objectType: types all underlying fields, how to make type scoped to those being exposed?

[marcebdev]

Still a little new, but starting to get the gist of things except for this one thing...

Issue Faced

const Item = builder.objectRef<{ id: string, name: string, other: string }>('Item')

const ItemQuery = Item.implement({
  description: 'contains basic item data',
  fields: (t) => ({
    id: t.exposeID('id'),
    name: t.exposeString('name'),
  }),
})

Now Item rightfully reflects the type of the underlying data so you can get auto-completion when implementing the objectType...

However, I'd expect the type for ItemQuery to effectively function like a Pick<> where only { id: string, name: string } is typed since the purpose of objectType is to define the subset of data we're interested in.

Why it's an issue

The issue this causes is that now when you define a query, you have to resolve the whole model even if that's not necessarily required.

builder.queryField('item', (t) =>
  t.field({
    type: ItemQuery,
    args: { id: t.arg.id() },
    // `other` and all other fields that we don't care about here are expected in the type, when they shouldn't be
    resolve: async (_, { id }) => ({ id: 1, name: 'test' }),
  }),
)

So if you want to say write a more constrained select query bc say it's an opaque model with lots of internal fields you want to ignore, or it's proxying for a micro-service or something like an elasticsearch API where you might have filters I don't seem to be able to do that.

Possible Workarounds

1. on queryField doing something like type: Pick<ItemQuery, id | name> instead but this is redundant with what objectType is already defining.

2. you scope the underlying data model, and write the query/api request first and then use the returned type. For instance for an SQL query you could do something like this assuming you're using a type-safe TS API

const dbQueryStub = () => ({ id: 1, name: 'test' })

builder.objectRef<typeof ReturnType<dbQueryStub>>

This seems bad for many reasons, including the fact that it seems like a goal of Pothos is to take the underlying data model itself and use objectType's to scope to what you want to expose to the graph where this is an outright anti-pattern, and works against the object system entirely. It'd also be very redundant if you have different queryTypes with the goal of returning different amounts of detail on the same large models.

So option 1) would still be functional in theory but redundant, idk how simple it'd actually be but I'd be surprised if something doesn't already exists that I'm just missing here. Could someone please point me in the right direction, hopefully I'm just missing something?

[hayes]

The relationship between typescript types and GraphQL types is important to understand, and isn't intuitive when you are only looking at basic examples.

A good way to think about it is that the typescript types represent your data, and your GraphQL types represent your desired output, and Pothos helps ensure that the way this data is mapped is type-safe. The typescript types do not in any way need to reflect the shape of the GraphQL API.

When you define an objectRef

const User = builder.objectRef<{ id: string, firstName: string, lastName: string }>('User')

you are declaring the data that will be used throughout your schema to represent a User. Any field that returns a User will need to return an object that matches the type you defined here for the ref. The fields you will define later for the User type have no bearing on what your resolvers for a User will need to return.

When you define fields for the User type the type you defined in the ref is what will be available as the source/parent argument in the resolver:

User.implement({
  fullName: t.string({
    resolve: (user) => `${user.firstName} ${user.lastName}`
  }),
  isAdmin: (user) => isAdmin(user.id),
})

the t.expose* methods are just helpers that allow omitting resolvers in cases where your data matches what you want in your schema:

User.implement({
  firstName: t.exposeString('firstName'),
  // is short hand for
  firstName: t.field({
    type: 'String',
    resolve: (user) => user.firstName
  }),
})

The original type passed when creating the ref also affects other APIs:

// the user type provided for auth checks for the scope-auth plugin
User.implement({
  address: t.field({
    type: 'String',
    authScopes: (user, ctx) => user.id === ctx.user.id // only allow reading your own address
    resolve: (user) => getUserAddress(user.id)
  }),
})

If you just want to define objects where the data is the same as what would be returned from the API, you can use the simple-objects plugin, which doesn't require types or resolvers:

const UserType = builder.simpleObject(
  'User',
  {
    fields: (t) => ({
      firstName: t.string(),
      lastName: t.string(),
    }),
  },
);

builder.queryType({
  fields: (t) => ({
    user: t.field({
      type: UserType,
      args: {
        id: t.arg.id({ required: true }),
      },
      resolve: (parent, args, { User }) => {
        return {
          id: '1003',
          firstName: 'Leia',
          lastName: 'Organa',
        };
      },
    }),
  }),
});