使用 GRAPHQL 构建项目的回顾 #4834

EmilyQiRabbit · 2018-12-10T01:48:23Z

译文翻译完成，resolve #4803

EmilyQiRabbit · 2018-12-10T01:48:56Z

@leviding 翻译完成。

leviding · 2018-12-10T02:49:19Z

@EmilyQiRabbit 标题根据文章内容扩展下吧，标题太短不吸引读者

EmilyQiRabbit · 2018-12-10T08:19:00Z

@EmilyQiRabbit 标题根据文章内容扩展下吧，标题太短不吸引读者

好的，会和第一次校对修改一起提交。

Eternaldeath · 2018-12-15T12:37:24Z

申请校对

fanyijihua · 2018-12-15T12:37:28Z

@Eternaldeath 好的呢 🍺

Eternaldeath · 2018-12-16T00:26:32Z

TODO1/graphql-a-retrospective.md


-One of the technologies we invested in was GraphQL. None of us had ever worked with it before, but we judged it to be crucial for delivering quickly and enabling people to work independently.
+我们投资的技术之一就是 GraphQL。我们中之前还从来没有人用过它，但我们认为它对于快速交付以及能让人们独立工作至关重要。


『我们投资的技术之一就是 GraphQL』=> 『我们投入使用的技术之一就是 GraphQL』

Eternaldeath · 2018-12-16T00:32:51Z

TODO1/graphql-a-retrospective.md


-In late 2016, we decided to rewrite our aging PHP legacy system using Python and [React](https://reactjs.org/). With only four months to build an MVP in time for the 2017 festival season, we had to decide very carefully where to invest time.
+在 2016 年末，我们决定用 Python 和 [React](https://reactjs.org/) 重写老旧的 PHP 遗留系统。由于只有四个月的时间来为 2017 年的节日季节建立 MVP，我们必须非常谨慎地决定如何投入时间。


『由于只有四个月的时间来为 2017 年的节日季节建立 MVP』=>『由于只有四个月的时间在 2017 年的节日（到来前）及时建立 MVP （模式开发的系统）』

Eternaldeath · 2018-12-16T00:37:44Z

TODO1/graphql-a-retrospective.md


-Our decision to use [GraphQL](https://graphql.org/) was heavily influenced by lessons learned from our legacy system. We were using REST APIs between a fair number of microservices, which were creating a mess of inconsistent interfaces, varying resource identifiers and incredibly complex deployments. Any API change had to be deployed simultaneously to all services using that API to avoid downtime, which often went wrong and resulted in long release cycles. Using GraphQL in a single API gateway, we would simplify the service landscape drastically. We also decided to use [Relay](https://facebook.github.io/relay/), giving us a single, global way of identifying resources and a straightforward way of organising our GraphQL schema.
+我们从遗留系统学到的教训，大大影响了我们，于是我们决定使用 [GraphQL](https://graphql.org/)。我们在相当数量的维服务之间使用 REST APIS，导致很多混乱，如不兼容的接口，不同的资源标识符和非常复杂的部署。任何 API 的变动都需要同时部署所有使用了这个 API 的服务以避免停机故障，这会经常出现错误并导致很长的发布周期。在单个 API 网关使用 GraphQL，我们将可以大大简化服务格局。我们也决定了使用 [Relay](https://facebook.github.io/relay/)，它为我们提供了一种识别资源的单一的、全局的方式，以及组织 GraphQL 模型的简单方法。


『维服务』=>『微服务』

Eternaldeath · 2018-12-16T00:52:12Z

TODO1/graphql-a-retrospective.md


-We use a single service as our GraphQL server, which in turn makes requests to various backend services – most of which have REST APIs, but because they only communicate with the gateway they’re free to use anything they like. The gateway is designed to be completely stateless, which is great for scalability. Caching happens within the GraphQL gateway, so it’s easy to scale up our whole system by just scaling up the number of gateway instances.
+我们使用单一服务作为 GraphQL 服务，它反过来会请求各种后端服务 -- 其中大部分是 REST APIs，但是因为它们都只和网关通信，所以它们可以使用任何想用的接口。网关被设计为完全无状态的，这对于可扩展性大有裨益。缓存也是在 GraphQL 网关中，因此，只需扩大网关实例的数量，就可以轻松扩展整个系统。


『我们使用单一服务作为 GraphQL 服务』=>『我们使用单一服务作为 GraphQL 服务器』

Eternaldeath · 2018-12-16T00:59:04Z

TODO1/graphql-a-retrospective.md


-The API Gateway is the **only** way that services communicate with each other, which cuts down complexity drastically. It also creates a great central location for caching, scaling, monitoring and profiling. Generally, having a single service responsible for so many things isn’t a great idea – it’s a single point of failure.
+API 网关是服务通信的**唯一**途径，这就大大降低了复杂度。它还为缓存，缩放，监视和分析创建了一个很好的中心位置。一般来说，只有一项服务负责这么多事情并不是一个好主意 -- 而是一个故障点。


『API 网关是服务通信的唯一途径』=>『API 网关是服务相互通信的唯一途径』

Eternaldeath · 2018-12-16T01:03:14Z

TODO1/graphql-a-retrospective.md


-However, the API Gateway is **stateless**. It has no database, no local resources and no authentication. This means it can be horizontally scaled extremely easily, and because it’s also responsible for caching, just increasing the number of gateway instances helps significantly with traffic spikes.
+但是，API 网关是**无状态的**。它没有数据库，没有本地资源也没有认证。这意味着它可以在水平方向上缩放自如，同时因为它还负责了缓存，所以仅增加网关实例的数量就有助于显著增加流量。


『所以仅增加网关实例的数量就有助于显著增加流量』=>『所以仅增加网关实例的数量就有助于显著解决流量高峰（的问题）』

Eternaldeath · 2018-12-16T01:08:46Z

TODO1/graphql-a-retrospective.md


 [![GraphQL Code](https://verve.co/wp-content/uploads/2018/11/Verve_GraphQL_Code_3.png)](https://verve.co/wp-content/uploads/2018/11/Verve_GraphQL_Code_3.png)

-The API wrapper for the GraphQL schema is completely auto-generated from the graphene schema, so the services don’t even need a copy of the schema file. There are no wasted requests, authentication is handled transparently in the background and fields are lazily resolved as they are accessed.
+GraphQL 模型的 API 包裹器是完全从 graphene schema 自动生成的。所以，服务甚至不需要模型文件的副本。没有多余的请求，身份验证在后台透明处理，字段在访问时会被懒惰地解析。


『字段在访问时会被懒惰地解析』=>『字段在访问时会被延迟解析』

Eternaldeath · 2018-12-16T01:16:35Z

TODO1/graphql-a-retrospective.md


-We use graphene and graphene-django to actually run our server. We don’t use graphene-django’s ability to map [Django](https://www.djangoproject.com/) models automatically because all data comes from external requests, we only use it for compatibility with the rest of our stack and its familiarity. The whole gateway server is essentially just a single GraphQLView, which we have extended slightly to allow for some improvements for our frontend:
+我们使用 graphene 和 graphene-django 来运行服务，我们不使用 graphene-django 自动映射 [Django](https://www.djangoproject.com/) 模型的能力，因为所有的数据都来自外部请求，我们只使用它来与我们的堆栈的其余部分兼容并熟悉它。整个网关服务实际上就是一个单独的 GraphQLView，我们做了一点小小的扩充来允许我们对前端做出优化：


『我们使用 graphene 和 graphene-django 来运行服务』=>『我们使用 graphene 和 graphene-django 来实际运行服务器』

Eternaldeath · 2018-12-16T01:20:59Z

TODO1/graphql-a-retrospective.md

-*   Monitoring: the GraphQLView is a great place to add various bits of performance monitoring. We track execution time per query, hashing the queries to make it easy to aggregate response times for the same query with different inputs.
+*   我们将报错信息优化，用以将 Django REST Framework 错误从后端服务中分解出来。DRF 每个字段可能有不止一个错误，但它在原生 graphene-django 中并不起作用，所以我们扩展了视图，用来为每个字段提供精确的错误信息。
+*   我们扩展了错误日志，以便更容易地报告各种错误信息。例如 4xx 错误实际意味着用户错误，但是由于网关调用了另一个不同的 API，它同样也意味着网关错误的使用了我们的 API。DRF 不会记录后台服务的 4xx 错误，因此，当实际上是我们而不是用户导致的错误时，我们会在网关中执行此操作。
+*   监控：GraphQLView 是添加各种性能监控的绝佳位置。我们追踪每个请求的执行时间，对查询进行散列，以便合计不同参数的同一请求的响应时间。


『GraphQLView 是添加各种性能监控的绝佳位置』=>『GraphQLView 是添加各种性能监控位的绝佳位置』

bits 没有翻译出来

Eternaldeath · 2018-12-16T01:27:02Z

TODO1/graphql-a-retrospective.md


-GraphQL is great for us, but we also made plenty of mistakes. We sometimes struggle with keeping our API truly backwards-compatible and had to invest in extra monitoring for deprecated fields in addition to performance monitoring and better error reporting. Updating the GraphQL schema with every API change manually can be tedious, and by making it extremely easy to communicate between backend services via GraphQL we accidentally broke some of our own service boundaries. But in the end, it has helped us develop faster while keeping the mental model of our infrastructure easy and giving our teams significantly more autonomy.
+GraphQL 对我们大有益处，但是我们也犯了很多错误。有时候我们会努力保持我们的 API 是真正向后兼容的，并且除了性能监控和更好的错误报告，还需要为了弃用的字段投入额外的监控。每次 API 变化就需要手动更新 GraphQL 模型，这相当乏味，通过 GraphQL，我们使得后台服务的通信变得非常容易，但却意外地破坏了一些服务的边界。但是最后，它帮助我们更快地发展，同时保持了基础设施核心模型的简易，并使我们的团队更加自主。


不知道是不是我感觉有问题，机翻的地方较多，很多地方的翻译比较生硬

leviding · 2018-12-16T03:34:52Z

@EmilyQiRabbit 可以修改啦

EmilyQiRabbit · 2018-12-18T02:31:16Z

@leviding 校对完成～
@Eternaldeath 感谢～

leviding · 2018-12-18T08:14:01Z

@EmilyQiRabbit 已经 merge 啦~ 快快麻溜发布到掘金然后给我发下链接，方便及时添加积分哟。

掘金翻译计划有自己的知乎专栏，你也可以投稿哈，推荐使用一个好用的插件。
专栏地址：https://zhuanlan.zhihu.com/juejinfanyi

leviding · 2018-12-24T06:59:04Z

今天下午更新积分，请注意查收

Update graphql-a-retrospective.md

46b1cd5

fanyijihua added the 校对认领 label Dec 10, 2018

fanyijihua mentioned this pull request Dec 10, 2018

GRAPHQL 回顾 #4803

Closed

EmilyQiRabbit changed the title ~~Update graphql-a-retrospective.md~~ GRAPHQL 回顾 Dec 10, 2018

leviding added the 前端 label Dec 10, 2018

EmilyQiRabbit changed the title ~~GRAPHQL 回顾~~ 关于使用 GRAPHQL 构建项目的回顾 Dec 10, 2018

EmilyQiRabbit changed the title ~~关于使用 GRAPHQL 构建项目的回顾~~ 使用 GRAPHQL 构建项目的回顾 Dec 10, 2018

fanyijihua added the 正在校对 label Dec 15, 2018

Eternaldeath reviewed Dec 16, 2018

View reviewed changes

leviding added the enhancement 等待译者修改 label Dec 16, 2018

Update graphql-a-retrospective.md

bd204bf

leviding added 标注待管理员 Review and removed enhancement 等待译者修改校对认领 labels Dec 18, 2018

leviding approved these changes Dec 18, 2018

View reviewed changes

leviding merged commit 94432d6 into xitu:master Dec 18, 2018

leviding added 翻译完成 and removed 标注待管理员 Review 正在校对 labels Dec 18, 2018

EmilyQiRabbit deleted the translation/GraphQL-A-RETROSPECTIVE branch June 19, 2019 06:45

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

使用 GRAPHQL 构建项目的回顾 #4834

使用 GRAPHQL 构建项目的回顾 #4834

EmilyQiRabbit commented Dec 10, 2018

EmilyQiRabbit commented Dec 10, 2018

leviding commented Dec 10, 2018

EmilyQiRabbit commented Dec 10, 2018

Eternaldeath commented Dec 15, 2018

fanyijihua commented Dec 15, 2018

Eternaldeath Dec 16, 2018

Eternaldeath Dec 16, 2018

Eternaldeath Dec 16, 2018

Eternaldeath Dec 16, 2018

Eternaldeath Dec 16, 2018

Eternaldeath Dec 16, 2018

Eternaldeath Dec 16, 2018

Eternaldeath Dec 16, 2018

Eternaldeath Dec 16, 2018

Eternaldeath Dec 16, 2018

leviding commented Dec 16, 2018

EmilyQiRabbit commented Dec 18, 2018

leviding commented Dec 18, 2018

leviding commented Dec 24, 2018


		One of the technologies we invested in was GraphQL. None of us had ever worked with it before, but we judged it to be crucial for delivering quickly and enabling people to work independently.
		我们投资的技术之一就是 GraphQL。我们中之前还从来没有人用过它，但我们认为它对于快速交付以及能让人们独立工作至关重要。


		In late 2016, we decided to rewrite our aging PHP legacy system using Python and [React](https://reactjs.org/). With only four months to build an MVP in time for the 2017 festival season, we had to decide very carefully where to invest time.
		在 2016 年末，我们决定用 Python 和 [React](https://reactjs.org/) 重写老旧的 PHP 遗留系统。由于只有四个月的时间来为 2017 年的节日季节建立 MVP，我们必须非常谨慎地决定如何投入时间。


		Our decision to use [GraphQL](https://graphql.org/) was heavily influenced by lessons learned from our legacy system. We were using REST APIs between a fair number of microservices, which were creating a mess of inconsistent interfaces, varying resource identifiers and incredibly complex deployments. Any API change had to be deployed simultaneously to all services using that API to avoid downtime, which often went wrong and resulted in long release cycles. Using GraphQL in a single API gateway, we would simplify the service landscape drastically. We also decided to use [Relay](https://facebook.github.io/relay/), giving us a single, global way of identifying resources and a straightforward way of organising our GraphQL schema.
		我们从遗留系统学到的教训，大大影响了我们，于是我们决定使用 [GraphQL](https://graphql.org/)。我们在相当数量的维服务之间使用 REST APIS，导致很多混乱，如不兼容的接口，不同的资源标识符和非常复杂的部署。任何 API 的变动都需要同时部署所有使用了这个 API 的服务以避免停机故障，这会经常出现错误并导致很长的发布周期。在单个 API 网关使用 GraphQL，我们将可以大大简化服务格局。我们也决定了使用 [Relay](https://facebook.github.io/relay/)，它为我们提供了一种识别资源的单一的、全局的方式，以及组织 GraphQL 模型的简单方法。


		We use a single service as our GraphQL server, which in turn makes requests to various backend services – most of which have REST APIs, but because they only communicate with the gateway they’re free to use anything they like. The gateway is designed to be completely stateless, which is great for scalability. Caching happens within the GraphQL gateway, so it’s easy to scale up our whole system by just scaling up the number of gateway instances.
		我们使用单一服务作为 GraphQL 服务，它反过来会请求各种后端服务 -- 其中大部分是 REST APIs，但是因为它们都只和网关通信，所以它们可以使用任何想用的接口。网关被设计为完全无状态的，这对于可扩展性大有裨益。缓存也是在 GraphQL 网关中，因此，只需扩大网关实例的数量，就可以轻松扩展整个系统。


		The API Gateway is the only way that services communicate with each other, which cuts down complexity drastically. It also creates a great central location for caching, scaling, monitoring and profiling. Generally, having a single service responsible for so many things isn’t a great idea – it’s a single point of failure.
		API 网关是服务通信的唯一途径，这就大大降低了复杂度。它还为缓存，缩放，监视和分析创建了一个很好的中心位置。一般来说，只有一项服务负责这么多事情并不是一个好主意 -- 而是一个故障点。


		However, the API Gateway is stateless. It has no database, no local resources and no authentication. This means it can be horizontally scaled extremely easily, and because it’s also responsible for caching, just increasing the number of gateway instances helps significantly with traffic spikes.
		但是，API 网关是无状态的。它没有数据库，没有本地资源也没有认证。这意味着它可以在水平方向上缩放自如，同时因为它还负责了缓存，所以仅增加网关实例的数量就有助于显著增加流量。


		We use graphene and graphene-django to actually run our server. We don’t use graphene-django’s ability to map [Django](https://www.djangoproject.com/) models automatically because all data comes from external requests, we only use it for compatibility with the rest of our stack and its familiarity. The whole gateway server is essentially just a single GraphQLView, which we have extended slightly to allow for some improvements for our frontend:
		我们使用 graphene 和 graphene-django 来运行服务，我们不使用 graphene-django 自动映射 [Django](https://www.djangoproject.com/) 模型的能力，因为所有的数据都来自外部请求，我们只使用它来与我们的堆栈的其余部分兼容并熟悉它。整个网关服务实际上就是一个单独的 GraphQLView，我们做了一点小小的扩充来允许我们对前端做出优化：


		GraphQL is great for us, but we also made plenty of mistakes. We sometimes struggle with keeping our API truly backwards-compatible and had to invest in extra monitoring for deprecated fields in addition to performance monitoring and better error reporting. Updating the GraphQL schema with every API change manually can be tedious, and by making it extremely easy to communicate between backend services via GraphQL we accidentally broke some of our own service boundaries. But in the end, it has helped us develop faster while keeping the mental model of our infrastructure easy and giving our teams significantly more autonomy.
		GraphQL 对我们大有益处，但是我们也犯了很多错误。有时候我们会努力保持我们的 API 是真正向后兼容的，并且除了性能监控和更好的错误报告，还需要为了弃用的字段投入额外的监控。每次 API 变化就需要手动更新 GraphQL 模型，这相当乏味，通过 GraphQL，我们使得后台服务的通信变得非常容易，但却意外地破坏了一些服务的边界。但是最后，它帮助我们更快地发展，同时保持了基础设施核心模型的简易，并使我们的团队更加自主。

使用 GRAPHQL 构建项目的回顾 #4834

使用 GRAPHQL 构建项目的回顾 #4834

Conversation

EmilyQiRabbit commented Dec 10, 2018

EmilyQiRabbit commented Dec 10, 2018

leviding commented Dec 10, 2018

EmilyQiRabbit commented Dec 10, 2018

Eternaldeath commented Dec 15, 2018

fanyijihua commented Dec 15, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

leviding commented Dec 16, 2018

EmilyQiRabbit commented Dec 18, 2018

leviding commented Dec 18, 2018

leviding commented Dec 24, 2018