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/