Add a select option to local API

[MoSattler]

In the local API, right now the only way to choose/limit which fields are returned by the local API is the depth parameter.
This approach has a few disadvantages:

• it's very crude and imprecise
• it leads to imprecise typing (related fields are always typed as string | SomeRelationCollectionType

It would be really cool if payload's local API could take a similar approach to prisma's select or how it works in GQL.

A possible API could be

  const res = await payload.find({
    collection: "users",
    select: {
      email: true,
      organization: {
        name: true,
      },
    }
  });

and the type could correctly be inferred to be

{
  email: string, 
  organization: {
    name: string
  }
}

[jmikrut]

Hey there! I do agree that this is something that would be very nice to have. There will be some complexities that make this a bit harder than it might seem at first pass though.

For example, we have nested fields and structures like tabs, groups, arrays, blocks, etc. However our select mechanism works would need to be functional with nested fields.

Prisma doesn’t have that problem because it doesn’t support nested structures at least last time I looked.

Another thing to consider is that our relationship field generated types are intentionally written as unions for more than just the depth parameter. There are a variety of reasons why a relationship may not be populated properly like access control, if the document was deleted and can’t be populated any longer, etc. There’s no way with typescript to infer a 100% accurate type there, so we will likely need to keep it as a union for safety.

Last thing I can think of just off the top of my head is that because we can populate via the depth parameter, if we were truly going to build out a select property, we would need to be able to pass in what fields to select on what relationships, and at what depth. That would be very challenging and unwieldy to even use.

I’m definitely not concluding that this isn’t a good idea, but I think this is basically what GraphQL is made for and if we solve all the problems above, we are just re-creating GraphQL.

Related:
#1288

[MoSattler]

Thank you for the context, makes a lot of sense!

[MoSattler]

I think this is basically what GraphQL is made for and if we solve all the problems above, we are just re-creating GraphQL.

If one could utilise GQL (and by that I do mean the query language alone) for the local API (and hence not have to go though http as a transport layer), that'd be fantastic.

[ssyberg]

@jmikrut

I’m definitely not concluding that this isn’t a good idea, but I think this is basically what GraphQL is made for and if we solve all the problems above, we are just re-creating GraphQL.

This is partially true in that the client can select what comes through in the response payload, but AFAIK there's no database optimization happening based on the gql query being sent - the gql resolvers are still just grabbing everything and then passing back selected fields to the FE. I'm frequently going back and forth about if I should bypass the local API and use mongoose directly to address this (I really don't want to haha!)