document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-10 22:21:11 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #17941 from wxy/20190612-Why-use-GraphQL

Browse Source 
TSL:20190612 Why use GraphQL.md
This commit is contained in:
Xingyu.Wang 2020-03-31 16:03:50 +08:00 committed by GitHub
commit 5d91c1262d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 91 additions and 97 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

97
sources/tech/20190612 Why use GraphQL.md
View File

@ -1,97 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: (wxy)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Why use GraphQL?)
[#]: via: (https://opensource.com/article/19/6/why-use-graphql)
[#]: author: (Zach Lendon https://opensource.com/users/zachlendon/users/goncasousa/users/patrickhousley)
Why use GraphQL?
======
Here's why GraphQL is gaining ground on standard REST API technology.
![][1]
[GraphQL][2], as I wrote [previously][3], is a next-generation API technology that is transforming both how client applications communicate with backend systems and how backend systems are designed.
As a result of the support that began with the organization that founded it, Facebook, and continues with the backing of other technology giants such as Github, Twitter, and AirBnB, GraphQL's place as a linchpin technology for application systems seems secure; both now and long into the future.
### GraphQL's ascent
The rise in importance of mobile application performance and organizational agility has provided booster rockets for GraphQL's ascent to the top of modern enterprise architectures.
Given that [REST][4] is a wildly popular architectural style that already allows mechanisms for data interaction, what advantages does this new technology provide over [REST][4]? The ‘QL’ in GraphQL stands for query language, and that is a great place to start.
The ease at which different client applications within an organization can query only the data they need with GraphQL usurps alternative REST approaches and delivers real-world application performance boosts. With traditional [REST][4] API endpoints, client applications interrogate a server resource, and receive a response containing all the data that matches the request. If a successful response from a [REST][4] API endpoint returns 35 fields, the client application receives 35 fields
### Fetching problems
[REST][4] APIs traditionally provide no clean way for client applications to retrieve or update only the data they care about. This is often described as the “over-fetching” problem. With the prevalence of mobile applications in people’s day to day lives, the over-fetching problem has real world consequences. Every request a mobile application needs to make, every byte it has to send and receive, has an increasingly negative performance impact for end users. Users with slower data connections are particularly affected by suboptimal API design choices. Customers who experience poor performance using mobile applications are more likely to not purchase products and use services. Inefficient API designs cost companies money.
“Over-fetching” isn’t alone - it has a partner in crime - “under-fetching”. Endpoints that, by default, return only a portion of the data a client actually needs require clients to make additional calls to satisfy their data needs - which requires additional HTTP requests. Because of the over and under fetching problems and their impact on client application performance, an API technology that facilitates efficient fetching has a chance to catch fire in the marketplace - and GraphQL has boldly jumped in and filled that void.
### REST's response
[REST][4] API designers, not willing to go down without a fight, have attempted to counter the mobile application performance problem through a mix of:
* “include” and “exclude” query parameters, allowing client applications to specify which fields they want through a potentially long query format.
* “Composite” services, which combine multiple endpoints in a way that allow client applications to be more efficient in the number of requests they make and the data they receive.
While these patterns are a valiant attempt by the [REST][4] API community to address challenges mobile clients face, they fall short in a few key regards, namely:
* Include and exclude query key/value pairs quickly get messy, in particular for deeper object graphs that require a nested dot notation syntax (or similar) to target data to include and exclude. Additionally, debugging issues with the query string in this model often requires manually breaking up a URL.
* Server implementations for include and exclude queries are often custom, as there is no standard way for server-based applications to handle the use of include and exclude queries, just as there is no standard way for include and exclude queries to be defined.
* The rise of composite services creates more tightly coupled back-end and front-end systems, requiring increasing coordination to deliver projects and turning once agile projects back to waterfall. This coordination and coupling has the painful side effect of slowing organizational agility. Additionally, composite services are by definition, not RESTful.
### GraphQL's genesis
For Facebook, GraphQL’s genesis was a response to pain felt and experiences learned from an HTML5-based version of their flagship mobile application back in 2011-2012. Understanding that improved performance was paramount, Facebook engineers realized that they needed a new API design to ensure peak performance. Likely taking the above [REST][4] limitations into consideration, and with needing to support different needs of a number of API clients, one can begin to understand the early seeds of what led co-creators Lee Byron and Dan Schaeffer, Facebook employees at the time, to create what has become known as GraphQL.
With what is often a single GraphQL endpoint, through the GraphQL query language, client applications are able to reduce, often significantly, the number of network calls they need to make, and ensure that they only are retrieving the data they need. In many ways, this harkens back to earlier models of web programming, where client application code would directly query back-end systems - some might remember writing SQL queries with JSTL on JSPs 10-15 years ago for example!
The biggest difference now is with GraphQL, we have a specification that is implemented across a variety of client and server languages and libraries. And with GraphQL being an API technology, we have decoupled the back-end and front-end application systems by introducing an intermediary GraphQL application layer that provides a mechanism to access organizational data in a manner that aligns with an organization’s business domain(s).
Beyond solving technical challenges experienced by software engineering teams, GraphQL has also been a boost to organizational agility, in particular in the enterprise. GraphQL-enabled organizational agility increases are commonly attributable to the following:
* Rather than creating new endpoints when 1 or more new fields are needed by clients, GraphQL API designers and developers are able to include those fields in existing graph implementations, exposing new capabilities in a fashion that requires less development effort and less change across application systems.
* By encouraging API design teams to focus more on defining their object graph and be less focused on what client applications are delivering, the speed at which front-end and back-end software teams deliver solutions for customers has increasingly decoupled.
### Considerations before adoption
Despite GraphQL’s compelling benefits, GraphQL is not without its implementation challenges. A few examples include:
* Caching mechanisms around [REST][4] APIs are much more mature.
* The patterns used to build APIs using [REST][4] are much more well established.
* While engineers may be more attracted to newer technologies like GraphQL, the talent pool in the marketplace is much broader for building [REST][4]-based solutions vs. GraphQL.
### Conclusion
By providing both a boost to performance and organizational agility, GraphQL's adoption by companies has skyrocketed in the past few years. It does, however, have some maturing to do in comparison to the RESTful ecosystem of API design.
One of the great benefits of GraphQL is that it’s not designed as a wholesale replacement for alternative API solutions. Instead, GraphQL can be implemented to complement or enhance existing APIs. As a result, companies are encouraged to explore incrementally adopting GraphQL where it makes the most sense for them - where they find it has the greatest positive impact on application performance and organizational agility.
--------------------------------------------------------------------------------
via: https://opensource.com/article/19/6/why-use-graphql
作者：[Zach Lendon][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/zachlendon/users/goncasousa/users/patrickhousley
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/metrics_graph_stats_blue.png?itok=OKCc_60D
[2]: https://graphql.org/
[3]: https://opensource.com/article/19/6/what-is-graphql
[4]: https://en.wikipedia.org/wiki/Representational_state_transfer

91
translated/tech/20190612 Why use GraphQL.md Normal file
View File

@ -0,0 +1,91 @@
[#]: collector: (lujun9972)
[#]: translator: (wxy)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Why use GraphQL?)
[#]: via: (https://opensource.com/article/19/6/why-use-graphql)
[#]: author: (Zach Lendon https://opensource.com/users/zachlendon/users/goncasousa/users/patrickhousley)
为什么使用 GraphQL?
======
> 这就是 GraphQL 在标准 REST API 技术上获得发展的原因。
[][1]
正如我[以前][3]所写，[GraphQL][2] 是下一代 API 技术，它正在改变客户端应用程序与后端系统的通信方式以及后端系统的设计方式。
由于一开始就从创建它的组织 Facebook 获得了支持，并得到了其他技术巨头（如 Github、Twitter 和 AirBnB）的支持，因此 GraphQL 作为应用程序系统的关键技术的地位似乎是可靠的 —— 无论现在还是将来。
### GraphQL 在崛起
移动应用程序性能和组织敏捷性重要性的提高为 GraphQL 登上现代企业体系结构的顶端提供了助推器。
鉴于 [REST][4] 是一种非常流行的体系结构风格，早已提供了数据交互机制，与 [REST][4] 相比，GraphQL 这项新技术具有哪些优势？GraphQL 中的 “QL” 代表查询语言，而这是一个很好的起点。
借助 GraphQL，组织内的不同客户端应用程序可以轻松地仅查询所需数据，从而取代了其他 REST 方法，并提高了实际应用程序的性能。 使用传统的 [REST][4] API 端点，客户端应用程序将详询服务器资源，并接收包含了与请求匹配的所有数据的响应。如果来自 [REST][4] API 端点的成功响应返回 35 个字段，那么客户端应用程序就会接收 35 个字段。
### 提取的问题
传统上，[REST][4] API 无法为客户端应用程序提供简便的方法来仅检索或更新它们关心的数据。这通常被描述为“<ruby>过度获取<rt>over-fetching</rt></ruby>”的问题。随着移动应用程序在人们的日常生活中的普遍使用，过度获取问题会给现实世界带来不良后果。移动应用程序需要发出的每个请求都必须发送和接收的每个字节，对最终用户的性能造成的负面影响越来越大。数据连接速度较慢的用户尤其会受到不太好的 API 设计方案的影响。在性能体验不佳时，使用移动应用程序的客户更有可能不购买产品或不使用服务。低效的 API 设计只会浪费公司的钱。
并非只有“过度获取”是问题，“欠缺获取”同样也是问题。默认情况下，仅返回客户端实际需要的部分数据的端点或许会要求客户端进行其他调用以满足其数据需求，这就需要其他的 HTTP 请求。由于过度和欠缺的获取问题及其对客户端应用程序性能的影响，促进有效获取的 API 技术才有机会在市场上引起轰动 —— GraphQL 大胆地介入并填补了这一空白。
### REST 的应对
[REST][4] API 设计师不战而退，他们尝试通过以下几种方式来应对移动应用程序性能问题：
* “include” 和 “exclude” 查询参数，允许客户端应用程序通过可能较长的查询格式来指定所需的字段。
* “复合”服务，组合了多个端点，以使客户端应用程序在其发出的请求数量和接收到的数据方面更高效。
  
尽管这些模式是 [REST][4] API 社区为解决移动客户端所面临的挑战而做出的英勇尝试，但它们在以下几个关键方面仍存在不足：
* 包含和排除查询的键/值对很快变得混乱，特别是对于需要嵌套“点表示法”语法（或类似方法）以包含和排除更深的目标数据的对象图而言。此外，在此模型中调试查询字符串的问题通常需要手动分解 URL。
* 包含和排除查询的服务器实现通常是自定义的，因为基于服务器的应用程序没有标准的方式来处理包含和排除查询的使用，就像没有定义包含和排除查询的标准方式一样。
* 复合服务的兴起创建了更加紧密耦合的后端和前端系统，需要加强协调以交付项目，并且一旦将敏捷项目转回瀑布式。这种协调和耦合顺便还能稍减组织敏捷性的痛苦。此外，根据定义，组合服务不是 RESTful。
  
### GraphQL 的起源
对于 Facebook 来说，从其 2011-2012 年基于 HTML5 版本的旗舰移动应用程序中感受到的痛点和体验，才造就了 GraphQL。Facebook 工程师意识到提高性能至关重要，因此意识到他们需要一种新的 API 设计来确保最佳性能。可能考虑到以上 [REST][4] 的局限性，并且需要支持许多 API 客户端的不同需求，因此人们开始去了解其共同创建者 Lee Byron 和 Dan Schaeffer（那时尚是 Facebook 员工）撒播下的早期种子，创建了后来被称之为 GraphQL 的技术。
通过 GraphQL 查询语言，客户端（通常是单个 GraphQL 端点）应用程序通常可以显著减少所需的网络调用数量，并确保仅检索所需的数据。在许多方面，这可以追溯到早期的 Web 编程模型，在该模型中，客户端应用程序代码将直接查询后端系统，有些人可能还记得 10 到 15 年前在 JSP 上用 JSTL 编写 SQL 查询吧！
现在最大的区别是使用 GraphQL，我们有了一个跨多种客户端和服务器语言和库实现的规范。借助 GraphQL 这样一种 API 技术，我们通过引入 GraphQL 应用程序中间层来分离后端和前端应用程序系统，该层提供了一种以与组织的业务领域相一致的方式来访问组织数据的机制。
除了解决软件工程团队遇到的技术挑战之外，GraphQL 还促进了组织敏捷性的提高，特别是在企业中。启用 GraphQL 的组织敏捷性通常归因于以下因素：
* GraphQL API 设计人员和开发人员无需在客户端需要一个或多个新字段时创建新的端点，而是能够将这些字段包含在现有的图形实现中，从而以较少的开发工作量和跨应用程序系统的较少更改的方式公开新功能。
* 通过鼓励 API 设计团队将更多的精力放在定义对象图上，而不是在专注于客户端应用程序交付上，前端和后端软件团队为客户交付解决方案的速度日益解耦。
  
### 采纳之前的注意事项
尽管 GraphQL 具有引人注目的优势，但 GraphQL 并非没有实施挑战。一些例子包括：
* 为 [REST][4] API 建立的缓存机制更加成熟。
* 用于使用 [REST][4] 来构建 API 的模式已经非常完善。
* 尽管工程师可能更喜欢 GraphQL 等新技术，但与 GraphQL 相比，市场上的人才库更多是从事于构建基于 [REST][4] 的解决方案。
### 结论
通过同时提高性能和组织敏捷性，GraphQL 在公司中的采纳在过去几年中猛增。但是，与 RESTful API 设计生态系统相比，它确实还需要更成熟一些。
GraphQL 的一大优点是，它并不是作为替代 API 解决方案的批发替代品而设计的。相反，可以实现 GraphQL 来补充或增强现有的 API。因此，鼓励公司探索逐步采用 GraphQL 的方法，这对他们来说最有意义，他们发现它对应用程序性能和组织敏捷性具有最大的积极影响。
--------------------------------------------------------------------------------
via: https://opensource.com/article/19/6/why-use-graphql
作者：[Zach Lendon][a]
选题：[lujun9972][b]
译者：[wxy](https://github.com/wxy)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/zachlendon/users/goncasousa/users/patrickhousley
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/metrics_graph_stats_blue.png?itok=OKCc_60D
[2]: https://graphql.org/
[3]: https://opensource.com/article/19/6/what-is-graphql
[4]: https://en.wikipedia.org/wiki/Representational_state_transfer