Follow-up : Query with a "mutation-like" side-effect

[strblr]

Hello, this is a follow-up to an issue I opened yesterday.

To quickly recap the situation :

• I need to implement an operation in GraphQL whose role is to parse raw xlsx files into Patents (which is a GraphQL type). So, this operation has the following signature : parsePatents(project: ID!, raw: [String!]!, autoSelect: Boolean): [Patent!]!. The debate is about whether this should be a query or a mutation.
• Patents can be selected into a Project, this is indicated via a selected field on Patent. You can select a patent via the selectPatent(project: ID!, patent: PatentInput!): Patent! mutation.
• Patents returned by parsePatents should listen to graphcache updates, the UI must rerender when a patent is selected.
• Instead of calling parsePatents then calling selectPatent on each patent, I want to implement a shortcut via the parsePatents argument autoSelect, to not only parse them and return them, but also select them into the project, all at once.
• There is another query called selectedPatents which only returns selected patents (with pagination). This query should be refetched when new patents are selected.

Here is the problem :

• If parsePatents is a query, then I can't refetch selectedPatents if autoSelect is true because graphcache's update config doesn't accept side-effects for queries.
• If parsePatents is a mutation, then the list it returns can't listen for graphcache changes.

I don't have much flexibility to redesign everything since this is a project for a client who has specific demands.

What should I do ? Thank you !

[andyrichardson]

Hey @ostrebler - I've had a brief look at the previous issue and I think the team make some pretty good points. It sounds like this is more of a backend concern but maybe we can help you out anyhow!

The first thing I think would be best to work out is:

1. what is the data you want to retrieve
2. what are the changes you want to make to data
3. what is the data you need back in response in order to reflect those changes on the frontend

[strblr]

@kitten But then as I said, the list returned by parsePatents (which has to be returned and displayed in order for the parsed patents to be selected) won't update when items in it are selected, because useMutation doesn't seem to care about graphcache updates.

[kitten]

yes, because mutations aren't delivering reactive data, queries are, as said. What I'm saying is you can create an update that reacts to the mutation and updates your data so that your query, which shows selectedPatents can display the new data that parsePatents has received. Mutations update query data, and Graphcache only holds normalised query data, as mutation data isn't ever a tree of data that can be read; the Query type is an origin from which data can be accessed, mutations are not; meaning, that mutations are updating the data in the normalised cache (and sometimes you have to update relations i.e. links manually) so that queries can see these updates.

So, again, you'll have to have some kind of query that loads selectedPatents. I don't know anything about your app, so maybe there's some details missing here about your schema, but, if you call parsePatents and you display those and you unselected/deselect those, maybe that should be UI state updating locally, or maybe you need a secondary query that shows the created patents. Either way; if you wish to implement this selection state then you need something reflecting it, e.g.

type Mutation {
  parsePatents(project: ID!, raw: [String!]!, autoSelect: Boolean): ParsedPatentConnection!
}

type ParsedPatentConnection {
  project: Project!
  patents: [PatentEdge]!
}

type PatentEdge {
  selected: Boolean!
  patentId: ID!
  patent: Patent!
}

so, if that's more closely to what you mean (i.e. your Project.selectedPatents are a subset of those that have been created, which is a list that's only available when they're created) then my suggestion has to unfortunately be rather short since this will depend on your specific implementation details. But overall, you'd need to either manage this state in your UI code, or you'll have to have some kind of state for it on the server-side, which I don't think is unreasonable. Now, if you don't actually create any patents in this flow, then I'd just suggest to manage the selection state locally only, since no actual server data will have been created at that point. If it is created on the server-side and the selection state along with all parsed patents are stored, then I'd suggest making a query showing the parsed data.

Either you'll therefore need to have all parsed patents be queryable after they've been parsed, or your selection state is a client-side only concern and will have to be partially stored outside of Graphcache/GraphQL.

[strblr]

@kitten Yes I think you really addressed my problem here. I didn't think of the local state solution, parallel to graphcache. I might very well do that, at least I'll give it a try. Thanks for giving your time.

as mutation data isn't ever a tree of data that can be read

That's the part I don't understand. Would it explicitly go against the spec ? What kind of unexpected behavior would be caused by making useMutation subscribe to the cache ? It feels like data has the same semantic everywhere, whether it comes from a query or a mutation. The fact that GraphQL even allows to return data from a mutation shows in my opinion that it's meant in some cases to have a query semantic, especially for use cases like these where you have intermediary data that would be inconvenient to be stored on the server.

[kitten]

Well, mutation data isn't consistent, so it can't be updated; think of it like writing vs reading from the cache. When an operation executes we read from the cache, if the cache doesn't have enough (or any) data we go to the API and write the API result to the cache. For mutations, we'll always go to the API since there's a side-effect to complete, so therefore they're not commutative and must only be run once. They also don't have a root (meaning, if you call one mutation twice you'll always get different entities, typically). Meanwhile, queries can be read or queried infinitely often, they're commutative, meaning that a query root type will always refer to the "same data" and can be run again and again as needed. That means that we can't update the mutation data with other data, because there's no consistent root to look for.

If you're actually interested in understanding the whole thing, I've got a blog post that (rather than glossing over the implementation and explaining the concept, like our docs page) goes into great detail on how normalised caching in Graphcache and in GraphQL in general works: https://kitten.sh/graphql-normalized-caching

[strblr]

@kitten I'll read that, thank you. I have to say, it's actually amazing that you guys take time to be so reactive and always answer in great details. Really appreciated !