graphql 前端编写_GraphQL：前端查询变得容易

graphql 前端编写

by Rasheed Bustamam

通过拉希德·布斯塔曼(Rasheed Bustamam)

GraphQL：前端查询变得容易 (GraphQL: front-end queries made easy)

If you’ve been reading about the latest trends in front-end development, you may have heard some buzz about something called GraphQL. In this article, we will cover what GraphQL is (and isn’t), some best practices behind GraphQL, and most importantly, why it makes your job as a front-end developer much easier.

如果您一直在阅读前端开发的最新趋势，那么您可能已经听到了一些关于GraphQL的嗡嗡声。 在本文中，我们将介绍GraphQL是(和不是)什么，GraphQL背后的一些最佳实践，最重要的是，为什么它使您作为前端开发人员的工作更加轻松。

Note: This is not meant to be a GraphQL tutorial. This article is merely meant to describe why GraphQL makes your job as a front-end developer easier.

注意：这并不意味着是GraphQL教程。 本文仅用于描述GraphQL为什么使您作为前端开发人员的工作更加轻松。

什么是GraphQL？ (What is GraphQL?)

GraphQL is a query language created by Facebook. It allows you, the front-end developer, to write queries that have the exact data shape you want.

GraphQL是Facebook创建的一种查询语言。 它使您(前端开发人员)可以编写具有所需数据形状的查询。

It’s important to note that despite the name “GraphQL,” it is not meant to be a database language. In fact, I’ve used GraphQL with many databases, including SQL, MongoDB, and even a REST API connected to a database (and I don’t even know what the database language was written in).

重要的是要注意，尽管名称为“ GraphQL”，但它并不意味着它是一种数据库语言。 实际上，我已经在许多数据库中使用了GraphQL，包括SQL，MongoDB，甚至还有连接到数据库的REST API(而且我什至都不知道数据库语言是用什么编写的)。

Instead, GraphQL on the server allows you to define how you want to fetch your data. Then, on the client, you can execute a query that has the exact data shape you want, and the data you get back will have the same shape as the query.

而是，服务器上的GraphQL允许您定义要如何获取数据。 然后，在客户端上，您可以执行具有所需数据形状的查询，并且返回的数据将与查询具有相同的形状。

For example:

例如：

The response you get back will look something similar to this:

您返回的响应将类似于以下内容：

There will be other metadata in the response, but you can already see how powerful GraphQL is — no need to normalize any of your data on the client. The work is pushed to the server.

响应中将包含其他元数据，但是您已经可以看到GraphQL的功能多么强大-无需在客户端上标准化任何数据。 工作被推送到服务器。

Since this article is more oriented towards front-end developers, I won’t get into too much detail about how GraphQL works on the server. However, what makes the “magic” happen is the GraphQL schema, which allows you to define types that are used across server and client. Here’s an example schema for a hypothetical app:

由于本文更面向前端开发人员，因此我不会过多地讨论GraphQL在服务器上的工作方式。 但是，使“魔术”发生的是GraphQL模式，该模式允许您定义在服务器和客户端之间使用的类型。 这是一个假设的应用程序的示例架构：

Just by looking at the schema, you can already tell what the shape of your data will be, and what types are expected. This allows you, the front-end developer, to know several important properties of a query, such as if it takes arguments, if it’s a list or just an “entity,” and if it’s a specific entity, what fields that entity has (in this case, entity User has fields name and email).

仅通过查看模式，您就可以知道数据的形状以及期望的类型。 这使您(前端开发人员)可以知道查询的几个重要属性，例如是否接受参数，是列表还是仅是“实体”，如果是特定实体，则该实体具有哪些字段(在这种情况下，实体User具有字段name和email )。

In the case of the user query, we can see that it takes in an argument called username, which has a type of String. The ! denotes that the field is required, so if it is not supplied, an error will be thrown.

对于user查询，我们可以看到它接受了一个名为username的参数，该参数的类型为String 。 ! 表示必填字段，因此，如果未提供该字段，将引发错误。

As a front-end developer, you probably won’t be working too much with the schema, but it will serve as an important document that allows you to know what queries you are allowed to make.

作为前端开发人员，您可能不会对架构进行过多的工作，但是它将用作重要的文档，使您可以知道可以进行哪些查询。

Compare that to other API standards, such as Swagger for REST APIs — you have to trust that whoever wrote documentation wrote it really well, with all edge cases and types documented. Swagger doesn’t exactly “enforce” type checking for different fields and such, so you can have a valid Swagger YAML file that is still incredibly difficult to navigate.

将其与其他API标准(例如Swagger for REST API)进行比较-您必须相信，编写文档的人写得很好，并记录了所有极端情况和类型。 Swagger并不完全“强制”对不同字段进行类型检查，因此，您可以获得有效的Swagger YAML文件，但仍然难以导航。

However, any valid GraphQL schema in itself will be immensely helpful for anyone to know what sorts of data they’re dealing with, even if it isn’t properly commented out and documented.

但是，任何有效的GraphQL模式本身对任何人都非常有帮助，即使他们没有正确注释和记录数据，也知道他们正在处理哪种数据。

This isn’t meant to dig at Swagger or to say it’s terrible — used correctly, Swagger can be very useful. But that’s the caveat — it needs to be used correctly, and since developers tend to move extremely fast, proper documentation can often take a back seat to building new and exciting features/APIs.

这并不是要挖掘Swagger或说它很糟糕-正确使用Swagger会非常有用。 但这是一个警告，需要正确使用，并且由于开发人员往往会以极快的速度移动，因此正确的文档通常会在构建新的令人兴奋的功能/ API时退居二线。

如何在客户端上使用GraphQL (How to use GraphQL on the client)

This is a fun one. On the client-side, there are many ways to use GraphQL on the client.

这很有趣。 在客户端，有多种方法可以在客户端上使用GraphQL。

One of the most popular ways to use GraphQL is using a library called apollo-client. Apollo Client can interface with React, Vue, Angular, and more.

使用GraphQL的最流行方法之一是使用名为apollo-client的库。 Apollo Client可以与React ， Vue ， Angular等接口。

Now, Apollo Client recently updated to the 2.0 release. It is absolutely not backwards compatible with the 1.0 release, with many packages changing names and entire APIs changing. I’ve been slowly familiarizing myself with the 2.0 release, but there are still some things I was able to do in 1.0 that I can no longer do in 2.0, such as Redux integration in my React apps. Because of this, I would consider 1.0 and 2.0 to be entirely different ways to use GraphQL on the client.

现在，Apollo Client最近更新到了2.0版本。 它绝对不向后兼容1.0版本，因为许多程序包更改了名称，整个API都更改了。 我一直在慢慢熟悉2.0版本，但是在1.0版本中我仍然可以做一些事情，而在2.0版本中我再也无法做到，例如React应用程序中的Redux集成。 因此，我认为1.0和2.0是在客户端上使用GraphQL的完全不同的方法。

However, the overall concept is the same: wrap your entire app in an Apollo Provider (similar to how you would do with Redux), and now all of your components have access to the client, and can write queries and mutations to the server.

但是，总体概念是相同的：将整个应用程序包装在Apollo Provider中(类似于对Redux的处理方式)，现在所有组件都可以访问客户端，并且可以向服务器写入查询和变异。

Apollo Client does a lot of cool “behind-the-scenes” things that you expect should be standard but apparently are not. One example is “batching” queries. If I load a component that loads two different queries, the default is to send two different requests. However, Apollo Client has the option to “batch” these queries, which puts both of those queries into a single request and sends that up to the server, saving some HTTP requests.

Apollo Client做了许多您认为应该是标准的但很显然不是标准的“幕后”很酷的事情。 一个示例是“批处理”查询。 如果加载的组件加载了两个不同的查询，则默认值为发送两个不同的请求。 但是，Apollo Client可以选择“批处理”这些查询，这会将这两个查询都放入单个请求中，然后将其发送到服务器，从而节省了一些HTTP请求。

Apollo Client also has a very robust caching feature, which makes components fetch from the cache first. Then it actually issues a request if the cache is stale (usually 100ms old, but can be configured).

Apollo客户端还具有非常强大的缓存功能，该功能使组件首先从缓存中获取。 然后，如果缓存已过期(通常为100毫秒，但可以配置)，它实际上会发出一个请求。

Here’s an example of instantiating an Apollo Client, and issuing a query:

这是实例化Apollo客户端并发出查询的示例：

This doesn’t even use React. If you were to implement React, then you could actually attach the query to the React Component so that it receives the query data as props.

这甚至不使用React。 如果要实现React，那么您实际上可以将查询附加到React组件，以便它接收查询数据作为道具。

The other way to use GraphQL on the client is by using Relay, which only works with React. So sorry Vue devs, you can’t use Relay.

在客户端上使用GraphQL的另一种方法是使用Relay ，它仅与React一起使用。 非常抱歉Vue开发人员，您不能使用Relay。

I haven’t used Relay too much, but it definitely has a steeper learning curve than Apollo. It seems like you have to “DIY” for a lot of things, such as caching and even schema implementation. You can take a look at some of the examples here to get an overview of how Relay works, and how it’s similar to and different from Apollo.

我没有太多使用Relay，但是它的学习曲线肯定比Apollo陡峭。 似乎您必须对很多事情进行“ DIY”，例如缓存甚至是模式实现。 您可以在此处查看一些示例，以概述Relay的工作原理，以及它与Apollo的异同。

Once you get Relay set up, then it actually works very similarly to how Apollo Client and react-apollo work together, in that it sends in the data as props to the component.

设置好中继后，它实际上与Apollo Client和react-apollo一起工作的方式非常相似，因为它将数据作为道具发送给组件。

结语 (Wrapping it up)

I hope this article was useful for you in deciding if you should use GraphQL or not. For me, just knowing the shape of the data coming in makes my front-end work immensely easier. And if the data is not coming in correctly, then I change it in the schema in the back-end, and update any necessary server-side code.

我希望本文对您决定是否使用GraphQL有所帮助。 对我来说，只要知道传入的数据的形状就可以使我的前端工作变得非常容易。 而且，如果数据输入不正确，那么我将在后端的架构中对其进行更改，并更新所有必要的服务器端代码。

If this article has piqued your interest in learning GraphQL, I suggest taking a deeper look at the official GraphQL tutorial: How to GraphQL.

如果本文激起了您对学习GraphQL的兴趣，我建议更深入地研究官方GraphQL教程： How to GraphQL 。

Have fun querying!

祝您查询愉快！

翻译自: https://www.freecodecamp.org/news/graphql-front-end-queries-made-easy-68e9d9ded283/

graphql 前端编写