GraphQL 是否具有与 REST 相同的缓存能力答案

【问题标题】：Does GraphQL has the same caching ability as RESTGraphQL 是否具有与 REST 相同的缓存能力
【发布时间】：2017-05-24 00:42:24
【问题描述】：

我们正在构建一个需求量很大的 API，现在正在考虑使用 GraphQL、REST 或 REST 和 GraphQL 的组合。我们喜欢前端可以决定返回哪些数据并看到它的好处的 GraphQL 方法。但另一方面，由于我们存储的数据类型（产品和产品配置），我们担心缓存。目前我们看到以下选项：

仅使用 GraphQL：允许我们加快前端开发并为我们的 API 提供更大的灵活性以供将来实施。但是通过大量的产品，我们希望使用基本的 http 缓存能力和我们的 CDN。
仅使用 REST：允许我们对每个请求使用标准 http 缓存，但需要为每个前端请求定义一个端点。

所以基本上我想知道GraphQL的缓存能力和REST一样吗？

作为一个优点，我们考虑将它结合起来。这样做的原因是我们有一个后端缓存来缓存来自后端系统的数据：

结合两者：想法是在 REST 端点 product/1 后面有一个产品 JSON，它将为产品数据和所有配置提供服务。然后将其保存在我们的后端缓存中。然后 GraphQL 可以被 fontend 开发人员用来整理特定视图需要的配置部分（例如：product/1?query=SomeGraphQLQuery'）。所以 REST-Endpoint 用于服务器缓存，GraphQL 用于客户端缓存。

这种方法在“GraphQL”世界中是否有意义，或者它只是一个无用的抽象层并且没有带来任何改进？

【问题讨论】：

标签： rest caching graphql

【解决方案1】：

GraphQL 的一些实现，如 Apollo 客户端和服务器具有缓存插件，我有一个结合 REST 和 graphql 的项目，所以我将 REST 调用缓存在内存 (redis) 中，Graphql 查询结果缓存在浏览器中apollo 客户端，它工作得很好，但我认为你不需要像我一样将 REST 和 graphql 结合起来，因为你的项目是新的，我这样做是因为我没有选择杀死 REST API 并在 graphql 中构建所有内容，所以我仅将 REST 包装在 graphql 中以获得前端的好处。我的建议是继续使用 graphql，并在查询调用和客户端消费者中应用缓存技术。

【讨论】：

【解决方案2】：

缓存、服务器端和客户端有多种解决方案。我认为 REST 在这里没有优势……

您可以让解析器缓存数据并实现 pubsub 以了解何时需要清除它，您也可以在客户端上进行某种缓存。

没有理由将两者结合起来。而且我觉得真正的问题不是你能不能用 GraphQL 成功缓存，而是“用哪种方式来做”？

【讨论】：

REST 绝对可以如果您想依赖 HTTP 中间体（例如 CDN 或其他代理）的自动缓存，则绝对有优势。要使用 GraphQL 进行这项工作，需要中间人理解 GraphQL，我不知道有什么。
同意以上评论。说 graphQL 具有与 REST 相同的缓存能力是一厢情愿的想法。 Apollo 必须在 graphQL 之上绑定自己的缓存约定，但它仍然没有 HTTP 缓存那么简单和强大。