GraphQL helpers?

[jeffposnick]

I'm opening up some feedback from @cheneytsai into a more public issue, to gauge developer interest and figure out exactly what the scope of this work might entail. Here's a (potentially naive, due to my lack of familiarity with GraphQL) distillation of the initial discussion.

Developers building on top of a GraphQL-based data backend run into a few unique challenges (vs. using a REST-ful backend):

• Both HTTP POST and GET request are commonly used for read-only data retrieval, and those POST request don't play nicely with the Cache Storage API by default. Only GET requests, with unique URLs, can be used as keys when writing to the Cache Storage API.

• Routing those requests using Workbox's built-in support for RegExp matching can be a bit blunt. It would help to have some routing criteria that "knew" a bit more about GraphQL, and felt more natural to configure.

• One of the premises of GraphQL is that the data on the server is represented as a nested set of properties, and each GraphQL query requests a slice of only the data that's needed at that moment. Two different GraphQL queries might end up requesting some overlapping data, mixed in with some unique data. Ideally, a caching strategy that "knew" about GraphQL would be able to identify the overlapping data. Instead of storing multiple copies of it, each keyed by the specific GraphQL query, the caching strategy would just store a single reference to the common data, and keep that cached data up to date. (This sounds like it would require replicating the native representation of data that the server uses inside of the service worker.)

Some relevant projects and docs that exist today:

• Client caching in Facebook's Relay library. (This looks to be an in-memory cache, and is not related to the Cache Storage API or available inside of a service worker.)

• micro-graphql-react by @arackaf includes some guidance about using that library in conjunction with Workbox.

[arackaf]

I don't think there's much for Workbox to do here, honestly. POST requests don't play well with the cache api, as you said, and there's nothing Workbox can do about that. GraphQL endpoints by default accept GET as easily as POST; unfortunately most client libraries default to using POST (I believe Apollo has gotten better here).

Thanks for the shout-out on micro-graphql-react - enabling GET by default was one of my goals from the start. Of course there are further complications. If you're using persisted queries, which suddenly become much more important if you're sending your queries over the wire with GET, then you won't have an easy way to identify which query is which, since only the dynamically-generated query id will be sent, along with whatever variables the query has. I've worked around this by just adding a dummy query argument, indicating which cache to put it in, ie

runtimeCaching: [
    getCache({ pattern: /^https:\/\/mylibrary\.io\/graphql\?query=.+bookSearchVersion/, name: "book-search-graphql", expires: 60 * 5 }), //5 minutes
    getCache({ pattern: /^https:\/\/mylibrary\.io\/graphql\?query=.+isBookDetails/, name: "book-details" }),

which of course expands to a Workbox runtime caching entry. Though at scale I imagine a more generic solution like a cacheCategory=X variable, which the workbox config could handle differently based on X might be more suitable.

[FluorescentHallucinogen]

@jeffposnick PTAL at:

• https://github.com/benseitz/apollo-link-offline/issues/1#issuecomment-371678922
• https://stackoverflow.com/q/51031445

[pcvonz]

For what it's worth: this is the current recommended implementation for data persistence in the Apollo docs.

[jeffposnick]

As things stand, there are now a couple of articles:

• https://medium.com/@jono/cache-graphql-post-requests-with-service-worker-100a822a388a
• https://medium.com/@adamrackis/making-your-web-app-work-offline-with-service-workers-and-indexeddb-6ce9c538c48

https://www.apollographql.com/docs/react/advanced/caching.html#persistence also seems like something that could help, if not focused on the service worker.

I'm less and less convinced that this is something we could do in a meaningful way as part of a core Workbox library, so I'm going to close this and hope that the guidance linked to above could steer folks in the right direction.