管理多个graphql_使用GraphQL的6个月

管理多个graphql

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

本文绝不是GraphQL与REST的比较。 有很多文章都提供了非常详细的信息。 我将分享我使用该框架的经验以及它如何影响我们的开发速度和团队之间的协作。

首要的

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

它是由Facebook开发的，作为其移动应用程序的内部解决方案，后来被开源给社区。 从那时起，它就在开发人员中广泛流行，并已成为构建服务的最喜欢的解决方案。

它如何适合？

1.实用数据交换

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

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

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

这方面的一个例子是由称为交易业务的不同服务获取的人的银行信息 ， 后端可以获取从交易服务的银行详细信息 ，然后该结果结合了名字和人的年龄和发送资源返还。

3.忘记API的版本控制

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

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

4.独立团队

使用GraphQL，前端团队和后端团队可以独立工作。 使用GraphQL具有的严格类型化架构，团队可以并行工作。 首先， 前端团队可以轻松地从后端生成模式，而无需查看代码。

生成的架构可以直接用于创建查询。 其次， 前端 团队可以继续使用该API的模拟版本。 他们还可以使用它来测试代码。 这为开发人员提供了愉快的体验，而不会停止他们的开发工作。

并非适合所有人

1.并非所有的API都能进化

有时候，从业务或设计中进行细化可能会带来一些变化，这将需要对API的实现进行彻底的更改。 在这种情况下，您将不得不依靠旧的方式进行版本控制。

2.不可读的代码

就像现在经历了很多次一样，使用Dataloader读取数据时，有时代码有时会分散到多个位置，从而可能难以维护。

3.响应时间更长

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

4.缓存

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

翻译自: https://hackernoon.com/6-months-of-using-graphql-dq2o3yyl

管理多个graphql