都 9102 年了，大家有没有用上 Facebook 出的 GraphQL ？

@Mithril 赞，适用范围内使用就好了

@StarkWhite 没必要像评论里一堆人抓着它的缺点不放，非得拿去干不适合的事情，然后说它垃圾

@dcoder 你看，我同样也能在知乎上找到支持 GraphQL 的回答：
"有人吐槽性能，只想说如果一定要做接口数据聚合这件事的话，GraphQL 遇到的问题几乎都会遇到，而并不是没有方案在解决此类问题。就接口数据聚合这事来说，它目前可能是最优方案。而就接口数据聚合这事需要不需要，个人认为微服务架构下几乎是必须。
还有提到 join 的，会有这个问题，但在微服务架构下，各自分管自己数据库这种场景下不也是一样么，抛弃了一些数据库本身所带来的直接好处以做妥协。如果本来服务粒度划分就很细，不用 GraphQL 同样也会遇到这个问题。"

"总而言之，个人的观点是：一个产品需要整个数据模型架构图之类的东西帮助所有开发人员理解来减少沟通和其他软成本。微服务架构下本就需要不同服务的数据聚合后透出给前端，GraphQL 可能是目前最好的数据聚合方案。后端在标准化的流程下，可以把方向往自动化生成大多数代码上去走，然后在此基础上去做定制化修正和优化，最终其实能极大增加开发效率，也能让不同的开发人员开发出规范雷同的代码，利于以后的维护。"

@StarkWhite
我不觉得有什么很好的方案能解决效率问题，因为 GraphQL 要达到的黑魔法一样的效果，后端的支持必然会比较粗糙.

我们看观点，不看出处. 你引用的这段，看着真的挺 YY 的. 而且我没听说过, micro service 最好是要配套 GraphQL 的.

@dcoder 性能问题只要你做聚合就都会有的，用不用 GraphQL 都一样，也不用期待 GraphQL 能解决本应该用其它方法解决的问题。
其实自己做一个聚合查询的接口也可以，但要自己设计 API，Parser，配套的辅助工具，再给前端后端讲清楚接口。
GraphQL 实际上做的就是这些事，省了你自己设计这 API 的时间。基本上是和 Swagger 类似的地位，也没人指望 Swagger 能解决端口的性能问题吧。

GraphQL 能够帮助解决一部分非描述性接口的性能问题，说不能的只是不知道 GraphQL 请求方描述的内容有什么用、怎么用而已。

@Mithril
GraphQL 的问题是, 它定义了某些高级的可以演义的动态 '语义' 和 '逻辑'.
没有任何成熟的机制，可以保证这些特性被高效可靠地实现.
所以, 其实要做聚合多个 micro service 的查询 api, 直接用死死的 function call 一样的 API 反而简单可靠高效 -- 比如就用 RESTful 之类就行了.

提问：查询比原生查慢一倍
如何优化

@soulzz dataloader

你还可以明早发一条帖子，让更多人看到并回答

加上 prisma 爽的一批

@ysp 感谢支持~

@aomine 是啊哈哈，我公司也在用 prisma

@soulzz 没图没真相，哪有这么大的差距。。。

@dcoder 那你得写多少 if else，光是字段组合就得累死，graphql 可以自动组装字段

@razertory 兄弟 加个联系方式

@finian 兄弟 加个联系方式