GraphQL
前后端关于CMDB的交互决定选用GraphQL，因为第一次听说就抓紧时间了解了以下是个什么东西。
GraphQL干嘛的？
GraphQL语言致力于提供一种直观的弹性语法系统，用以描述客户端程序设计时的数据需求以及数据交互行为。
说的直白点就是能让API设计变得更加的灵活，你想要什么数据就给你什么数据，不多不少。
实践
目前只有CMDB那一块使用的GraphQL，其它的前后端交互还是用的传统的方式。
不过这并不影响我对它的兴趣，新东西总是喜欢琢磨琢磨，更何况GraphQL有大厂的背书，那证明它的潜力是巨大地。
- 传统的api设计，如果想要多种场景公用一个接口，比如都是获取用户信息，A场景需要name，B场景需要name+sex，C场景需要name+introduction，很显然都是获取用户信息，但是每个场景要求的数据不一样，如果简单粗暴的直接返回整个用户信息，很显然不太科学，极端一点假设用户有20个字段，调用方只需要一个字段，你给20个字段完全是浪费，另一种方案是写三个接口，但是三个接口很显然太冗余了，所以通常是公用一个接口，但是共有一个接口就肯定免不了一堆逻辑判断,此外，这样还会造成不同业务之间的耦合，每次发布都需要各个业务场景一起测试和回归。
这种时候痛点就出现了，不重用接口则没法提高开发效率，重用接口则会有这些问题。
这个时候GraphQL就体现它的优势了，我认为它的出现就是为了解决上面的痛点。出现上面的问题的根本原因我认为在于，前端不能直白的告诉后端我要什么数据，必须通过后端经过对应的翻译转换，因为前端没有合适的方式来告诉我们A只需要name，B只需要name+sex，它可能就给我们一个userId然后给个businessCase然后我们根据businessCase来进行逻辑判断，进行数据查询，进行数据筛选以及过滤。
GraphQL
花点时间写这个，是因为觉得GraphQL算是开阔了我的技术视野，我们其实还用的很浅，他的一切皆是图、API无版本（某些场景）的思想，以及schema、别名、片段、指令、mutation、元字段等概念让GraphQL灵活的像猴哥，至少目前我们没有遇到有什么场景是满足不了的，至少对于技术浅薄的我来说是有开到脑洞。
学习地址：
这是我用nodejs实现的很简单的demo：
这是通过howtographql搭建的demo
https://flaviocopes.com/graphql-vs-rest/
本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。