使用 GraphQL 的 6 个月 #7013
Merged
使用 GraphQL 的 6 个月 #7013
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
使用 GraphQL 的 6 个月
Closed
|
校对认领 |
|
@JohnieXu 好的呢 🍺 |
JohnieXu
suggested changes
May 6, 2020
|
|
||
| It was developed by Facebook as an internal solution for their mobile apps and was later open-sourced to the community. | ||
| 它由 Facebook 开发，作为其移动应用程序的内部解决方案，后来向社区开放源代码。 |
There was a problem hiding this comment.
后来向社区开放源代码
====>
后来向社区开放了源代码
这样应该更通畅一点
|
|
||
| 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，可以为客户需要的字段指定一个查询，不多也不少。真的就是这么简单。如果**前端**需要一个**人**的**`名字`**和**`年龄`**，直接请求就可以了。他的**`姓`**和**`地址`**并不会作为额外的数据返回。 |
There was a problem hiding this comment.
如果前端需要一个人的**名字和年龄，直接请求就可以了。他的姓和地址**并不会作为额外的数据返回。
======>
如果前端只需要一个人的**名字和年龄字段，直接请求相应的字段就可以了。这个人的姓氏和地址**等其他字段不会返回在请求结果中。
|
|
||
| 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，但是所有并发请求都将被合并起来并呈现给你的批处理加载函数。这使你的应用程序可以安全地在整个应用程序中分发提取数据。 |
There was a problem hiding this comment.
虽然加载器提供了一个加载各个值的 API，但是所有并发请求都将被合并起来并呈现给你的批处理加载函数。这使你的应用程序可以安全地在整个应用程序中分发提取数据。
====>
虽然加载器提供了一个加载各个独立值的 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. | ||
| 这方面的一个例子是，从另一个称为**事务服务**的服务中获取人的银行信息，后端可以从**事务服务**中获取银行信息，然后将结果与人的**`姓名`**和**`年龄`**结合起来后将结果返回。 |
There was a problem hiding this comment.
结合起来后将结果返回
====>
结合起来后作为结果返回
|
|
||
| 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 以查看它们是否可以帮助您的项目时，有必要将它们考虑在内。 |
There was a problem hiding this comment.
这里提到的优缺点可能并不总是适用，但是在查看 GraphQL 以查看它们是否可以帮助您的项目时，有必要将它们考虑在内。
====>
这里提到的优缺点可能并不总适用，但是探索如何借助 GraphQL 来帮助你完成项目是很值得思考的。
稍微意译一下可能更通畅些
|
@fanyijihua 校对认领 |
JohnieXu
previously approved these changes
May 7, 2020
shixi-li
reviewed
May 8, 2020
|
|
||
| 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 中的数据提供了完整且易于理解的描述，并且让用户有权决定他们所需要的东西，除此之外别无他求。 |
|
|
||
| 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 的使用密切相关，因为 你可以在将数据发送给用户之前将它们组合在一起，从而使得公开数据的设计模型变得非常容易。 |
There was a problem hiding this comment.
因为 你可以在将数据发送给用户之前将它们组合在一起
=>
因为你可以在将数据发送给用户之前将它们组合在一起
多了一个空格
|
|
||
| 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 具有的严格类型化架构，因此团队可以并行工作。首先，**前端团队**可以轻松地从后端生成数据模型，而无需查看代码。生成的数据模型可以直接用于创建查询。其次，**前端团队**可以模拟使用该 API。他们还可以使用它来测试代码。这为开发人员提供了愉快的体验，而不会停止他们的开发工作。 |
There was a problem hiding this comment.
这为开发人员提供了愉快的体验，而不会停止他们的开发工作。
=>
这为开发人员提供了愉快的体验，而不会阻塞他们的开发工作。
这一整段我都建议再考虑下，不用非依照原文的断句来翻译，感觉比较奇怪
|
|
||
| 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 查询可以请求资源的任何字段，因此本质上是很难实现缓存的。 |
There was a problem hiding this comment.
缓存 API 响应的目的主要是为了更快地从将来的请求中获取响应。
=>
缓存 API 响应的目的主要是为了更快地为将来的请求获取响应。
|
|
||
| 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 读取数据时，代码有时会分散到多个位置，这可能很难维护。 |
|
|
||
| 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 读取数据时，代码有时会分散到多个位置，这可能很难维护。 |
There was a problem hiding this comment.
所以有时在使用 Dataloader 读取数据时，代码有时会分散到多个位置
=>
所以有时在使用 Dataloader 读取数据时代码会分散到多个位置
lsvih
approved these changes
May 8, 2020
|
@YueYongDev 已经 merge 啦~ 快快麻溜发布到掘金然后给我发下链接，方便及时添加积分哟。 掘金翻译计划有自己的知乎专栏，你也可以投稿哈，推荐使用一个好用的插件。 |
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
译文翻译完成，resolve #6999