在使用 restful 中，经常发现无法严格按照 restful 规范来设计，结果就是慢慢的变成的一个仅仅是看起来像是 restful 的设计
因此网上找资料发现了 GraphQL，它可以大量节省请求次数，返回字段由前端决定，也不用写文档了，初步了解之下感觉很不错。
但转念一想可能没这么简单，有没有用过的大佬来说说它有什么坑？
相比 restful 的优劣有哪些？
只有一种情况 GraphQL 有用：
当你想把 SQL 数据库查询工作量前置到浏览器的时候。
任何其他情况都不适用， 任何。
如果你的应用是用的 MongoDB 或者任何不是 SQL 的，等着难受吧，恶心死你。
如果你的应用是高度动态的，等着难受吧，恶心死你。
如果你的应用是有分页概念而不是直接查数据库的，等着难受吧，恶心死你。
如果你的应用是你自己设计的有自己的想法会思考，而不是按照丫挺的教程 c-c c-v，等着难受吧，恶心死你
CS 时代后端直接写数据库存储过程，客户端直接用 SQL，权限控制在 DB 里配置，
历史总是惊人的相似。
这里说说感受，restful 实际上是一种约束，它约束 API 设计应该遵循资源规范。用户资源和订单资源是分开的。
但这种设计是方便后端的，按照这种设计，由于业务的组合，前端需要多次发起调用不同资源的 api，就很繁琐了。
实际业务中很难严格遵守这种规范，导致 /users/{id}/orders/{id} 这种情况经常出现。
甚至 /users/getUser 这种完全不是 restful 风格的 api 的出现。
而 graphQL 的结构声明，其实也是 restful 思维的扩展。
现实是，api 的设计过于随意，graphQL 中结构的声明也很少遵从设计原则。依旧是导致资源嵌套很深。
到头来写的二不像。
不过问题是由于耦合很大，所以会导致优化起来难度远比 Restful 方案更麻烦
总结一下个人对 GraphQL 评价
优点：
– schema-driven 的开发流程，衍生出一系列好处：代码生成、精确的接口文档。类比 RESTful 的 swagger 。
– 很容易实现 field 粒度的 ACL
– 良好的类型系统，对 normalization 、cache 、codegen 等都非常友好
– 有官方 spec，不像 RESTful 有各种不同的解读方式（尽管 spec 没有提到分页，但 relay style 已经成为了事实标准）
缺点：
– 各类 HTTP debug 工具支持都很弱
– 大规模 scale out 的实践比较少，缺少成熟的基础设施（ gateway，细粒度监控，日志，限流，等等）
– 很难利用 HTTP cache，需要前端自己实现 cache 系统
– 服务端 n+1 查询问题
– 和 RESTful 一样，只是一种工具，没有官方范式。有人会写嵌套很深的 field，有人会像 RESTful 一样全部扁平化，甚至有人写出来是 RPC style （我见过 root query 顶层 field 全部是 `getXxxByXxx` 的命名风格）
– 使用最广泛的 apollo-client 至今稳定性欠佳，bug 很多
另外看了下大家的回复，都是各执一词，如此来看好不好用只能自己去试试看再说了。