在后端使用GraphQL进行了6个月的项目开发后，我权衡了该技术是否适合开发工作流程

　　首要的

　　GraphQL是用于API的查询语言，也是用于使用现有数据来完成这些查询的运行时。 GraphQL为您的API中的数据提供了完整且易于理解的描述，并且使客户有权要求他们确切需要什么，仅此而已。

　　它是由Facebook开发的，作为其移动应用程序的内部解决方案，后来被开源给社区。

　　好的务实的数据交换

　　使用GraphQL，可以为客户需要的字段定义查询，仅此而已。 真的就是这么简单。 如果前端需要一个人的名字和年龄，则只能要求。 该人的姓氏和地址不会在回复中发送。

　　使用数据加载器减少网络呼叫

　　尽管数据加载器本身不是GraphQL库的一部分，但它是一个实用程序库，可用于解耦应用程序中不相关的部分，而不会影响批处理数据加载的性能。 加载程序提供了一个加载单个值的API时，所有并发请求将被合并并呈现给您的批量加载功能。 这使您的应用程序可以安全地在整个应用程序中分发数据提取。

　　公开数据与数据库模型之间的解耦

　　GraphQL的一大优点是可以将数据库建模数据与如何将数据公开给使用者分离。 这样，在设计持久层时，我们可以专注于该层的需求，然后分别考虑将数据公开给外部世界的最佳方法。 这与数据加载器的使用紧密结合，因为您可以在将数据发送给用户之前将它们组合在一起，从而为暴露数据设计模型变得非常容易。

　　忘记API的版本控制

　　API的版本控制是一个常见问题，通常，通过在其前面添加v2来添加相同API的新版本来解决它相当简单。 有了GraphQL，情况就不同了，您可以在此处拥有相同的解决方案，但是这与GraphQL的精神并不合适。 该文档明确指出您应该改进API，这意味着向现有端点添加更多字段不会破坏您的API。 前端仍然可以使用相同的API进行查询，并且可以根据需要询问新字段。 很简单

　　与前端团队合作时，此特定功能非常有用。 他们可以请求添加由于设计更改而需要的新字段，并且后端可以轻松添加该字段而不会弄乱现有的API。

　　独立团队

　　使用GraphQL，前端团队和后端团队可以独立工作。 使用GraphQL具有的严格类型化架构，团队可以并行工作。 首先，前端团队可以轻松地从后端生成模式，而无需查看代码。 生成的架构可以直接用于创建查询。 其次，前端团队可以继续使用该API的模拟版本。 他们还可以使用它来测试代码。 这为开发人员提供了愉快的体验，而不会停止他们的开发工作。

　　不好并非所有的API都能进化

　　有时，会因业务或设计而产生一些变化，这需要对API的实现进行彻底更改。 在这种情况下，您将不得不依靠旧的方式进行版本控制。

　　无法读取的代码

　　由于经历了多次，所以有时在使用Dataloader读取数据时，代码有时会分散到多个位置，这可能很难维护。

　　响应时间更长

　　由于查询会不断发展并变得庞大，因此有时可能会浪费响应时间。 为避免这种情况，请确保简明扼要的响应资源。 有关指导原则，请查看Github GraphQL API。

　　快取

　　缓存API响应的目的主要是为了更快地从将来的请求中获取响应。 与GraphQL不同，RESTful API可以利用HTTP规范中内置的缓存。 正如前面提到的，GraphQL查询可以请求资源的任何字段，因此缓存本质上是困难的。

　　结论

　　我强烈建议使用GraphQL替代REST API。 GraphQL所提供的灵活性绝对可以取代它的痛点。 这里提到的优缺点可能并不总是适用，但是在查看GraphQL以查看它们是否可以帮助您的项目时，有必要将它们考虑在内。

　　如果您有任何意见，请在下面发布。