随着系统业务量的增大不同的应用和系统共同使用着许多的服务api，而随着业务的变化和发展，不同的应用对相同资源的不同使用方法最终会导致需要维护的服务api数量呈现爆炸式的增长，比如我试着跑了下我们自己业务里的接口数量，线上正在运行的就有超过1000多个接口，非常不利于维护。而另一方面，创建一个大而全的通用性接口又非常不利于移动端使用（流量损耗），而且后端数据的无意义聚合也对整个系统带来了很大的资源浪费。
graphql介绍
graphql的方案完美的解决了以上所有问题，连大名鼎鼎GitHub也抛弃了自己非常优秀的REST API接口，全面拥抱graphql了。
GraphQL是Facebook 在2012年开发的，2015年开源，2016年下半年Facebook宣布可以在生产环境使用，而其内部早就已经广泛应用了，用于替代 REST API。facebook的解决方案和简单：用一个“聪明”的节点来进行复杂的查询，将数据按照客户端的要求传回去，后端根据GraphQL机制提供一个具有强大功能的接口，用以满足前端数据的个性化需求，既保证了多样性，又控制了接口数量。
GraphQL并不是一门程序语言或者框架，它是描述你的请求数据的一种规范，是协议而非存储，GraphQL本身并不直接提供后端存储的能力，它不绑定任何的数据库或者存储引擎，它可以利用已有的代码和技术来进行数据源管理。
一个GraphQL查询是一个被发往服务端的字符串，该查询在服务端被解释和执行后返回JSON数据给客户端。
和Rest Api的对比
RESTful：服务端决定有哪些数据获取方式，客户端只能挑选使用，如果数据过于冗余也只能默默接收再对数据进行处理；而数据不能满足需求则需要请求更多的接口。
GraphQL：给客户端自主选择数据内容的能力，客户端完全自主决定获取信息的内容，服务端负责精确的返回目标数据。
为什么推荐用GraphQL方案
说人话就是：减少工作量,后端一个接口前端进行查询
专业一点：提供一种更严格、可扩展、可维护的数据查询方式
优点
能为老板节省几个亿的流量（由前端定义需要哪些字段
再也不需要对接口的文档进行维护了（自动生成文档，代码里定义的结构就是文档
再也不用加班了（真正做到一个接口适用多个场景
再也不用改bug了（强类型，自动校验入参出参类型
新人再也不用培训了（所有的接口都在一颗数下，一目了然
再也不用前端去写假数据了（代码里定义好结构之后自动生成mock接口
再不用痛苦的联调了（代码里定义好结构之后，自动生成接口在线调试工具，直接在界面里写请求语句来调试返回，而且调试的时候各种自动补全
react/vue/express/koa无缝接入（relay方案/apollo方案
更容易写底层的工具去监控每个接口的请求统计信息（都在同一个端点的请求下
不限语言，除了官方提供的js实现，其他所有的语言都有社区的实现
生态是真的好啊，有各种方便易用的开发者工具GraphQL存在的问题
graphQl也不是没有缺点，主要有以下几个缺点：
改造成本
要使用GraphQL对数据源进行管理，相当于要对整个服务端进行一次换血。你需要考虑的不仅仅是需要针对现有数据源建立一套GraphQL的类型系统，同时需要改造服务端暴露数据的方式，这对业务久远的产品无疑是一场灾难，让人望而却步。
查询性能
GraphQL查询的每个字段如果都有自己的resolve方法，可能导致一次查询操作对数据库跑了大量了query，数据库里一趟select+join就能完成的事情在这里看来会产生大量的数据库查询操作，虽然网络层面的请求数被优化了，但是数据库查询可能会成为性能瓶颈。但是这个其实是可以优化，反正就算是用rest api，同时处理多个请求的时候，也总要运行那些数据库语句的。
369
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
