依据后面的学习，能够发现 GraphQL 带来了很多便当和翻新。具备以下几个次要的劣势：
- 1、缩小数据冗余和申请冗余，能够更获取和应用数据；
- 2、灵便而强类型的 schema，GraphQL 是强类型的，他能够帮忙开发者防止很多问题；
- 3、因为强类型的应用，GraphQL 能够自动化地对收到的数据进行测验；
- 4、GraphQL 不须要进行接口文档保护，它能主动生成，加之其自省性能，能够说很不便；
- 5、进步开发效率，缩小代码变更次数，长期保护老本升高；
只管 GraphQL 有很多劣势，但万物并不是完满的，其也有如下的毛病，正是这些导致其没有被大规模应用：
- 1、成熟的解决方案比拟少，引入 GraphQL 老本略高，危险也不小，这就很大水平上限度了受众；
- 2、减轻前后端利用比重, 前端会带一个 graphql-client，缩短用户等待时间；
- 3、GraphQL 产生大量冗余查问，尽管网络层面的申请数被优化了，但 GraphQL 的每一个实体背地可能对应着不同的数据库甚至不同类型的存储集群，后端集群间的海量数据查问便会成为性能瓶颈。绝对于 resetful, 有显著的降性能的状况；
- 4、GraphQL 的利好次要是在于前端的开发效率，但落地却须要服务端的全力配合，对于曾经成熟的公司技术栈，要推动 GraphQL 还是会遇到各种合作上的阻力；
- 5、谬误提醒不敌对,REST API 的状况下，咱们不须要解析 Response 的内容，只须要看 HTTP status code 和 message，就能晓得申请是否胜利，大略问题是什么，处理错误的程序也非常容易编写。然而 GraphQL 只有 Service 自身还在失常运行，咱们就会失去 200 的 HTTP status，须要专门查看 response 的内容才晓得是否有 error，这时须要全局中间件解决 http error code 到 graph-error 的映射；
总结
GraphQL 最大的劣势，就是它可能大大提高开发者的效率，而且最大化地简化了前端的数据层的复杂性，使得前后端对数据的组织观点统一。但咱们抉择一项技术时，须要考查其 scale、performance、tech stack、migration 等多方面的因素，否则它可能不仅没能提高效率和性能，反倒制作出更多的问题。