Remove read-only fields before mutation in GraphQL

Question

I’ve got a type called Article in my schema:

type Article {
  id: ID!
  updated: DateTime
  headline: String
  subline: String
}

For updates to it, there’s a corresponding input type that is used by a updateArticle(id: ID!, article: ArticleInput!) mutation:

input ArticleInput {
  headline: String
  subline: String
}

The mutation itself looks like this:

mutation updateArticle($id: ID!, $article: ArticleInput!) {
  updateArticle(id: $id, article: $article) {
    id
    updated
    headline
    subline
  }
}

The article is always saved as a whole (not individual fields one by one) and so when I pass an article to that mutation that I’ve previously fetched, it throws errors like Unknown field. In field "updated", Unknown field. In field "__typename" and Unknown field. In field "id". These have the root cause, that those fields aren’t defined on the input type.

This is correct behaviour according to the spec:

(…) This unordered map should not contain any entries with names not
defined by a field of this input object type, otherwise an error
should be thrown.

Now my question is what a good way to deal these kinds of scenarios is. Should I list all properties that are allowed on the input type in my app code?

If possible I’d like to avoid this and maybe have a utility function slice them off for me which knows about the input type. However, since the client doesn’t know about the schema, this would have to happen on the server side. Thus, the unnecessary properties would be transferred there, which I suppose is the reason why they shouldn’t be transferred in the first place.

Is there a better way than maintaining a list of properties?

I’m using apollo-client, react-apollo and graphql-server-express.

Can you please show the actual mutation that you're calling? It sounds like something else is amiss here. — Mar 6, 2017 at 17:22
Thanks for the quick response @marktani! I've added the mutation code to the question. — Mar 6, 2017 at 17:36
Do you have the possibility to run a "raw" mutation against your server? That is, using GraphiQL or a HTTP client like curl or fetch. I want to understand if this is an error thrown by Apollo or thrown by your server. — Mar 6, 2017 at 17:43
I've just simulated the request with a curl. The error is definitely thrown by the server. Removing the fields that are unknown to the input type fixes the problem. — Mar 6, 2017 at 17:51
Exactly, the root cause seems to be that the mutation doesn't know about those fields. My preferred solution would have been that they are ignored, but that would involve transferring them to the server, which I guess is the reason this isn't supported. Sadly I can't share the endpoint with you, but I guess every GraphQL endpoint will respond in the same way when a mutation is called with an input type that includes extra fields. — Mar 6, 2017 at 18:00

score 10 · Accepted Answer · 2022-01-04 15:50:34Z

You can use a fragment for the query, which includes all mutable fields of the data. That fragment can be used by a filter utility to remove all unwanted data before the mutation happens.

The gist is:

const ArticleMutableFragment = gql`
fragment ArticleMutable on Article {
  headline
  subline
  publishing {
    published
    time
  }
}
`

const ArticleFragment = gql`
fragment Article on Article {
  ...ArticleMutable
  id
  created
  updated
}
${ArticleMutableFragment}
`;

const query = gql`
query Article($id: ID!) {
  article(id: $id) {
    ...Article
  }
}
${ArticleFragment}
`;

const articleUpdateMutation = gql`
mutation updateArticle($id: ID!, $article: ArticleInput!) {
  updateArticle(id: $id, article: $article) {
    ...Article
  }
}
${ArticleFragment}
`;

...

import filterGraphQlFragment from 'graphql-filter-fragment';

...

graphql(articleUpdateMutation, {
  props: ({mutate}) => ({
    onArticleUpdate: (id, article) =>
      // Filter for properties the input type knows about
      mutate({variables: {id, article: filterGraphQlFragment(ArticleMutableFragment, article)}})
  })
})

...

The ArticleMutable fragment can now also be reused for creating new articles.

Yeah GraphQL currently doesn't include a lot of nice-to-have stuff for CRUD operations, like utilities for saving an entire object via an input object. It kind of assumes you are calling each mutation with exactly the data you mean to pass in. Which might be good because if someone added a new field to the input type, then you will end up sending more fields than you expected. — Mar 7, 2017 at 7:03
That's true. On the other hand, when new fields are added to Article that are queried and updatable with the view, I might forget to add them to the whitelist – so that's something to keep in mind. But good to know that I'm not missing anything obvious – thanks! — Mar 7, 2017 at 9:36
Actually, this might be solved in a good way with the filter capabilities of your graphql-anywhere package. That way I can write a query that filters the data before a mutation. That query can be placed right next to the query that fetches the data and so it might be easier to keep those in sync. — Mar 7, 2017 at 9:37
Or even better a shared fragment between the query and the filter query for the mutation. I'll give that another try. — Mar 7, 2017 at 9:48
Ooh, I like this a lot because it still lets you specify exactly the fields you are trying to send! — Mar 7, 2017 at 16:15

Jiří BrabecJiří Brabec 3002 silver badges7 bronze badges · Accepted Answer · 2019-02-22 13:09:05Z

I’ve personally had same idea and took @amann ‘s approach earlier, but after some time the conceptual flaw of using query fragments on input types became evident. You would’n have an option to pick input type field that isn’t present in (corresponding) object type – is there even any?

Currently I’m describing my input data by typesafe-joi schemas and using it’s stripUnknown option to filter out my form data.

Invalid data never leaves form so valid data can be statically typed.

In a sense, creating joi schema is same activity as defining “input fragment” so no code duplication takes place and your code can be type-safe.

LIITLIIT 5066 silver badges16 bronze badges · Accepted Answer · 2023-09-08 07:49:43Z

If one uses graphql-codegen, then one can add another codegen config to his project, like so :

import { CodegenConfig } from '@graphql-codegen/cli';

import { commonConfig } from './configs/common.config';

const classesCodegen: CodegenConfig = {
  schema: 'apps/back/src/app/schema.gql',
  documents: ['apps/front/**/*.tsx'],
  ignoreNoDocuments: true,
  generates: {
    'libs/data-layer/src/lib/gql/classes.ts': {
      plugins: ['typescript'],
      config: {
        declarationKind: {
          // directive: 'type',
          // scalar: 'type',
          input: 'class',
          // type: 'type',
          // interface: 'type',
          // arguments: 'type',
        },
        ...commonConfig,
      },
    },
  },
};

export default classesCodegen;

Above, we ask graphql-codegen to generate inputs as classes. Geneated code will be something like :

/** Material Input */
export class MaterialInput {
  /** Material's id */
  _id?: InputMaybe<Scalars['Id']['input']>;
  /** Material's coding config */
  codingConfig: CodingConfigUnionInput;
  /** Material's content */
  content?: InputMaybe<Scalars['String']['input']>;
  /** Material's cost usages */
  costUsages: Array<CostUsageInput>;
  /** Material's label */
  label: Scalars['String']['input'];
  /** Material's status id */
  statusId: Scalars['Id']['input'];
  /** Material's title */
  title?: InputMaybe<Scalars['String']['input']>;
};

By having classes instead of types or interfaces, we are now able to prune our data before sending it to backend.

Here is a small util to remove any excess data from an object, regarding a given class :

import type { C, O } from 'ts-toolbelt';
import { assign, keys, pick } from 'lodash';

export const pruneInput = <I extends object>(
  instance: O.Object,
  Class: C.Class<unknown[], I>,
): I => {
  const input = new Class();
  assign(input, pick(instance, keys(input)));
  return input;
};

Finally, you can clean your data without having to maintain this cleansing step anymore :

import type { O } from 'ts-toolbelt';

import { CostUsageInput, MaterialInput } from '@your-organization/data-layer';

import { pruneInput } from '../../../utils/prune-input.util';

import { codingConfigForm2ApiMapper } from '../../mappers/coding-config.form2api.mapper';

import type {
  MaterialForm_Material,
  MaterialInput as IMaterialInput,
} from '..';

export function materialForm2ApiMapper(
  material: O.Readonly<MaterialForm_Material>,
): O.Readonly<IMaterialInput> {
  const materialInput = pruneInput(material, MaterialInput);

  const costUsagesInput = materialInput.costUsages.map((costUsage) =>
    pruneInput(costUsage, CostUsageInput),
  );

  return {
    ...materialInput,
    costUsages: costUsagesInput,
    codingConfig: codingConfigForm2ApiMapper(material.codingConfig),
  };
}

Remove read-only fields before mutation in GraphQL