它是什么？ (What is it?)
GraphQL is a query language to retrieve data from the server. It can be taken as an alternative to REST, SOAP, or gRPC in some way.Built for Facebook’s internal use and later made open source. Today it powers hundreds of billions of API calls a day for Facebook and being used extensively by many others.
GraphQL是用于从服务器检索数据的查询语言。 它可以以某种方式替代REST，SOAP或gRPC.Built供Facebook内部使用，后来成为开源。 如今，它每天为Facebook提供数千亿个API调用，并被许多其他人广泛使用。
为什么命名为GraphQL？ (Why name, GraphQL?)
So as we know GraphQL is not a query language for graph databases but it is still an appropriate name because it queries the graph of your application data.
因此，我们知道GraphQL并不是图数据库的查询语言，但它仍然是一个合适的名称，因为它查询应用程序数据的图。
为什么Facebook随附GraphQL？ (Why did Facebook come with GraphQL?)
Facebook’s developers were frustrated with the differences between the data they wanted to use in their apps and the server queries they required.
Facebook的开发人员对他们想要在其应用程序中使用的数据与所需的服务器查询之间的差异感到沮丧。
They didn’t think of data in terms of resource URLs, secondary keys, or join tables; they thought about it in terms of a graph of objects and the models they ultimately use in their apps like NSObjects or JSON.
他们没有从资源URL，辅助键或联接表的角度考虑数据。 他们从对象图和最终在其应用程序(如NSObjects或JSON)中使用的模型的角度考虑了这一问题。
There was also a considerable amount of code to write on both the server and the client. The server had to prepare the data and the client had to parse it.
在服务器和客户端上也要编写大量的代码。 服务器必须准备数据，而客户端必须解析数据。
The conflict in the app’s API requirements and server’s implementation can lead to serious performance issues and overall bad UX when we operate at a scale of billions of hits per day.And that's what happened with Facebook.
当我们以每秒数十亿day.And命中这与Facebook发生了什么事的经营规模在应用程序的API要求和服务器的实现的冲突可能会导致严重的性能问题和总体不良UX。
As Facebook’s mobile apps became more complex and accessible, they suffered from poor performance and frequent crashes.
随着Facebook的移动应用变得越来越复杂和易于使用，它们遭受了性能低下和频繁崩溃的困扰。
可以通过以下基本示例解释此冲突： (This conflict can be explained via the following basic example:)
Facebook App requesting posts, comments, and likes from facebook’s server.And the single post view looks like the following in facebook’s news feed.
Facebook App从Facebook的服务器上请求帖子，评论和喜欢的消息，而单个帖子视图则类似于Facebook新闻提要中的以下内容。
We can see here that more than one resource is required to power a single post view. i.e. Post Details, Author, likes count, comment, and share count.And in the real world applications most of the views would require more than one resource to power a single view.
我们在这里可以看到，需要一个以上的资源来提供一个单一的视图。 例如，发帖详细信息，作者喜欢计数，评论和共享计数。在现实世界中，大多数视图将需要多个资源来支持一个视图。
How to fulfill this use case?
如何实现这个用例？
Let’s say in a single
/postscall we fetch everything related to a post. i.e. fetching list of likes, comments along with each post.假设在一个
/posts调用中，我们获取与/posts相关的所有内容。 即获取喜欢列表，评论以及每个帖子。This is called
这就是所谓的
over-fetching.
过度获取。
But the cons of this approach are that we are sending unnecessary data that wouldn’t be consumed always.
但是这种方法的缺点是我们正在发送不必要的数据，这些数据不会总是被使用。
Also, it leads to more computation at the server and more bandwidth consumption at the client, in a way leading to bad user experience.
另外，它还会导致服务器上的更多计算和客户端上的更多带宽消耗，从而导致不良的用户体验。
To have separate APIs for each type of resource and for each use case.
为每种类型的资源和每种用例具有单独的API。
i.e. Separate resources to fetch likes and comments.
即单独的资源来获取喜欢和评论。
This is called
这就是所谓的
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.
提取不足。 默认情况下，仅返回客户端实际需要的部分数据的端点要求客户端进行其他调用以满足其数据需求-这需要其他HTTP请求。
Again leading to bad UX and more efforts by developers.
再次导致不良的UX和开发人员的更多努力。
The frustration due to the aforementioned limitations inspired Facebook developers to start the project that ultimately became GraphQL. Using GraphQL they wanted to rethink mobile app data-fetching from the perspective of product designers and developers. It moved the focus of development to the client applications, where designers and developers spend their time and attention.
由于上述限制而产生的挫败感促使Facebook开发人员开始了最终成为GraphQL的项目。 他们希望使用GraphQL从产品设计师和开发人员的角度重新考虑移动应用程序的数据获取。 它把开发重点转移到了客户端应用程序上， 设计人员和开发人员在那里花费时间和精力。
Facebook如何使用GraphQL解决此问题 (How did Facebook solve this using GraphQL)
GraphQL provides the following features out of the box which helped Facebook to overcome the above-described problems.
GraphQL开箱即用地提供以下功能，这些功能帮助Facebook克服了上述问题。
1.强类型： (1. Strongly Typed:)
One very important property of GraphQL is that it is strongly typed i.e. the server knows exactly the shape of every object client can query and any client can actually introspect the server and ask for the so-called schema.Hence GraphQL response returns the data in the same format a query has requested it from.
GraphQL的一个非常重要的特性是它是强类型的，即服务器确切知道客户端可以查询的每个对象的形状，并且任何客户端都可以实际对服务器进行内部检查并请求所谓的模式 。因此GraphQL响应将返回对象中的数据。查询请求的格式相同。
GraphQL SchemaIt describes the shape of the data graph a client can query. i.e. what all queries are possible and what fields you can get back.
GraphQL模式描述客户端可以查询的数据图的形状。 即所有查询都是可能的，您可以取回哪些字段。
Object Typetype represents the type of objects you can query and fetch from the server.
对象类型类型表示您可以从服务器查询和获取的对象类型。
GraphQL QueryThe Query type is the same as regular objectType but it is special because its the entry point of the GraphQL API. And using a string query the client requests data from the server which in result interprets the request, fulfills it, and returns JSON back to the client.
GraphQL查询查询类型与常规objectType相同，但是它很特殊，因为它是GraphQL API的入口点。 并使用字符串查询，客户端从服务器请求数据，结果解释该请求，执行该请求，然后将JSON返回给客户端。
Below given is the schema for facebook’s post kind of structure.
下面给出的是Facebook帖子类型结构的架构。
type Post {
id: String!
title: String!
description: String
comments: [Comment]
likes:[Like]
}
type Comment{
id:String
}
type Like{
id:String
}
# The Root Query for the application
type Query {
recentPosts(count: Int, offset: Int): [Post]!
}
# The Root Mutation for the application
type Mutation {
writePost(title: String!, category: String) : Post!
}2.避免过度获取 (2. Avoids OverFetching)
GraphQL allows you to avoid over-fetching.Whenever a client requests for any field/data at that time only our server does the computation required to fetch it.For the above-given schema using recentPosts(count: Int, offset: Int) query to fetch the desired data.
GraphQL可以避免过度获取。 每当客户当时请求任何字段/数据时，只有我们的服务器才会执行获取该字段/数据所需的计算。对于上述提供的模式，使用lastPosts(count：Int，offset：Int)查询来获取所需的数据。
3.避免提取不足 (3. Avoids UnderFetching)
GraphQL allows you to avoid under-fetching.So here nothing called under/over fetching exists. Data is getting served and computed based on the client’s request.And also no need to expose out multiple endpoints to get any subset of fields. A single Query serves the purpose.
GraphQL允许您避免获取不足。 因此，这里不存在任何所谓的过度/过度获取。 数据是根据客户端的请求提供和计算的，也无需暴露多个端点即可获取任何字段子集。 单个查询即可达到目的。
Examples showing how GraphQL avoids over and under fetching:
显示GraphQL如何避免过度获取和不足获取的示例：
Here client request for the id field only in the post and same being returned in the response.
在此，客户端仅在帖子中请求id字段，并且在响应中返回相同的字段。
Here client requests for likes and comments too and based on the request the server resolves these using field-specific resolvers.
客户端在这里也请求喜欢和评论，并且服务器根据请求使用特定于字段的解析器解析这些。
You can see immediately that the recentPosts query has exactly the same shape as the result. This is essential to GraphQL, because the client always gets back what it expects, and the backend server knows exactly what fields the client is asking for. Here, each field is backed by any arbitrary function. And server uses these functions to resolve fields requested by the client.
您可以立即看到lastPosts查询的形状与结果完全相同。 这对于GraphQL是必不可少的，因为客户端始终可以获取期望值，并且后端服务器确切知道客户端要求的字段。 在这里，每个字段都由任意函数支持。 服务器使用这些功能来解析客户端请求的字段。
4.协议，而不是存储： (4. Protocol, not Storage:)
While Facebook was building GraphQL to support News Feed, they already had a sophisticated feed ranking and storage model, along with existing databases and business logic. GraphQL had to leverage all this existing work that was useful, and so does not dictate or provide any backing storage. Instead, GraphQL takes advantage of your existing code.
在Facebook构建GraphQL以支持News Feed的同时，他们已经拥有完善的feed排名和存储模型，以及现有的数据库和业务逻辑。 GraphQL必须利用所有这些有用的现有工作，因此不会规定或提供任何后备存储。 相反，GraphQL利用了您现有的代码。
5.分层的 (5. Hierarchical)
One of the important aspects of GraphQL is that it is hierarchical in nature. GraphQL naturally follows relationships between objects, whereas a RESTful service may require multiple network calls or complex join statements in SQL. This kind of data hierarchy pairs well with graph-structured data stores and ultimately with the hierarchical user interfaces it’s used within.
GraphQL的重要方面之一是它本质上是分层的。 GraphQL自然遵循对象之间的关系，而RESTful服务可能需要多个网络调用或SQL中的复杂连接语句。 这种数据层次结构与图结构的数据存储以及最终在其中使用的层次结构用户界面很好地配对。
结论 (Conclusion)
The above-discussed features like strongly-typed, hierarchical nature, extensibility e.t.c. make GraphQL stand firmly against rest. While preferring GraphQL over rest has some downsides also but still, GraphQL is an established part of building products at Facebook and, its use beyond Facebook is just a beginning.
上面讨论的功能，如强类型，分层性质，可扩展性等，使GraphQL坚决抵制休息。 尽管优先选择GraphQL也有一些缺点，但是GraphQL仍然是Facebook构建产品的既定组成部分，其在Facebook以外的用途仅仅是一个开始。
449
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
