It is possible to write an updaters for deep nested fields?

[RIP21]

Yet another question.
Considering this schema.

type NameOfServiceMutations {
   createSomeThing: String!
   integrate(input: NameOfServiceInput!): NameOfServiceIntegrationPayload!
}

type IntegrationMutations {
  nameOfService: NameOfServiceMutations!
}

type Mutation {
  "Collects all possible mutations on company"
  company: CompanyMutations!
  "Collects all possible mutations on integrations"
  integration: IntegrationMutations!
  "Collects all possible mutations on onboarding"
  onboarding: OnboardingMutations!
}

With the usage like that

mutation NameOfServiceButton_Integrate($someString: String!, $metadata: JSON!) {
  integration {
    nameOfService {
      integrate(input: { metadata: $metadata, someString: $someString }) {
        ...NameOfServiceButton_NameOfServiceIntegraionPayload
      }
    }
  }
}

So this pattern is some sort of namespacing for particular entities/resources if you wish. Works both for Queries and even better for Mutations as there is no longer createEntityName, updateEntityName likeEntityName, deleteEntityName etc. You can make it easier to navigate and use.

mutation {
   entityName {
     create(input: {...}) { 
        ... 
     }
}

The Problem tho, is that updates don't give you the ability to write updaters for NameOfServiceMutations like

NameOfServiceMutations: {
  integrate: (result, args, cache, info) => {}
}

But only from the root Mutation type like

Mutation: {
  integraton: (result, args, cache, info) => {}
}

And then you should branch based on result effectively which would be ok, but there is a problem tho. That args are missing. As it seems, they're getting extracted from the root field only. So if I'll make some dummy argument field like integration(dummy: Boolean) then I'll see dummy to be in my args.dummy otherwise, nope.

How to work around this one? Or maybe it can be added as a feature? Or maybe there are some helper functions that can extract such from into object?
As this pattern is really lovely and smart if you ask me and I don't want to redesign the whole backend to fit URQL :)
It's way better to see 15-20 entities and then see what mutations they have going deeper down the tree than having 100 -120 mutations on the root Mutation type :)

[kitten]

This is a conscious limitation. GraphQL actively discourages you from "name spacing" mutations in result types. There are several reasons for that but two are relevant here:

• A GraphQL API will run mutation fields in series, which is unique to the mutation root type and important for operations like these that alter data on the backend. Nesting defeats this.
• There's no way to differentiate between mutating resolver fields and "data" fields on types. This means that all that's differentiating fields running mutations and fields that just resolve data in your schema is now a loose convention.

The latter is relevant because we can feasibly allow updaters to be written for any field. But we don't and actively discourage this because that means you could write updaters for any field including just data.

I'd suggest, and I'm pleading here 😅, please don't do this. This is one of these things that look right-ish if you haven't dealt with it before, is a case where you're trying to be more clever than the GraphQL spec, and leads to more issues down the line.

I'm saying this because, again, we could support this, but don't right now for a reason. Here are some follow up links on the topic while I'm at it ❤️

• https://www.freecodecamp.org/news/beware-of-graphql-nested-mutations-9cdb84e062b5/
• https://spec.graphql.org/June2018/#sec-Mutation

[RIP21]

Okay then. I thought that it was a pretty clever workaround to tidy things up :) I will read the articles and will refactor stuff maybe then. Fortunately, we're early in development, so :D

Any concerns related to queries? Same thing? Where's the data and where is the root? :)

[JoviDeCroock]

Queries are different, resolvers can be fully utilized to follow the data-flow inside of a query. This is also how it's intended in backend GraphQL when you have a product query and you want Product.categories to be a separate sub-resolver.

[kitten]

I suppose if you decide not to change your schema, there is the option of manually retrieving the nested data from the first argument, e.g. parent.fieldA.fieldB and so on. Really depends on how far you've nested these mutation fields. But ultimately I suppose they won't repeat so you can still get to them.

[MatthewAry]

It seems that for the first point that @kitten brought up, Apollo says that you can use client-side aliases to force it back to root.
BTW, I'm new with GraphQL. Trying to understand the cache system is proving a challenge.

Could you @kitten please elaborate on what you meant when you said

There's no way to differentiate between mutating resolver fields and "data" fields on types. This means that all that's differentiating fields running mutations and fields that just resolve data in your schema is now a loose convention.

Much appreciated.

[kitten]

Yes, what the docs there are saying is: GraphQL’s specification says that the root fields on the selection set on the root Mutation are resolved serially.

It doesn't matter whether they eventually end up in the same place, so that's completely correct, and doesn't actually influence what Graphcache does, as it always updates anything in series anyway based on the result.

That said, the original limitation here has been lifted — not to enable what the original post asked for, but oh well 😆 It's now possible to write updaters for arbitrary type & field combinations.
(Which was rather meant to be useful for query updates tbh)

What I meant by the original comment is that this is still bad schema design. Don't design Mutation.update.item.something but Mutation.updateItemSomething, basically. The specification is quite clear on this recommendation and implication as well.

The reason for that is, and what I meant originally, that you can't tell anymore what's a mutation on the client-side (or just looking at the schema or a selection set)

Mutation.update.item, for instance, wouldn't tell you whether Mutation.update is running a side-effect, or whether update { Item { ... } } is, i.e. update.Item.

While the limitation in Graphcache for updaters is lifted and updaters for any field on any type can now be written, for mutations, it's still recommended — from a general GraphQL schema design best practices point of views — to only have your side-effects run on root Mutation field resolvers, and not on nested resolvers.

So, not a cache problem, but a question of GraphQL schema / API design.

[kitten]

Leaving a note here, See comment: #1244 (reply in thread)

It's now possible to write updaters for any type & field combination, and not just Mutation and Subscription.

This is mainly meant though to catch "invisible updates" that are necessary when writing Query data, i.e. nested items that influence other nested items.

This is often an optimisation, or when integration this into schema design would actually make things more convoluted. In some cases, it's infeasible to add relations infinitely to query selection sets, to make sure that maybe a future Graphcache query can read from the cache.
This is why we now allow arbitary updaters.