我们正在构建一个请求很多的API，现在考虑使用GraphQL，REST或REST和GraphQL的组合。我们喜欢前端可以决定的GraphQL方法，返回哪些数据并查看其优点。但另一方面，由于我们存储的数据类型（产品和产品配置），我们担心缓存。目前我们看到以下选项：
仅使用GraphQL ：允许我们加快前端开发，并为我们的API提供更大的灵活性，以便将来实施。但是，通过大量的产品，我们希望使用基本的http缓存功能和我们的CDN。
仅使用REST ：允许我们在每个请求中使用标准http缓存，但每个前端请求都需要一个已定义的端点。
所以基本上我想知道GraphQL的缓存能力是否与REST相同？
作为一个加号，我们考虑将它组合起来。这样做的原因是我们有一个后端缓存来缓存来自后端系统的数据：
product/1后面有一个产品JSON，它将提供产品数据和所有配置。然后将其保存在我们的后端缓存中。然后，前端开发人员可以使用GraphQL来整理特定视图所需的配置部分（例如：product / 1？query = SomeGraphQLQuery'）。因此，REST-Endpoint用于服务器缓存，而GraphQL用于客户端缓存。这种方法在'GraphQL'世界中是否有意义，还是只是一个无用的抽象层并没有带来改进？
答案 0 :(得分：1)
像Apollo客户端和服务器这样的GraphQL的一些实现具有用于缓存的插件，并且我有一个组合REST和graphql的项目，因此我在内存中缓存REST调用（redis）并且在浏览器中缓存Graphql查询结果apollo客户端，它工作得很好，但我认为你不需要结合REST和graphql，因为我确实导致你的项目是新的，我做了这个因为我没有选择杀死REST API并在graphql中构建所有，所以我只将REST包装在graphql中以获得前端的好处。我的建议是继续使用graphql并在查询调用和客户端使用者中应用缓存技术。
答案 1 :(得分：0)
缓存，服务器和客户端有多种解决方案。我不认为REST在这里有优势......
您可以让解析器缓存数据并实现pubsub以了解何时需要清除它们，您也可以在客户端上进行某种缓存。
没有理由把两者结合起来。而且我觉得真正的问题不是你是否可以使用GraphQL成功缓存，而是＃34;以哪种方式做到这一点＆＃34;？