浅谈GraphQL的尴尬
本人某校大二学生，最近忙于数据库课设，其中用到了 GraphQL，碰巧在知乎上看到了GraphQL 为何没有火起来？这个问题，虽然是刚用到 GraphQL，但对于这个问题还是有一点想法，的所以这里就浅浅的聊一下 GraphQL 的尴尬吧。
GraphQL 的好处
因为刚开始用上，没有很深入的去研究 GraphQL 的好处，我只能列出在使用过程中发现的一些好处：
弹性 API 查询
由前端传来的查询参数，需要哪些内容由由前端决定，可多可少，减少返回数据冗余。直接好处就是对于不同的 C 端（Web、App、小程序等），可能需要展示不同的内容，有的数据需要，有的数据不需要，使用 GraphQL 可以不用改后端代码，定制想要的数据字段。
减少路由
RESTful 往往会使用到许多路由，服务器对大量路由的解析会延长响应时间，对于 GraphQL，只需要设置一个路由而不需要大量的路由解析，并且方便 API 的管理。
减少请求次数
根据上面所说的，我们只需要一个路由，并且可以自定义需要的数据字段，那么对于一个页面，完全可以只发送一个请求来获取所有数据。
更少的代码
这是对于服务端来说的，对于查询同一内容，不需要重新再写一遍，只需要一个 resolver 就行了。
更好的前后端联调
在开发前期，只要后端给出 GraphQL 接口或者说 Schema 确定，那么在前端就能够通过 GraphQL PlayGround 很轻松的模拟数据，GraphQL PlayGround 就相当于一份 API 文档。而且因为 GraphQL 严格的类型系统，也直接在开发阶段解决掉了类型不相同的问题。
GraphQL 现状
我认为现在 GraphQL 目前处在一种进退两难的局面之中，2015 年 GraphQL 正式发布，到现在仅仅 5 年的时间，在圈子中颇具影响力，也获得了很多的关注，可以算得上是新秀。这势头太强劲，是导致 GraphQL 现在窘境的一个原因，如果它发展的慢一点，人们可以慢慢的接受，和现在是不一样的局面吧。
首先要肯定的是 GraphQL 必定会成为未来的 API 查询语言，所以人们炒的很火，但在短期内无法改变仍然开发 RESTful 的局面，这就是发展太快带来的窘境吧。明明很强，大家也很喜欢，但用的人不多，作为 GraphQL 表示很尴尬啊。
原因
一个很现实的问题就是，如果一个公司全部都是使用的 RESTful，现在改为使用 GraphQL，那不是要重写了？这对于一个大公司来说是伤筋动骨的事，搞不好服务崩溃，所以对于这些公司来说，继续使用 RESTful 花销会比改用 GraphQL 低得多，GraphQL 带来的好处远不如这些花销。
有些人认为需要前后端都支持是 GraphQL 没有被大量用起来的一个原因，但我对这个说法是不认可的，有需求就有技术支持，究其原因还是上面说的，有需求但没有必要。
兼容方案
为了解决上面这个问题，也有一些兼容性方案。
在课设项目的开发中我使用的是ApolloServer，其中 ApolloServer 提供了两类数据源，一类是 RESTful API 数据源，一类是自定义数据源，RESTful API 数据源允许你不改变 RESTful API 来使用 GraphQL 进行查询，虽然看起来是很友好的，但当你使用 GraphQL 查询的内容令一个 RESTful API 不能完整提供的时候，会带来一些问题，举个简单的例子：
RESTful API 请求的字段都是固定的，前后端设定一致，就是说客户端直接请求 RESTful API，返回的数据中冗余很少，而 GraphQL 查询中需要的内容由前端来定，往往一个 GraphQL 查询会伴随着多个 RESTful API 请求，而最终是不需要用到所有数据的，这就出现了数据冗余，浪费了资源。
而如果 RESTful API 请求和 GraphQL 查询的内容完全吻合，那相比于直接使用 RESTful API 请求，使用 GraphQL 查询多了一次请求，这就是鸡肋的存在啊。
所以我认为这种兼容并不是完美的，反而会带来更多的资源消耗，并没有达到让大家迁移到 GraphQL 的目的。
以上就是入门级码农对 GraphQL 尴尬境地的浅显描述。如果大家有什么想法，欢迎留言评论。
本文作者：KylinLee
本文链接：https://kylin.dev/2020/05/30/浅谈GraphQL的尴尬
版权声明：本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
