Does GraphQL have the same caching ability as REST

Question

We are creating a highly requested API and are now considering using GraphQL, REST, or a combination of REST and GraphQL. We like the GraphQL approach, which the interface can decide which data is returned and see its benefits. But on the other hand, we are worried about caching due to the type of data we store (Product and Product Configurations). At the moment, we see the following options:

• Only using GraphQL . It allows us to speed up the development of our interface and gives our API more flexibility for future implementation. But due to the large number of products we want to use the basic http caching ability and our CDN.

• Only use of REST . Allows us to use a standard HTTP cache for each request, but a specific endpoint is required for each external request.

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

---

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

• Combine both . The idea is to have, for example, a JSON product behind the REST product/1 endpoint that will serve the product data and all configurations. Then it is saved in our backend cache. Then GraphQL can be used by fontend developers to sort the parts of the configuration that a particular view needs (for example: product / 1? Query = SomeGraphQLQuery). Thus, the REST endpoint is for server caching and GraphQL for client caching.

Does this approach make sense in the world of GraphQL, or is it just a useless level of abstraction and doesn't provide any improvement?

Answer 1

Some GraphQL implementations, such as the Apollo client and server, have plugins for the cache, and I have a project that combines REST and graphql, so I cache REST calls in memory (redis), and the results of Graphql queries are cached in the apollo client browser. it works fine, but I think you do not need to combine REST and graphql, as if I are making your project new, I did this because I have no choice to kill the REST API and build everything in graphql, so I just wrap it REST inside graphql to get benefits in the interface. My recommendation is that you continue to work with the schedule and apply caching techniques in queries and clients.

Answer 2

There are several solutions for caching, server and client. I don't think REST has an edge here ...

You have the caching data of your solutions and the pubsub implementation so that you know when they need to clear them, you can also have some kind of caching on the client.

There is no reason to combine the two. And I feel that the real question is not whether it is possible to cache successfully using GraphQL, but rather "How to do it"?