PySpa是一个综合的思念体。这是我们在聊天中讨论的总结。这份总结并不是特定某个人的发言，而是多人随意交流的汇总，类似一份神秘的文献。

现在，GraphQL引起了一些轰动。它是由Facebook开发的，并且GitHub也开始提供支持。有人声称GraphQL是REST的未来。不过，当新东西出现时，往往会有人拿旧东西当沙包，然后开口嘲笑：“他还在用这么老旧的东西wwwww”。这已经成为了网络界的一种风景线。然而，为了不被人认为是盲目追随者，我们要冷静地考虑GraphQL的定位以及未来可能出现的趋势。

LSUDs及SSKDs

在《WebAPI The Good Parts》中，Netflix公司的API负责人在文章中提到了一个概念。根据使用WebAPI的用户不同，可以将其分为两大类。

• LSUDs(large set of unknown developers): 大多数の未知の開発者が利用する

SSKDs(small set of known developers): 小数の知っている開発者が利用する

是的，如果你能读到这里并且能够预测到后面的内容，那么你可以关闭这个页面，没问题的。

Facebook和GitHub都以前者为目标。通过公开API，可以构建以自身基础服务为核心的生态系统，进一步提升服务的魅力，这是一项有力的武器。由于未知的外部开发者可能会使用，我们无法知道哪些数据会被如何利用。此外，用户位于慢速网络之外的负载均衡器上。因此，作为服务提供方，需要根据需要返回各种类型的数据，用户只需提取所需数据，这样能获得利益。

当访问企业内部微服务时，首先减少数据量的激励会减少。也就是说，GraphQL的优点会减弱。另外，由于可以在一定程度上了解使用对象，因此可以避免将不确定是否需要大量使用的数据包含在响应中。

此外，人们常常说REST的“显著优势是可以减小大小”，但并不意味着REST不能做同样的事情。Google的API通过添加一个参数fields来提供功能，可以限制包含在响应中的结果的列。这样一来，对现有的REST API进行添加就很容易了。

追加（7/1）

据在其他某个聊天室中讨论的情况来看，尽管将它们批量处理也有优点，但如果使用SSKDs，可以使用BFF：Backend for Frontend，这也是个好方法。此外，当通过Web浏览器发送请求时，Google也提供了使用多部分表单的批量请求。我记得在Microsoft的指南中也看到过，但找不到来源了。

返回克拉萨巴时代的不利之处和优势

GraphQL是一种查询语言。也就是说，它类似于直接发出SQL查询的语言。实际上，它具有简单明了的SQL风格。它和以前的客户-服务器时代做的事情是相同的。以前也有类似于XML数据库的东西。历史总是在重复。但在某种程度上，它在当前阶段有些后退了。

客户端开发人员体验可能确实不错。有预先提供的解析器和可进行语法检查的编辑器库。那么服务器端呢，每个服务器的实现者都需要编写SQL引擎的等效部分。解析器应该是有的（至少在Node.js上是有的）。需要实现的是检查查询并访问存储引擎并对结果进行整形返回的部分。

只查看与ID相关的部分在SQL（或OR Mapper）中获取数据，然后在服务器端进行过滤是一个不太好的方法。这样会给数据库引擎造成不必要的负载，并且在容易发生CPU阻塞的Node.js上执行CPU密集的操作是软件工程的失败。要做得好，需要从GraphQL查询中构建不会有不必要访问的SQL并发送到服务器，但这确实是一个麻烦的过程。处理字段过滤可能还好，但构建一个能正确处理层级结构的中间层似乎很困难（这只是我的想象，因为我从未做过）。

GraphQL成为绝对的赢家有一个条件，那就是出现了使用本地方式实现GraphQL的中间件和数据库引擎，使得GraphQL可以在没有实现服务器代码的情况下轻松处理。这就像是使用SQL的关系型数据库一样，只是这里是GraphQL的版本。

然而，这并不是一个全新的想法，CouchDB应该也是以这样的想法开始的。类似的想法也适用于具备独特基于JSON的查询功能的MongoDB。ArangoDB则集成了一个轻量级的Web服务层，可以用JS编写存储过程。PostgreSQL的JSON支持也在不断发展，而SQLServer则支持用C#编写存储过程。如果这些数据库能进一步演化，并原生支持GraphQL，就能够在不考虑服务器实现负载和性能的情况下使用。尽管会使数据库暴露在互联网上，但可能还存在将其连接到现有存储引擎的中间件或者类似GraphQL-关系型数据库映射器的解决方案。

想到了以后，发现有适用于PostgreSQL的选项。

总结

如果您正在使用LSUD的服务器，那么努力实现GraphQL可能是值得的。至少因为有Github和Facebook的支持，它不太可能在一到两年内过时并被废弃。

在创建服务器的用户是使用SSKDs吗？如果是的话，我认为现在不需要使用它。你可以仅仅作为访问所使用的网络服务的客户端进行使用，不需要急于使用它。或者，你可以等待出现易于使用的中间件或存储引擎，这样也许更好。

（7/1）增补

在我周围没有人支持GraphQL，但问题在于“服务器开发工作量（复杂性集中在此处，包括维护可能很困难）”，所以只要解决这一点，情况就会改变，期待您的反驳意见！

（2019/10/01）添加内容

最近出现了许多支持GraphQL的数据库管理系统，是吧。

• https://supergraph.dev/

https://www.graph.cool/

（2020/03/24）增加说明

据说出现了类似GraphQL的东西。我一直期待着这样的世界观。原本我们不应该像原始人一样手动实现查询转换这种事情。

GraphQL Code Generatorを開発しているThe Guildは、最近GraphQL Meshをリリースしました。これにより、gRPC、OpenAPI、Swagger、SQLなどのデータソースに対してGraphQLクエリを実行することができます。