I love talking about GraphQL, especially with people who have been working with GraphQL or thinking of adopting GraphQL. One common question people have is why someone would want to move to GraphQL from REST.

我喜欢谈论GraphQL，特别是和那些一直在使用GraphQL或正在考虑采用GraphQL的人谈论。 人们经常遇到的一个问题是，为什么有人想要从REST迁移到GraphQL。

There are a ton of resources out there that talk about the difference between REST and GraphQL and those are great to check out if you are interested in how those two are different. In this blog post, I want to address some common misconceptions and questions asked about GraphQL.

那里有大量的资源谈论REST和GraphQL之间的区别，如果您对这两者之间的差异感兴趣，那么非常有用。 在此博客文章中，我想解决一些常见的误解和有关GraphQL的问题。

您如何从前端的GraphQL中受益？ (How do you benefit from GraphQL on the front end?)

As a Front End Engineer, I like working with a GraphQL API for the following reasons:

作为前端工程师，由于以下原因，我喜欢使用GraphQL API：

1. You can instantly test queries and mutations using GraphiQL or playground
   您可以使用GraphiQL或Playground立即测试查询和变异
2. Less data means lighter state management
   数据更少意味着状态管理更轻松
3. It offloads heavy lifting to the server through resolvers
   它通过解析器将繁重的工作转移到服务器上
4. It has documentation that is up-to-date and interactive
   它具有最新的文档和交互式文档

它比REST好吗？ (How is it better than REST?)

1. There is one endpoint to fetch all resources.
   有一个端点可获取所有资源。
2. You avoid over fetching of data (getting too many fields when only a few fields are needed).
   您可以避免过度获取数据(仅需要几个字段时获取太多字段)。
3. You avoid under fetching of data (having to call multiple APIs because one API doesn't give back all the information needed).
   您可以避免获取数据不足(必须调用多个API，因为一个API不会返回所有需要的信息)。

误解：GraphQL用于查询图形数据库。 (Myth: GraphQL is used to query graph databases.)

GraphQL can be used to query a graph database, but this is not its only use case. The "graph" in GraphQL is used to represent the graph-like structure of data. You model the data in terms of nodes and how they connect to each other. Schema is used to represent this modeling.

GraphQL可用于查询图形数据库，但这不是唯一的用例。 GraphQL中的“图形”用于表示数据的图形结构。 您可以根据节点及其相互连接的方式对数据进行建模。 模式用于表示此建模。

There is no limitation in the GraphQL spec that enforces that the data source should be a graph.

GraphQL规范中没有限制，即数据源应为图形。

误解：GraphQL仅适用于基于图的数据库或数据源。 (Myth: GraphQL only works with databases or data sources that are graph based.)

It's a misconception that you need to rewrite your database to adopt GraphQL. GraphQL can be a wrapper around any data source, including databases. GraphQL is a query language for your API - which means it is a syntax of how to ask for data.

您需要重写数据库以采用GraphQL是一个误解。 GraphQL可以包装任何数据源，包括数据库。 GraphQL是query language for your API的query language for your API -这意味着它是如何查询数据的语法。

误解：使用解析程序，查询和变异进行数据提取会神奇地工作。 (Myth: Data fetching with resolvers, queries and mutations work magically.)

You will need to define exactly what each of them needs to do. You will be writing functions that get called when queries are fired, and writing functions for resolvers that send back exactly the data you need and know which API to call. You will be defining what data return through those functions by calling resolvers.

您将需要确切定义每个人需要做什么。 您将编写在激发查询时被调用的函数，并为解析器编写函数，这些解析器将准确发送回所需的数据并知道要调用的API。 您将通过调用解析器来定义通过这些函数返回的数据。

误解：GraphQL取代了Redux或任何状态管理库 (Myth: GraphQL replaces Redux or any state management library)

Redux is a state management library. GraphQL is not a state management library. GraphQL helps to get less data, which in turn leads to less data to manage on the client-side, but it is not a state management solution.

Redux是一个状态管理库。 GraphQL不是状态管理库。 GraphQL有助于获取更少的数据，从而导致更少的数据需要在客户端进行管理，但这不是状态管理解决方案。

You will still need to manage state - albeit in a more lightweight way. Client libraries like Apollo and Relay can be used to manage state and they have caching built-in. GraphQL is not a replacement for Redux - it helps to reduce the need for it.

您仍然需要管理状态-尽管以更轻量的方式。 客户端库(如Apollo和Relay)可用于管理状态，它们具有内置的缓存。 GraphQL不能代替Redux-它有助于减少对Redux的需求。

误解：GraphQL是一种数据库语言。 (Myth: GraphQL is a database language.)

GraphQL is a programming language - specifically a query language. GraphQL's spec defines how GraphQL runtimes should implement the language and how data should be communicated between client and server.

GraphQL是一种编程语言，特别是一种查询语言。 GraphQL的规范定义了GraphQL运行时应如何实现该语言以及应如何在客户端和服务器之间传递数据。

GraphQL is used to ask for data and can be used in multiple places in any layer from front end to back end. There are databases such as DGraph that implement the GraphQL spec, allowing clients to use GraphQL to query the database.

GraphQL用于请求数据，并且可以在从前端到后端的任何层中的多个位置使用。 有些数据库(例如DGraph)实现了GraphQL规范，从而允许客户端使用GraphQL查询数据库。

误解：使用GraphQL的实现中不能包含REST端点。 (Myth: You can't have REST endpoints in your implementation with GraphQL.)

You can plug in multiple REST endpoints or even multiple GraphQL endpoints in your application. Although it is not a best practice to have multiple REST endpoints, it is technically possible.

您可以在应用程序中插入多个REST端点，甚至多个GraphQL端点。 尽管拥有多个REST端点不是最佳实践，但在技术上是可行的。

误解：GraphQL很难在现有项目中引入。 (Myth: GraphQL is difficult to introduce in an existing project.)

GraphQL can be plugged into an existing project. You can start with one component of business logic, plug in a GraphQL endpoint, and start fetching data through GraphQL. You don't need to scrap an entire project to start using GraphQL.

GraphQL可以插入到现有项目中。 您可以从业务逻辑的一个组件开始，插入GraphQL端点，然后开始通过GraphQL获取数据。 您无需剪贴整个项目即可开始使用GraphQL。

If switching to GraphQL endpoint is still a daunting task, you can start by masking a REST endpoint into a GraphQL endpoint using resolvers.

如果切换到GraphQL端点仍然是一项艰巨的任务，则可以通过使用解析器将REST端点屏蔽到GraphQL端点开始。

误解：GraphQL仅适用于前端开发人员 (Myth: GraphQL is only for front-end developers)

GraphQL is platform agnostic. In my opinion, the beauty of GraphQL's benefits starts from the inside out - back end to front end.

GraphQL与平台无关。 我认为，GraphQL的优势之美始于从内到外-从后端到前端。

As a back end developer, you are able to expand the API by adding fields without having to publish a new version of the API. You don't need to write different endpoints for different needs since clients can fetch whatever data they need.

作为后端开发人员，您可以通过添加字段来扩展API，而不必发布API的新版本。 您无需为不同的需求编写不同的端点，因为客户端可以获取所需的任何数据。

With GraphQL, you have visibility of what fields clients are using, which provides powerful instrumentation.

使用GraphQL，您可以查看客户端使用的字段，从而提供了强大的工具。

误解：GraphQL会自己编写数据库查询，我只需要指定架构及其之间的关系 (Myth: GraphQL will write database queries itself, I just need to specify schemas and the relation between them)

You may need to write the database queries depending on which GraphQL library you are using. However, some libraries like Neo4j and Prisma write database queries too and abstract the logic away from the developer. Everything, including resolvers, queries, and mutations, needs to be defined.

您可能需要编写数据库查询，具体取决于所使用的GraphQL库。 但是，某些库(例如Neo4j和Prisma)也编写数据库查询，并将逻辑抽象给开发人员。 包括解析程序，查询和变异在内的所有内容都需要定义。

误解：GraphQL用于绘制图形。 (Myth: GraphQL is used to draw graphs.)

Often people new to GraphQL think that it is a graph plotting software such as D3. GraphQL doesn't plot graphs.

经常接触GraphQL的人会认为这是一个诸如D3之类的图形绘图软件。 GraphQL不会绘制图形。

误解：GraphQL需要复杂的客户端，并且几乎不可能通过简单的HTTP提取来完成 (Myth: GraphQL requires complicated clients and is near impossible to do with a simple HTTP fetch)

误解：它取代了ORM。 (Myth: It replaces ORMs.)

Lately we see a lot of DB and GraphQL integration but GraphQL itself is not that.

最近，我们看到了很多数据库和GraphQL的集成，但是GraphQL本身不是那样。

I think GraphQL is awesome! There are a multitude of libraries that help a user get started with GraphQL. If you are interested in learning about GraphQL, start with the documentation or check out this Udemy course that I found helpful when I was new to GraphQL.

我认为GraphQL很棒！ 有许多库可以帮助用户开始使用GraphQL。 如果您有兴趣学习GraphQL， 请先阅读 文档，或者查看本本Udemy课程 。

翻译自: https://www.freecodecamp.org/news/what-is-graphql-the-misconceptions/