GraphQL support for nested criteria queries

[lucianogreiner]

Currently, "relationship" typed fields can only be filtered by ID on GraphQL:

const Todo: CollectionConfig = {
  slug: 'todos',
  ...
  fields: [
    ...
    {
      name: 'user',
      type: 'relationship',
      relationTo: 'users',
    },
   ...
  ]
}

Therefore, it is not possible to query Todos where the user email field is equal to something, as an example.

Such operation is supported using Rest and Local query APIs:

Ideally, we should be able to make nested queries using GraphQL, such as:

{
  Todos(where: { user: { email: { equals: "something@test.com" } } }) {
    docs {
      ...
    }
  }
}

Of course that should respect both the maxDepth configuration at field and server config levels, and the GraphQL maxComplexity setting.

Additionally, we should decide how relationship fields marked with hasMany would behave for schema generation.

Using the example above, if we have multiple users attached to a Todo entry, in my opinion it is acceptable that we might be searching for Todos where all or some of attached users match a certain criteria. We see this on Keystoke as a reference.

I suggest the following in case the relationship is marked with hasMany:

const Todo: CollectionConfig = {
  slug: 'todos',
  ...
  fields: [
    ...
    {
      name: 'users',
      type: 'relationship',
      relationTo: 'users',
      hasMany: true
    },
   ...
  ]
}

If any of my Todo users match (Using "any", as possibly "in" is already being used for ID matching. Could also be "anyOf"):

{
  Todos(where: { users: { any: { email: { equals: "something@test.com" } } } } ) {
    docs {
      ...
    }
  }
}

If all of my Todo users match: (Could also be "allOf"):

{
  Todos(where: { users: { all: { team: { equals: "Secret Services" } } } } ) {
    docs {
      ...
    }
  }
}

Not to forget, we should also support the negate options of all if possible.

I would be glad to help implementing this if you think this is useful.

Thoughts?

[DanRibbens]

@lucianogreiner, thanks for all the details.

We're going to implement this. We'll update here when it is ready.

[b00y0h]

is there any way to handle querying a relationship? Here's my use case

export const CarouselCards: CollectionConfig = {
  slug: 'carousel-cards',
  fields: [
    {
      name: 'partner',
      type: 'relationship',
      relationTo: 'partners',
      label: 'Associated Partner',
    },
...
  ]
}

and I need to get all the CarouselCards that have a specific state. Hoping something like this would have worked:

query CarouselCards($state: String) {
  CarouselCards(where: {partner: { contact: {state: { equals: $state}}}}) {
    docs {
      title
      partner {
        contact {
          state
        }
      }
    }
  }
}

[paulpopus]

@b00y0h Not yet! You currently have two options:

1. A custom graphql endpoint where you can manually handle this inside a Resolver, check it out here https://payloadcms.com/docs/graphql/extending#example
2. A bit more convoluted but you can create a new field on your carouselcard collection to contain this "state" value and update it from your relationship data via hooks

I recommend option 1 until this feature is in core! Ping if you need any help with the custom resolver

[lorenzofaresin]

@XPOL555 some news?

[XPOL555]

Nope.

As mentioned here (https://discord.com/channels/967097582721572934/1143572219348402267/1143913244424163438) by @JarrodMFlesch that's something they want to implement. It's not clear "when". :/

[tyteen4a03]

It looks like there's a PR for this now #3296

Hope it can be prioritized!

[XPOL555]

Yes, that's great! I hope it's accepted soon.

[wkentdag]

Any updates on this feature? I was hoping it might get a mention during this morning's v3 status call. IIRC somebody in discord said it's implemented already in v3, but I can't find it anymore. So. I'm wondering...

1. Is it implemented in v3?
2. If not, is it planned?
3. Would you accept a PR to add this feature? either as a backport to v2, or a new feature to both versions.
4. If the answer to the first 3 q's is "no", how about a docs update to this line that (incorrectly) states "All GraphQL find queries support the where argument, which accepts queries exactly as detailed above." [edit: done chore(docs): note graphql relationship query limitations #7782]

I am interested in contributing a PR, but I don't understand why #3296 was left to die on the vine, so I'd love to get more insight into the payload team's current thinking re this issue. Thanks!

[tyteen4a03]

@DanRibbens might be able to elaborate as he's working on bi-directional relationships.

[wkentdag]

ya I figured they might be somewhat intertwined

[wkentdag]

i'm keeping an eye on the feat/join-field branch to see if this feature gets rolled in there, at the moment the basic bidirectional functionality hasn't been implemented yet: https://github.com/payloadcms/payload/blob/feat/join-field/docs/fields/join.mdx#graphql only the basic join logic has been implemented: d137ce0

IMO graphql is currently a second-class API citizen due to this missing feature, I kinda expect that to continue in v3 given that the local API appears to be the new "recommended" way of fetching data on the frontend 🙁

[wkentdag]

Any update on this for v3? AFAICT it's still not supported.

I'd understand if the team has decided not to implement this feature, especially with a viable alternative available now in the form of local API w/ field selection in v3, but some clarity would be really helpful here. At the moment this is a big missing feature that merits a warning in the docs. I imagine I'm not the only user who would've pursued a different architecture if I'd realized I could only query relationships via ID ahead of time.

[linus-ha]

I can't agree with that, as we have client software that does not run on Node.js, so the local API is not an option.
We need this feature!

[christophemenager]

Arf, so disappointed to discover this, which as many other limitations, is not mentioned in the docs 😢

[christophemenager]

Don't get me wrong I love payloadcms but it's so frustrating to discover things like that, and it's clearly not the first time