使用 GraphQL 的 6 个月

article/2020/6-months-of-using-graphql.md

@@ -1,73 +1,73 @@
-> * 原文地址：[6 Months Of Using GraphQL](https://levelup.gitconnected.com/6-months-of-using-graphql-faa0fb68b4af)
-> * 原文作者：[Manish Jain](https://medium.com/@jaiin.maniish)
-> * 译文出自：[掘金翻译计划](https://github.com/xitu/gold-miner)
-> * 本文永久链接：[https://github.com/xitu/gold-miner/blob/master/article/2020/6-months-of-using-graphql.md](https://github.com/xitu/gold-miner/blob/master/article/2020/6-months-of-using-graphql.md)
-> * 译者：
-> * 校对者：
+> - 原文地址：[6 Months Of Using GraphQL](https://levelup.gitconnected.com/6-months-of-using-graphql-faa0fb68b4af)
+> - 原文作者：[Manish Jain](https://medium.com/@jaiin.maniish)
+> - 译文出自：[掘金翻译计划](https://github.com/xitu/gold-miner)
+> - 本文永久链接：[https://github.com/xitu/gold-miner/blob/master/article/2020/6-months-of-using-graphql.md](https://github.com/xitu/gold-miner/blob/master/article/2020/6-months-of-using-graphql.md)
+> - 译者：[YueYongDEV](https://github.com/YueYongDev)
+> - 校对者：[JohnieXu](https://github.com/JohnieXu)、[cyril](https://github.com/shixi-li)
 
-# 6 Months Of Using GraphQL
+# 使用 GraphQL 的 6 个月
 
-Having worked on a project for 6 months using GraphQL on the backend, I weigh up the technology’s fit into the development workflow
+在使用 GraphQL 进行了 6 个月的后端项目开发后，我开始考量该技术是否适合在开发工作中使用。
 
 ![The output from my terminal](https://cdn-images-1.medium.com/max/2526/1*SYo5JVMz3D79G_OEfs8q_g.png)
 
-## First and Foremost
+## 首先
 
-GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API as well as gives clients the power to ask for exactly what they need and nothing more.
+GraphQL 是一种实现 API 的查询语言，也是使用现有数据完成这些查询的运行时。GraphQL 为你的 API 中的数据提供了完整且易于理解的描述，并且让用户有权决定他们所需要的东西，仅此而已。
 
-It was developed by Facebook as an internal solution for their mobile apps and was later open-sourced to the community.
+它由 Facebook 开发，作为其移动应用程序的内部解决方案，后来向社区开放了源代码。
 
-## The good
+## 优点
 
-#### Pragmatic Data Exchange
+#### 务实的数据交换
 
-With GraphQL, the query can be defined for the fields which the client needs, nothing more and nothing less. It’s really that simple. If the **frontend** needs `**first name**` and `**age**` of a **person**, it can only ask for that. The `**last name**` and `**address**` of the `**person**` would not be sent in the response.
+使用 GraphQL，可以为客户需要的字段指定一个查询，不多也不少。真的就是这么简单。如果**前端**只需要一个人的**`名字`**和**`年龄`**字段，直接请求相应的字段就可以了。这个人的**`姓氏`**和**`地址`**等其他字段不会返回在请求结果中。
 
-#### Using Dataloaders to Reduce Network Calls
+#### 使用数据加载器（Dataloaders）减少网络调用
 
-Although Dataloaders are not a part of the GraphQL library itself it is a utility library that can be used to decouple unrelated parts of your application without sacrificing the performance of batch data-loading. While the loader presents an API that loads individual values, all concurrent requests will be combined and presented to your batch loading function. This allows your application to safely distribute data fetching throughout your application.
+虽然 Dataloaders 不是 GraphQL 库本身的一部分，但是它的确是一个很有用的第三方库，可以用来解耦应用程序中不相关的部分，同时不会牺牲批量数据加载的性能。虽然加载器提供了一个加载各个独立值的 API，但是所有并发请求都将被合并起来才分送给你的批处理加载函数。这使你的应用程序可以安全地在整个应用程序进行数据的分发与获取。
 
-An example of this would be fetching `**bank details**` of the `**person**` from a different service called **transaction service**, the **backend** can fetch the `**bank details**` from the **transaction service** and then combine that result with the `**first name**` and the `**age**` of the `**person**` and send the resource back.
+这方面的一个例子是，从另一个称为**事务服务**的服务中获取人的银行信息，后端可以从**事务服务**中获取银行信息，然后将结果与人的**`姓名`**和**`年龄`**结合起来后作为结果返回。
 
-#### Decoupling between exposed data and database models
+#### 公开数据和数据库模型之间的解耦
 
-One of the great things about GraphQL is the option to decouple the database modeling data with how the data is exposed to consumers. This way when designing our persistence layer, we could focus on the needs of that layer and then separately think about what's the best way to expose the data to the outside world. This goes hand in hand with the usage of Dataloaders since you can combine your data together before sending it to the users it becomes really easy to design the models for exposed data.
+GraphQL 的一大优点是可以将数据库建模数据和给用户公开的数据解耦。这样，在设计持久层时，我们可以专注于该层的需求，然后分别考虑如何采取最好的方式将数据暴露给使用者。这与 dataloader 的使用密切相关，因为你可以在将数据发送给用户之前将它们组合在一起，从而使得公开数据的设计模型变得非常容易。
 
-#### Forget about versioning of APIs
+#### 忘记 API 的版本控制
 
-Versioning of APIs is a common problem and generally, it is fairly simple to solve by adding a new version of the same APIs by appending a **v2** in front of it. With GraphQL the story is different, you can have the same solution here but that is not going to go well with the spirit of GraphQL. The documentation clearly states that you should evolve your APIs meaning adding more fields to an existing endpoint would not break your API. The frontend can still query using the same API and can ask for the new field if needed. Pretty simple.
+API 的版本控制是一个常见问题，通常一个简单的解决方案是，在相同的 API 前面添加一个**v2**标识。但一旦有了 GraphQL，情况就不同了。虽然你仍然可以使用相同的解决方案，但这与 GraphQL 的理念不合。官方文档明确指出你应该改进你的 API，这意味着向已有端点添加更多的字段并不会破坏原有的 API。前端仍然可以使用相同的 API 进行查询，并且可以根据需要查询新字段。这种处理方式真的很巧妙。
 
-This particular feature is really useful when it comes to collaborating with the frontend team. They can make a request to add a new field that is required because of the design change and the backend can easily add that field without messing with the existing API.
+在与前端团队协作时，这个特性非常有用。他们可以发出请求，并添加由于设计更改而需要的新字段，而后端可以轻松地添加该字段，同时不会破坏现有的 API。
 
-#### Independent Teams
+#### 独立团队
 
-With GraphQL, the front-end and back-end teams can work independently. With the strictly typed schema that GraphQL has, the teams can work in parallel. Firstly the **frontend team** can easily generate a schema from the backend without even looking at the code. The schema generated can directly be used to create queries. Secondly, the **frontend** **team** can continue working with just a mock version of the API. They can also test the code with it. This gives the developers a pleasant experience without stalling their development work.
+使用 GraphQL，前端和后端可以独立工作。因为 GraphQL 具有严格的类型化架构，因此两个团队可以并行工作互不影响。首先，**前端**无需查看后端代码即可轻松地生成数据模型，且生成的数据模型可以直接用于创建数据查询。其次，**前端**可以使用模拟（mock）出来的 API 来测试代码。这样便不会阻碍前后端的开发工作，大大的提升了程序员的开发体验。
 
 ![Photo by [Perry Grone](https://unsplash.com/@perrygrone?utm_source=medium&utm_medium=referral) on [Unsplash](https://unsplash.com?utm_source=medium&utm_medium=referral)](https://cdn-images-1.medium.com/max/10944/0*ClSi_KEJVSWlHwUL)
 
-## The bad
+## 缺点
 
-#### Not all APIs can be evolved
+#### 并非所有的 API 都能改进
 
-Sometimes there would be changes trickling down from the business or design which would require a complete change in the implementation of an API. In that case, you would have to rely on the old ways to do the versioning.
+有时，会因业务或设计而产生一些变化，这需要对 API 的实现进行彻底更改。在这种情况下，你将不得不依靠旧的方式进行版本控制。
 
-#### Unreadable code
+#### 不可读的代码
 
-As experienced multiple times, the code sometimes can become scattered into multiple places while using Dataloaders to fetch the data and that could be difficult to maintain.
+由于经历了多次迭代，所以有时在使用 Dataloader 读取数据时代码会分散到多个位置，这可能很难维护。
 
-#### Longer response times
+#### 响应时间更长
 
-Since the queries can evolve and become huge, it can sometimes take a toll on the response time. To avoid this, make sure to keep the response resources concise. For guidelines have a look at the [Github GraphQL API.](https://developer.github.com/v4/)
+由于查询会不断发展并变得臃肿，因此有可能会延长响应时间。为避免这种情况，请确保简明扼要的响应资源。有关指导原则，请查看[Github GraphQL API。](https://developer.github.com/v4/)
 
-#### Caching
+#### 缓存
 
-The goal of caching an API response is primarily to obtain the response from future requests faster. Unlike GraphQL, caching is built into in the HTTP specification which RESTful APIs are able to leverage. And as mentioned earlier a GraphQL query can ask for any field of a resource, caching is inherently difficult.
+缓存 API 响应的目的主要是为了更快地从将来的请求中获取响应。与 GraphQL 不同，RESTful API 可以利用 HTTP 规范中内置的缓存。正如前面提到的，GraphQL 查询可以请求资源的任何字段，因此本质上是很难实现缓存的。
 
-## Conclusion
+## 结论
 
-I will highly recommend using GraphQL as a replacement for REST APIs. The flexibility offered by GraphQL definitely supersedes the pain points it has. The good and bad points mentioned here may not always apply, but it is worth taking them into consideration while looking at GraphQL to see if they can help your project.
+我强烈建议使用 GraphQL 替代 REST API。GraphQL 所提供的灵活性绝对可以取代它的痛点。这里提到的优缺点可能并不总适用，但是探索如何借助 GraphQL 来帮助你完成项目是很值得思考的。
 
-If you have any comments, please post them below.
+如果你有任何意见，请在下面回复。
 
 > 如果发现译文存在错误或其他需要改进的地方，欢迎到 [掘金翻译计划](https://github.com/xitu/gold-miner) 对译文进行修改并 PR，也可获得相应奖励积分。文章开头的 **本文永久链接** 即为本文在 GitHub 上的 MarkDown 链接。