Does GraphQL has the same caching ability as REST

问题:

We are building a heavily requested API and now considering using GraphQL, REST or a combination of REST and GraphQL. We like the approach of GraphQL that the frontend can decide, which data is returned and see its benefits. But on the other hand we are worried about caching because of the type of data we are storing (Product and Product Configurations). For the moment we see the following options:

• Only using GraphQL: Allows us to speed up our frontend developmentand gives our API more flexibility for future implementation. But through the high amount of products we want to use the basic http caching ability and our CDN.

• Only using REST: Allows us to use the standard http cache on every request but needs an defined endpoint for every frontend request.

So basically I want to know if the caching ability of GraphQL is the same as REST?

---

As a plus we thought about combining it. The reason for this is that we have a backend cache which caches data from our backend-systems:

• Combining both: The idea is to have for example a product JSON behind the REST endpoint product/1 which will serve the product data and all configurations. This is then saved in our backend cache. GraphQL can then be used by the fontend developers to sort out the configuration parts the specific view needs (e.g.: product/1?query=SomeGraphQLQuery'). So the REST-Endpoint is for server-caching and the GraphQL for client-caching.

Does this approach make sense in the 'GraphQL' world or is it just an useless abstraction layer and brings no improvement?

回答1:

Some implementations of GraphQL like Apollo client and server have plugins for cache, and i have a project that combine REST and graphql, so i'm caching the REST calls in memory (redis) and Graphql query results is cached in browser by apollo client, it is working great but i think you do not need to combine REST and graphql like i do cause your project is new, i made this cause i do not have choice to kill the REST API and build all in graphql, so i only wrap the REST inside graphql to get the benefits in front-end. My recommendation is to you go on with graphql only and apply cache techniques in query calls and client consumers.

回答2:

There are multiple solutions for caching, server and client side. I don't think REST has the edge here...

You can have your resolvers caching data and implement pubsub to know when they need to clear it, you can have some sort of caching on the client as well.

There's no reason for combining the two. And I feel that the real question is not whether or not you can cache successfully with GraphQL, but rather "Which way to do it"?