Allow for type to be omitted when calculating Cache keys

[x-sheep]

Use case

Given an endpoint that returns an interface type, it's currently not possible to set a fieldPolicy that will resolve the various implementation types.

interface Node @typePolicy(keyFields: "id") {
    id: ID!
}

type Actual implements Node {
    id: ID!
    name: String
}

type Query @fieldPolicy(forField: "node", keyArgs: "id") {
    node(id: ID!): Node # Cache will never find an Actual object before sending a request
}

I'm trying to use the node field to get a variety of types that have most fields in common. However, since those types are cached using their full type name, it isn't possible to retrieve the object from cache using the node field because only the Node interface is known.

Describe the solution you'd like

Inspired by the rejected RFC apollographql/apollo-ios-dev#549, I want to suggest @typePolicy and @fieldPolicy gain a new field named keyScope, with one of the following possible values:

1. TYPE: The identifier is unique for the type, e.g. an auto-incrementing column from a database table.
2. SERVICE: The identifier is unique across the current GraphQL Service, e.g. a type name combined with an auto-increnting column.
3. UNIVERSAL: The identifier is unique across all GraphQL services, e.g. UUIDs generated through RFC 9562. Exact serialization details are unspecified, as long as all UUID information is present. Appending more information is allowed.

TYPE is the default. If the scope is not TYPE, cache keys should not contain the type name but only use the actual id as a cache key (possibly with a constant prefix).

The GraphQL best practice known as Global Object Identification requires that all ids are unique across the service. This is also a required part of the Relay spec.

[BoD]

(I've transferred the ticket because new cache features will happen here.)

Thanks for this, this is interesting!

For your immediate use case, you may provide your own CacheKeyGenerator/CacheResolver as described here, and not include the type in the CacheKey.

Also, I'm wondering if there's a way to make the builtin TypePolicyCacheKeyGenerator/ FieldPolicyCacheResolver work as expected with interfaces/unions.

More thoughts about your proposal: do we need the distinction between service and universal?

[x-sheep]

do we need the distinction between service and universal?

Not for my use case, but I thought it would be a good idea to nail down this distinction in case a service becomes part of a federated graph. The term "global" could refer to either SERVICE or UNIVERSAL which could become a real problem when several subgraphs produce identifiers and call them global.

[martinbonnin]

do we need the distinction between service and universal?

I want it for the day we have a Global supergraph 😄 Then I can cache my GitHub pull requests and Shopify inventory in the same cache 🚀 (probably not until a couple more decades so let's say I support UNIVERSAL softly for now and unless there are other strong arguments, it's probably better to live it out and add it later down the road when we actually need it, or when our grand children do 😄)

[x-sheep]

Obviously I'm not attached to immediately adding UNIVERSAL, but I think it would be a good idea to keep this new field an enum, and avoid the term "global" since it doesn't play well with federation.

[BoD]

After looking at this more closely I think it’s enough to specify the scope on @typePolicy. When a field returns:

• An object
  • To decide whether to include the type in the returned key, we can look at the field’s type’s policy
• A union or an interface
  • The key must never include the type

That being said, to simplify further we could have a schema-wise flag to include the type or not. There certainly are schemas out there that have a mix of global and per-type keys (wondering if that is your case @x-sheep?), but maybe we can hope that most schemas will either be in one case or the other?

[x-sheep]

The schema I'm using follows the Relay spec, so all I need is the typePolicy for the Node interface. Although I can imagine other developers want to use different key fields for other types that don't conform to Node (in combination with other types that do use it).

Leaving out the Scope parameter for @fieldPolicy seems fine to me.

As for schema-wise information, I kind of wish there was a standard way for schemas to identify themselves as compliant with the Relay spec (or other best practices) so Apollo could use some reasonable defaults in these cases. Right now, it's always stated in user documentation instead of a machine-readable form if a spec is followed, which means Apollo cannot be 100% certain and always errs on the side of caution. I expect a lot of projects using Apollo and a Relay GraphQL server will be using the same extensions to their schema.

[BoD]

All right, in #102 a new CacheKey.Scope enum can be passed to TypePolicyCacheKeyGenerator and FieldPolicyCacheResolver. The type name will be included only when passing TYPE (the default).

We can add the option to configure this by type later if there is some demand - for now I think a global configuration is a good tradeoff that should work for most users.