你应该使用graphql-CSDN博客

At AH Technology we’re continuously looking for new technology to see if we can make our developers faster and happier, make our tech better or develop with more value for money. One of the proof of concepts we did was to see if we should use GraphQL. In this article I describe the findings.

在AH Technology，我们一直在寻找新技术，以查看是否可以使我们的开发人员更快，更快乐，使我们的技术更好，或者以更高的性价比获得发展。我们所做的概念证明之一就是看是否应该使用GraphQL。在本文中，我描述了这些发现。

What is GraphQL?“GraphQL provides a complete description of the data in your API through schemas. It gives clients (apps/websites) the power to ask for exactly the data that they need and nothing more, making it easier to evolve APIs over time and enabling powerful developer tools.” — https://graphql.org/

什么是GraphQL？ “ GraphQL通过模式提供了API中数据的完整描述。它使客户(应用程序/网站)完全有权要求他们所需的数据，仅此而已，这使得随着时间的推移更容易开发API并启用强大的开发人员工具。” -https://graphql.org/

GraphQL was developed by Facebook and first shared with the world in 2015. GraphQL is open source, which means that it no longer belongs to Facebook itself and the code is publicly accessible. Some say is the most beautiful thing Facebook has ever produced, although ReactJS — a front-end framework also used for ah.nl — is a close second and you often see them together.

GraphQL由Facebook开发，于2015年首次与世界共享。GraphQL是开源的，这意味着它不再属于Facebook本身，并且代码可公开访问。有人说这是Facebook有史以来最美丽的东西，尽管ReactJS(也用于ah.nl的前端框架)紧随其后，而且您经常会看到它们。

Most examples I found in other companies where they use GraphQL they use it as an alternative next to REST. Some describe it as the advantages of REST, but without the disadvantages (like backwards compatibility or getting multiple data sources in one query). Also good to know is that GraphQL is under heavy development and stuff that is not standard yet, probably will be in the near future.

我在其他使用GraphQL的公司中发现的大多数示例，都将其用作REST的替代品。有些人将其描述为REST的优点，但没有缺点(例如向后兼容或在一个查询中获得多个数据源)。还要知道的是GraphQL正在大量开发中，尚不标准的东西可能会在不久的将来出现。

GraphQL Versus REST, in 30 seconds

GraphQL与REST在30秒内

How can GraphQL help Albert Heijn?

GraphQL如何帮助Albert Heijn？

Single source of truth.
真理的单一来源。

GraphQL encourages us to align between teams and agree on concepts (e.g. “a list”).
GraphQL鼓励我们在团队之间结盟并就概念(例如“列表”)达成共识。
Currently mobile and web endpoints could (and sometimes do!) return different data for one item, e.g. product price.
当前，移动和Web端点可以(有时甚至可以！)返回一项商品的不同数据，例如产品价格。
Currently we have to maintain alot of endpoints (“BFFs”) for web plus different endpoints for mobile.
当前，我们必须维护许多用于Web的端点(“ BFF”)以及用于移动设备的不同端点。

2. Productivity

2.生产力

Currently domain knowledge is scattered between teams
当前领域知识分散在团队之间
GraphQL makes it possible to redesign the UI without needing to change the backend
GraphQL使得无需更改后端即可重新设计UI
GraphQL stimulates front-end developers to reuse existing code, instead of creating new BFFs.
GraphQL刺激前端开发人员重用现有代码，而不是创建新的BFF。
GraphQL automatically generates API documentation
GraphQL自动生成API文档

3. Better insight into usage

3.更好地了解用法

GraphQL provides insight in what data is used where
GraphQL提供了在哪里使用哪些数据的见解
GraphQL communicates deprecation of fields at development time
GraphQL在开发时传达不赞成使用的字段

4. Performance

4.表现

GraphQL allows app/web to only request the data it actually needs.
GraphQL允许应用程序/网站仅请求其实际需要的数据。

5. Continuously evolve the API to meet the business demands

5.不断发展 API以满足业务需求

Currently it is difficult, thus slow, to change services to meet new business demands without breaking things.
当前，很难在不中断工作的情况下更改服务以满足新的业务需求，因此很慢。
GraphQL is designed with continuous changes in mind.
GraphQL在设计时考虑了不断变化。

Simplified with GraphQL we expect to have:

我们希望通过GraphQL进行简化：

Higher quality code -> less incidents, faster incident resolution
更高质量的代码-> 更少的事件，更快的事件解决
Faster development -> Shorter time to market
发展更快-> 上市时间更短
Less code to maintain -> more capacity to improve performance and scalability
更少的代码需要维护-> 更多的能力来提高性能和可伸缩性
More insights for optimization -> focus on bottlenecks in domain services
更多有关优化的见解-> 关注域服务中的瓶颈
And… we will finally all agree on what data we have, and how we should interpret it -> Happy developers
而且……我们最终将在我们拥有的数据以及如何解释它们上达成共识-> 快乐的开发人员

Why not use GraphQL?

为什么不使用GraphQL？

GraphQL is a powerful tool, and there are many reasons to choose GraphQL over REST as mentioned above. But don’t forget to choose the right tool for the right job.

GraphQL是一个功能强大的工具，如上所述有很多理由选择基于REST的GraphQL。但不要忘记为正确的工作选择正确的工具。

The points I present in the pitfalls may not always apply, but it is worth taking them into account to see if they can be addressed. There are still use cases where REST is a valid approach. Alot of these challenges can be found by Googling for them, many contain possible solutions as well.

我在陷阱中提出的要点可能并不总是适用，但是值得考虑一下它们是否可以解决。在某些情况下，REST是有效的方法。通过谷歌搜索可以找到很多这些挑战，其中许多还包含可能的解决方案。

REST can do much of what GraphQL does
REST可以完成GraphQL的大部分工作

GraphQL is an alternative to REST for developing APIs, not a replacement. The main feature of GraphQL is to be able to send a query specifying only the information you need and get exactly that. But you can also achieve this using REST, from passing the name of the fields you want to use in the URL (implementing the parsing and returning logic yourself):

GraphQL是用于开发API的REST的替代方法，而不是替代方法。 GraphQL的主要功能是能够发送仅指定您需要的信息的查询，并准确地获取该信息。但是，您还可以使用REST实现这一点，方法是在URL中传递要使用的字段名称(自己实现解析和返回逻辑)：

GET /products/217282?fields=title,price

And it is not difficult to implement. There are many JSON API libraries in many languages.

而且实施起来并不难。有许多使用多种语言的JSON API库。

Do you want the benefits of using a schema and strong types in REST? Use JSON schemas.

您是否想要在REST中使用架构和强类型的好处？使用JSON模式。

Do you want to use a query language in REST APIs? Try OData.

您是否要在REST API中使用查询语言？试试OData 。

The point is that there are valid alternatives. Especially for small applications, where using GraphQL may be overkill.

关键是存在有效的替代方法。尤其是对于小型应用程序，在其中使用GraphQL可能会过大。

There are situations where it will be complicated to implement these libraries and for those cases, it may be better to use GraphQL, which natively support all of these features. But GraphQL can also make things more complicated.

在某些情况下，实现这些库会很复杂，对于这些情况，最好使用本机支持所有这些功能的GraphQL。但是GraphQL也会使事情变得更复杂。

2. GraphQL will make some tasks more complex

2. GraphQL将使某些任务更加复杂

Using GraphQL in a simple application (for example, one that uses a few fields in the same way, every time) is not recommended because it adds more complexity because of things such as:

不建议在简单的应用程序中使用GraphQL(例如，每次以相同的方式使用几个字段的应用程序)，因为这样会增加复杂性，例如：

Types
种类
Queries
查询
Mutators
变异者
Resolvers
解析器
High-order components
高阶组件

Which is not good from a maintenance perspective. But even if the use of GraphQL is justified, there may be some complications. Two examples are error handling and file uploading.

从维护的角度来看，这是不好的。但是，即使使用GraphQL是合理的，也可能会出现一些复杂情况。错误处理和文件上传是两个示例。

3. You could have performance issues with GraphQL queries

3. GraphQL查询可能会出现性能问题

A lot of examples in other companies talk about performance issues. The best article i found was: https://blog.graphqleditor.com/GraphQL-Performance-issues-and-how-to-handle-them/ It talks about one of biggest GraphQL flaws: Missing some basic implementation know how which is crucial for application performance. A simple GraphQL server comes without a built-in caching or batching mechanism. This might cause some problems for you apps. Redundant calls … lots of redundant calls

其他公司的许多示例都在讨论性能问题。我发现的最好的文章是： https ://blog.graphqleditor.com/GraphQL-Performance-issues-and-how-to-handle-them/它讨论了GraphQL的最大缺陷之一：缺少一些基本的实现，知道这是怎么回事对于应用程序性能至关重要。一个简单的GraphQL服务器没有内置的缓存或批处理机制。这可能会给您的应用程序带来一些问题。冗余电话…大量冗余电话

决策表 (Decision table)

If you have a majority of B answers, it’s a good idea to investigate more about GraphQL for your project.

如果您有大多数B答案，那么最好为您的项目研究有关GraphQL的更多信息。

结论 (Conclusion)

GraphQL, can be powerful technology that offers a methodology for data retrieval and impacts both API’s provider and consumers. Choosing an API design style will have impact on the whole API lifecycle — From design and implementation to developers experience.

GraphQL，可以是强大的技术为数据检索和影响API的提供者和使用者。选择API设计风格将对整个API生命周期产生影响-从设计和实现到开发人员的经验。

Therefore, when choosing to work with GraphQL, choose it because it solves a problem in a given context, knowing its strengths and weaknesses.

因此，在选择使用GraphQL时，选择它是因为它可以在给定的上下文中解决问题，同时了解其优缺点。

You shouldn’t think of GraphQL as “better” than REST or the “next step”, but rather as an alternative option for a “new relationship between client and data”.

您不应认为GraphQL比REST或“下一步”“更好”，而应作为“客户端和数据之间的新关系”的替代选择。

For AH Technology we were super excited about the advantages of GraphQL and have found ways to deal with the challenges. In our case we did the initial proof of concept with a tech enablement team. In order to do a rollout to production in several areas we needed to transfer knowledge to our DevOps teams running several of our products. We found a lot of interest and enthusiasm of developers for these workshops. We have now started to roll out multiple services using GraphQL to production.

对于AH Technology，我们对GraphQL的优势感到非常兴奋，并找到了应对挑战的方法。在我们的案例中，我们与技术支持团队进行了概念的初步证明。为了在多个领域进行生产，我们需要将知识转移给运行我们多个产品的DevOps团队。对于这些研讨会，我们发现了很多开发人员的兴趣和热情。现在，我们已经开始使用GraphQL将多种服务推出生产环境。

Sources:

资料来源：