过去几年，GraphQL[1]已经成为非常流行的API规范，它专注于制作客户端（无论客户端是前端还是前端）第三方）数据获取更容易。内容：为什么选择GraphQL？定义GraphQL模式设置解析器运行服务器性能注意事项缓存授权模式最佳实践GraphQL什么时候不合适？了解更多在传统的基于REST的API方法中，客户端发出请求，服务器决定响应：curlhttps://api.heroku.space/users/1{"id":1,"name":"Luke""email":"luke@heroku.space","addresses":[{"street":"1234RodeoDrive","city":"LosAngeles","country":"USA"}]}但是，在GraphQL中，客户端可以准确地确定它从服务器获取的数据。例如，客户端可能只需要用户名和电子邮件，而不需要任何地址信息：curl-XPOSThttps://api.heroku.space/graphql-d'query{user(id:1){nameemail}}{"data":{"name":"Luke","email":"luke@heroku.space"}}有了这个新模式，客户端可以通过缩小响应来满足他们的需求，从而更有效地查询服务器。对于单页应用程序(SPA)或其他前端重客户端应用程序，您可以通过减少负载大小来加快渲染时间。然而，与任何框架或语言一样，GraphQL也有取舍。在本文中，我们将探讨使用GraphQL作为API查询语言的优缺点，以及如何开始构建实现。为什么选择GraphQL？与任何技术决策一样，重要的是要了解GraphQL为您的项目提供哪些优势，而不是仅仅因为它是一个流行词而选择它。考虑一个使用API连接到远程数据库的SaaS应用程序。如果要呈现用户的个人资料页面，您可能需要进行APIGET调用以获取有关用户的信息，例如用户名或电子邮件。然后您可能需要进行另一个API调用以获取有关存储在另一个表中的地址的信息。随着应用程序的增长，由于其构建方式，您可能需要不断对不同位置进行更多API调用。虽然每个API调用都可以异步完成，但您还必须处理它们的响应，无论是错误、网络超时，还是暂停页面呈现，直到收到所有数据。如上所述，这些响应的负载可能超过呈现当前页面所需的负载，并且每个API调用都有网络延迟，总延迟加起来可能会很大。使用GraphQL，您无需进行多次API调用（例如GET/user/:id和GET/user/:id/addresses），而是进行一次API调用并将查询提交到单个端点：query{user(id:1)){nameemailaddresses{streetcitycountry}}}GraphQL然后只提供一个端点来查询所需的所有域逻辑。如果您的应用程序不断增长，您可能会发现自己向架构中添加了更多数据存储-PostgreSQL可能是存储用户信息的好地方，而Redis可能是存储其他类型信息的好地方-对GraphQL的一次调用端点将解析所有这些不同的位置，并用他们请求的数据响应客户端。如果您不确定应用程序的需求以及将来如何存储数据，GraphQL在这里也很有用。要修改查询，您只需添加所需字段的名称：addresses{street+apartmentNumber#newinformationcitycountry}这大大简化了应用程序随时间增长的过程。定义GraphQL模式有各种编程语言的GraphQL服务器实现，但在开始之前，您需要识别业务领域中的对象，就像任何API一样。就像RESTAPI可能使用JSON模式一样，GraphQL使用SDL或模式定义语言定义其模式，这是一种描述GraphQLAPI可用的所有对象和字段的幂等方式。SDL条目的一般格式如下：type$OBJECT_TYPE{$FIELD_NAME($ARGUMENTS):$FIELD_TYPE}让我们在前面的示例的基础上定义用户和地址的条目。typeUser{name:Stringemail:Stringaddresses:[Address]}typeAddress{street:Stringcity:Stringcountry:String}user定义了两个String字段，分别是name和email，它还包括一个名为addresses的字段，是一个Addresses对象数组。地址还定义了它自己的几个字段。（顺便说一句，GraphQL模式不仅有对象、字段和标量类型，您还可以组合接口、联合和参数来构建更复杂的模型，但我们不会在本文中介绍。）我们还需要定义一个类型，它是我们GraphQLAPI的入口点。你还记得吗，我们之前说过一个GraphQL查询看起来像这样：query{user(id:1){nameemail}}查询字段属于一个特殊的保留类型，称为Query，它指定了获取对象点的主要入口点。（还有一个用于修改对象的Mutation类型。）这里，我们定义了一个返回User对象的user字段，所以我们的schema也需要定义这个字段：typeQuery{user(id:Int!):User}中的参数typeUser{...}typeAddress{...}字段是一个以逗号分隔的列表，格式为$NAME:$TYPE。这！是GraphQL表示参数是必需的方式，省略它意味着它是可选的。根据您选择的语言，将此架构合并到服务器的过程会有所不同，但通常，将信息用作字符串就足够了。Node.js有graphql[2]包来准备GraphQL模式，但我们将使用graphql-tools[3]包，因为它提供了更多好处。让我们导入该包并阅读我们的typedef为将来的开发做准备：:"utf8",标志:"r",});设置解析器模式设置了构建查询的方式，但是建立模式来定义数据模型只是GraphQL规范的一部分。另一部分涉及实际获取数据，这是通过使用解析器完成的，解析器是一个返回字段基础值的函数。让我们来看看如何在Node.js中实现解析器。我们的目标是巩固有关解析器如何使用模式进行操作的概念，因此我们不会详细介绍如何设置数据存储。在“现实世界”中，我们可能会使用knex[4]之类的东西来建立数据库连接。现在，让我们设置一些虚拟数据：constusers={1:{name:"Luke",email:"luke@heroku.space",addresses:[{street:"1234RodeoDrive",city:"LosAngeles",country:"USA",},],},2:{name:"Jane",email:"jane@heroku.space",addresses:[{street:"1234LincolnPlace",city:"Brooklyn",country:"USA",},],},};Node.js中的GraphQL解析器相当于一个Object，key是要检索的字段名，value是返回数据的函数。让我们从一个通过id进行初始用户查找的简单示例开始：constresolvers={Query:{user:function(parent,{id}){//userlookuplogic},},}这个解析器有两个参数：一个对象表示父级（在原始根查询中，此对象通常未使用），一个包含传递给您的字段的参数的JSON对象。并非每个字段都有参数，但在本例中我们会有，因为我们需要通过用户ID检索其用户。函数的其余部分很简单：constresolvers={Query:{user:function(_,{id}){returnusers[id];},}}你会注意到我们没有明确定义用户或地址的解析器,graphql-tools包足够聪明，可以自动为我们映射这些。如果我们愿意，我们可以覆盖它们，但现在我们已经定义了我们的类型定义和解析器，我们可以构建我们的完整模式：constschema=makeExecutableSchema({typeDefs,resolvers});运行服务器最后，让我们来运行这个演示吧！由于我们使用的是Express，因此我们可以使用express-graphql[5]包将我们的模式公开为端点。该包有两个参数：架构和根值，它有一个可选参数graphiql，我们将在稍后讨论。使用GraphQL中间件在您的首选端口上设置一个Express服务器，如下所示：,express_graphql({schema:schema,graphiql:true,}));app.listen(5000,()=>console.log("Expressisnowliveatlocalhost:5000"));将浏览器导航到http://localhost:5000/graphql，你应该看到一种IDE界面。在左侧窗格中，您可以输入所需的任何有效GraphQL查询，而在右侧您将获得结果。这就是graphiql:true提供的：一种测试查询的便捷方式，您可能不想在生产中公开它，但它使测试变得容易得多。尝试输入上面显示的查询：query{user(id:1){nameemail}}要探索GraphQL的类型化功能，请尝试为ID参数传递一个字符串而不是整数。#Thiswon'tworkquery{user(id:"1"){nameemail}}你甚至可以尝试请求不存在的字段：#Thiswon'tworkquery{user(id:1){namezodiac}}只需使用schema表达在几行清晰的代码中，就可以在客户端和服务器之间建立一个强类型的契约。这可以防止您的服务接收虚假数据，并向请求者清楚地指示错误。性能注意事项虽然GraphQL为您解决了很多问题，但它并没有解决构建API时固有的所有问题。特别是缓存和授权，只需要一些计划来防止性能问题。GraphQL规范没有为实现这两种方法中的任何一种提供任何指导，这意味着构建它们的责任落在您身上。缓存基于REST的API在缓存时无需过分关注，因为它们可以构建在网络其他部分使用的现有HTTP标头策略之上。GraphQL没有这些缓存机制，这对重复请求造成了不必要的处理负担。考虑以下两个查询：query{user(id:1){name}}query{user(id:1){email}}没有某种缓存，只是为了检索两个不同的列，将导致两个数据库查询到获取ID为1的用户。实际上，由于GraphQL也允许别名，因此以下查询有效并执行两次查找：query{one:user(id:1){name}two:user(id:2){name}}second该示例暴露了如何批量查询的问题。为了快速高效，我们希望GraphQL以尽可能少的往返次数访问同一数据库行。dataloader[6]包旨在解决这两个问题。给定一个ID数组，我们将一次性从数据库中获取所有这些ID；同样，对同一ID的后续调用将从缓存中获取项目。要使用数据加载器构建它，我们需要两件事。首先，我们需要一个函数来加载所有请求的对象。在我们的示例中，它看起来像这样：constDataLoader=require('dataloader');constbatchGetUserById=async(ids)=>{//在现实生活中，这将是数据库调用returnids.map(id=>users[id]);};//userLoader现在是我们的“批量加载函数”constuserLoader=newDataLoader(batchGetUserById);这样可以解决批处理的问题。要加载数据并使用缓存，我们将调用load方法替换之前的数据查找，传入我们的用户ID：constresolvers={Query:{user:function(_,{id}){returnuserLoader.load(id);},},}授权授权是GraphQL的一个完全不同的问题。简而言之，它是识别给定用户是否有权查看某些数据的过程。我们可以想象这样一种场景，经过身份验证的用户可以执行查询来获取自己的地址信息，但不应该获取其他用户的地址。为了解决这个问题，我们需要修改解析器函数。除了字段的参数之外，解析器还可以访问其父节点，以及传入的特殊上下文值，这些值提供有关当前经过身份验证的用户的信息。因为我们知道地址是一个敏感字段，所以我们需要修改我们的代码，以便对用户的调用不只是返回地址列表，而是实际调用一些业务逻辑来验证请求：constgetAddresses=function(currUser,user){if(currUser.id==user.id){returnuser.addresses}return[];}constresolvers={Query:{user:function(_,{id}){returnusers[id];},},用户：{地址：函数（parentObj，{}，上下文）{returngetAddresses（context.currUser，parentObj）;}，}，};同样，我们不需要为每个User字段显式定义一个解析器，只需要一个我们想要修改的解析器就可以了。默认情况下，express-graphql会将当前HTTP请求作为上下文值传递，但这可以在设置服务器时更改：app.use("/graphql",express_graphql({schema:schema,graphiql:true,context:{currUser:user//当前认证用户}}));模式最佳实践GraphQL规范中缺少的一个方面是缺乏关于版本控制模式的指导。随着应用程序的增长和变化，它们的API也会发生变化，可能需要删除或修改GraphQL字段和对象。但这个缺点也是一个积极的方面：通过仔细设计你的GraphQL模式，你可以避免在更容易实现（也更容易破坏）的REST端点中出现明显的陷阱，例如命名不一致和混淆关系。此外，您应该尝试将业务逻辑与解析器逻辑分开。您的业??务逻辑应该是整个应用程序的唯一真实来源。在解析器中执行验证检查很诱人，但随着模式的增长，这将成为一种站不住脚的策略。GraphQL什么时候不适合？GraphQL无法像REST那样精确地满足HTTP通信的需求。例如，GraphQL仅指定一个状态代码——200OK——无论查询是否成功。在此响应中，返回一个特殊的错误键供客户端解析和识别出了什么问题，因此错误处理可能有点棘手。同样，GraphQL只是一个规范，它不会自动解决您的应用程序面临的所有问题。性能问题不会消失，数据库查询不会变得更快，而且通常，您需要重新考虑有关API的一切：授权、日志记录、监控、缓存。对您的GraphQLAPI进行版本控制也可能是一个挑战，因为官方规范目前不支持处理重大变更，而这是构建任何软件都不可避免的一部分。如果您对探索GraphQL感兴趣，则需要投入一些时间来学习如何最好地将它与您的需求相结合。本文转载自微信公众号“前端全栈开发者”，可通过以下二维码关注。转载本文请联系前端全栈开发公众号。
