How to manually normalize data into Graphcache?

[ersinakinci]

My app client, running in the browser, fetches search results from a third-party service. I'd like to normalize these results into Graphcache. Is there a way to do this?

I looked into these solutions but they seem like dead ends:

• https://formidable.com/open-source/urql/docs/graphcache/custom-updates/ discusses custom updates to the cache store, but all the methods described appear to be side effects to mutations. I don't need to execute a mutation against my schema, which would incur a round trip to the server. Not to mention that I don't have a mutation in my schema that would neatly correspond to the normalization operation that I want to execute.
• I found https://formidable.com/open-source/urql/docs/api/execute-exchange/, but it's not 100% clear to me how I would use this to solve my problem. Maybe create a custom local schema with a local mutation just for the purpose of normalizing my search results into the store, then write an updater function to perform the normalization? But I still want access to my server-provided schema; it's not just a local-only app. Besides which, I can't use this exchange because I already have to use https://formidable.com/open-source/urql/docs/api/multipart-fetch-exchange/, so it's not just a matter of swapping the fetch exchange for this one.

Ideally, there would be some way for me to directly manipulate the store, but I don't see how I can do this.

[JoviDeCroock]

Hey,

We aim to have graphCache be a representation of your server-side state, this makes a lot of cases more deterministic, hence why we don't allow cache updates outside of mutations/subscriptions.

My advice most often would be to write this inside these transformations inside of React-land, this way the data will keep representing the query.

If the transformation is just a data-formatter or something you could use the resolvers API.

[ersinakinci]

@JoviDeCroock

We aim to have graphCache be a representation of your server-side state, this makes a lot of cases more deterministic, hence why we don't allow cache updates outside of mutations/subscriptions.

This makes sense, thank you. Would be great for that to be included in the docs 👍. I'm not sure that I agree with it but I appreciate the design choice. Personally, I'd rather have an escape hatch, if it would be simple to build, with some kind of scary name like unsafeCustomUpdate.

My advice most often would be to write this inside these transformations inside of React-land, this way the data will keep representing the query.

If the transformation is just a data-formatter or something you could use the resolvers API.

Could you please clarify? I'm not sure what you mean by "transformations," I'm looking to take data coming from an external service and store it in a way that the rest of my app can access it using urql. I assume that transformation would be involved to make it fit a shape that urql can understand, but the confusing part is how to get it into the store, not how to perform the transform. Sounds like from your previous comment that this use case is intentionally unsupported and discouraged.

Also, resolvers formats data coming from the GraphQL endpoint on my server, no? But my data is coming from a third-party service.

[JoviDeCroock]

Have you considered using the thirth party service as an extension of your GraphQL server? This extends your schema to include that data making it tie into the whole GraphQL story more.

[ersinakinci]

Haha. Actually, that's how it's currently set up. I was trying to refactor to go through the search service directly in order to avoid hitting my server.