Started thinking though some of the details of this. Here is a rough idea of the API I have in mind. To implement the following schema:

type Review @key(fields: "id") {
  id: ID!
  body: String
  author: User @provides(fields: "username")
  product: Product
}

extend type User @key(fields: "email") {
  username: String! @external
  email: String! @external
  emailDomain: String! @requires(fields: "email")
}

extend type Product @key(fields: "upc") {
  upc: String! @external
}

you would write something like:

const Product = builder.externalEntity('Product', {
  key: ['upc'],
  externalFields: (t) => ({
    upc: t.string(),
  }),
});

const User = builder.externalEntity('User', {
  key: ['email'],
  externalFields: (t) => ({
    email: t.string(),
    username: t.string(),
  }),
  fields: (t) => ({
    emailDomain: t.string({
      requires: ['email'],
      resolve: ({ email}) => email.split('@')[1],
    }),
  }),
});

builder.entityObject(Review, {
  name: 'Review',
  key: ['id'], // This part I don't know how to make type-safe.
  // arg here needs to be based on key above, so I also don't know how to make it type-safe
  resolveReference: ({ id }) => Review.loadById(id),
  fields: (t) => ({
    id: t.exposeId('id'),
    body: t.exposeString('body', { nullable: true }),
    author: t.field({
      type: User,
      provides: ['username'],
      resolve: review => {
        return {
          __typename: 'Review',
          id: review.authorId,
          username: review.author.email.split('@')[0]
        }
      },
    }),
    product: t.field({
      type: Product,
      resolve: review => {
        return { __typename: 'Product', id: review.productId }
      },
    }),
  }),
})

Field selections for @requires, @provides, and @key on external objects are all required to be based on external fields. This means we can use inference based on the externalFields return type to ensure that the field selections for those fields make sense. The biggest issue is that the @keys for entities owned by a service don't have the same restriction. This means that the keys can reference fields defined outside the object definition (either through nested fields, or methods like builder.objectField(...). This makes it impossible to infer the correct types for the keys on an entity, and by extension we can't correctly type the resolveReference method since we don't know they types for the keys that are going to be passed in.

There are a few things I can do to get it working for most use-cases, but it would not be reliable. This might be okay, since I think I could type basic fields like ids directly on the entity correctly, and then fall back to unknown for fields that can't be directly inferred.

Uh oh!

Apollo Federation support #97

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions