Consider id field addition dangerous

[sambostock]

While most of the time adding a field is a safe non-breaking change, there are certain fields that can be dangerous to add, namely the id field.

This is because many caching implementations will use the id field as part of a cache key, if present. For example, Apollo's InMemoryCache uses __typename and id (or _id) to generate a cache key.¹

In fact, an ESLint-Plugin-GraphQL rule exists to enforce the querying of so called "required fields"² (such as id), to ensure caching is done properly.

As such, adding an id field to an existing type can change the client side caching behaviour if the client hasn't defined a custom caching strategy (e.g. start caching resources that were previously not cached).

Footnotes

1. https://www.apollographql.com/docs/react/v2/caching/cache-configuration/#default-identifiers ↩

2. https://github.com/apollographql/eslint-plugin-graphql#required-fields-validation-rule ↩

[sambostock]

Perhaps it should be possible to customize this?

For instance,

• Apollo's InMemoryCache looks for id or _id by default
• ESLint-Plugin-GraphQL's required-fields rule is customizable and uses uuid in its example

[swalkinshaw]

🤔 I think customizing this might go into "linter" territory? Especially beyond the initial id only proposal.

Anyone consuming this library is free to do whatever they want with the output of course.