Hacker News Reader

Comment by arinlen | Hacker News Reader

> You can execute GraphQL queries via GET and set a cache up for it like REST.

Does it, though? It seems it really doesn't, nor was GraphQL designed with HTTP caching in mind.

The only references to caching in GraphQL are vague hand-waiving arguments about how theoretically GraphQL implementations might be implemented with some sort of support for caching primary keys.

But any type of HTTP caching is automatically excluded from GrahQL.

To put it differently, is there any third-party caching solution for GraphQL? As far as I could gather, the answer is no.

View on HN

It looks like you are fixated on caching in GraphQL, but that's unnecessary, you can just cache GraphQL like REST, because in the end they are just GET requests. Just cache the GET request.

> It looks like you are fixated on caching in GraphQL, but that's unnecessary

Oh so one of the most basic feature of any API, one which has a direct impact on scalability and motivates entire product lines and businesses like CDNs, is now "unnecessary"?

> you can just cache GraphQL like REST,

Go ahead and show one example, please.

It's just a GET request. Same as REST. I don't know what you want me to show as an example. You can use Apache, nginx, squid, any proxying webserver worth its salt...

> It's just a GET request. Same as REST.

I'm not sure you understand the problem at all.

Are you actually able to show an example or not? Because changing the HTTP verb doesn't magically change the problem, and passing query parameters as a request document renders these queries uncacheable.

> You can use Apache, nginx, squid, any proxying webserver worth its salt...

Great, pick the one you're familiar with, and just show the code. Well, unless you're not "worth its salt" or are completely oblivious to the problem domain.

Check back in a couple of hours, I'm on my mobile right now

A GET request is a GET request and anything that can cache one doesn’t know or care whether it’s for REST, GraphQL, a binary file or anything else.

Here's the code: https://github.com/RedShift1/graphql-cached-get

Note that I made a very primitive implementation. Depending on which GraphQL node is queried, the request will be cached by the proxy or not. Apollo GraphQL server has much more fine grained methods of allowing caching (see https://www.apollographql.com/docs/apollo-server/performance...) however I left the example code crude so you see exactly what's going on under the hood.

see https://www.apollographql.com/docs/apollo-server/performance...

> see https://www.apollographql.com/docs/apollo-server/performance...

Sorry, that doesn't cut it at all. Far from it. Being able to cache a response is not the same thing as optimizing queries that hit your database. Being able to cache a response means not having to hit your database to begin with, and save up on things like traffic going into your database, and round trip time.

With REST APIs I can get a web service to return responses that are HTTP cacheable, put a nginx instance between the ingress controller and the web service, and serve responses to REST clients without even touching the web service that provides the REST API. I can even deploy nginx instances in separate regions.

What's GraphQL's response to this basic usecase?

Did you take the time to read the article? I'll try a more specific link to a section https://www.apollographql.com/docs/apollo-server/performance...

Here's how we do it: https://wundergraph.com/docs/overview/features/caching We "persist" all operations using their name (unique) as part of the path. Variables are passed via query parameters. We also add a unique hash as query param which is generated by the configuration. This way, each "iteration" of the application invalidates the cache automatically. Additionally, we generate ETags for each request to reduce response payloads to zero when nothing changed. (https://wundergraph.com/docs/overview/features/automatic_con...) Combined with the generated type-safe client, this is a very solid setup.

i share your sentiment; in neo4j, a popular graph store, you can’t even get primary keys without a third-party plug-in (apoc)

Reply on news.ycombinator.com