Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Federation support checklist #10206

Open
16 of 35 tasks
eddeee888 opened this issue Nov 28, 2024 · 0 comments
Open
16 of 35 tasks

Federation support checklist #10206

eddeee888 opened this issue Nov 28, 2024 · 0 comments
Assignees

Comments

@eddeee888
Copy link
Collaborator

eddeee888 commented Nov 28, 2024

  • @key
    • ref should not be mapper. PR
    • Interface with @key must generate __resolveReference. PR
    • Ref types are scalar output type (?)
    • __resolveReference should return mapper if available
    • Defining advanced @keys
      • composite @key work e.g. @key(fields: "id anotherId")
      • nested @key work e.g. @key(fields: "id organization { id }")
      • multiple @key work e.g. @key(fields: "id") @key(fields: "id2")
  • @interfaceObject
    • No types required
  • @extends
    • No types required
  • @shareable
    • No types required: this is used during composition check to say whether a field can be resolved by multiple subgraphs or used as another Graph's @key (which is implicitly shareable)
  • @inaccessible
    • If an enum member is marked with inaccessible, omit it from types, otherwise there could be runtime errors
  • @override
    • No types required: this is used to migrate field resolving from one subgraph to another
  • @external
    • If a field is marked with @external, do not generate resolver types.
    • If a field is marked with @external, do not change other fields' signature from ParentType (using mappers) to GraphQLRecursivePick
    • If a type is marked with @external , generate the base type but not resolver types
    • Server Preset must not generate resolvers i.e. use resolver types instead of type interface to compare fields against mappers
  • @provides
    • When @provides is used on an @external field, the field resolver type is generated
    • @provides works with nested path
  • @requires
    • Fields marked with @requires must use the normal mappers, instead of the GraphQLRecursivePick with the @key and @requires fields.
    • When there's a field marked with @requires, the __resolveReference 's ref must have a union of possible combination e.g.
type User @key(fields: "id") {
  id: ID!
  title: PersonTitle! @external
  firstName: String! @external
  lastName: String! @external
  birthYear: Int! @external

  fullName: String! @requires(fields: "firstName lastName")
  fullNameWithTitle: String! @requires(fields: "firstName lastName title")
  age: Int! @requires(fields: "birthyear")
}

Then, the type of reference is something like:

ReferenceResolver<
    Maybe<ResolversTypes["User"]>,
    { __typename: "User" } 
   & GraphQLRecursivePick<ParentType, { id: true }> // <-- from @key, must always be here
   & GraphQLRecursivePick<ParentType, { firstName?: true; lastName?: true }> <-- from @requires
   & GraphQLRecursivePick<ParentType, { firstName?: true; lastName?: true, title?: true }> <-- from @requires
   & GraphQLRecursivePick<ParentType, { birthyear?: true }> <-- from @requires
   , ContextType
  >

Note: the type for @requires needs a re-think because if fullName is in the selection set, firstName and lastName must exist in the ref together. The example above is saying there could be a scenario where firstName is there but lastName is not. We need something like AnyCombinationOf<ArrayOfRequiresOptions>


Enterprise directives

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant