为什么我们不使用GraphQL? - Wundergraph

20-11-08 banq

我认为GraphQL将改变世界。将来,您可以使用GraphQL查询世界上的任何系统。我正在建立这个未来。那么,为什么我反对使用GraphQL?

我个人的烦恼是,当前社区采取GraphQL的理由实际上与GraphQL无关。如果我们想推动采用,我们应该诚实并脱掉玫瑰色的眼镜。这篇文章是对Kyle Schrade的“为什么使用GraphQL”的回应(https://www.apollographql.com/blog/why-use-graphql/),我并不是要直接批评该文,我认为Kyle的文章应命名为“为什么使用Apollo”。

 

REST缺点

作者指出REST API具有一些缺点,以及GraphQL如何解决所有这些缺点:过度获取多个资源的多个请求,会产生基于嵌套数据上的瀑布网络请求,要获得这些嵌套数据,每个客户端都需要访问提供这些嵌套数据的每个服务。

解决过度请求可以通过编写另一个REST API作为特定用户界面的外观来解决。以Next.JS为例。接下来,您可以使用非常轻量级的语法来定义API。您可以将这些调用包装到API中并使它们在服务器端,而不是从客户端发出多个请求。

使用这种方法也可以解决过度获取和不足获取,因为您可以在将数据发送回客户端之前对其进行操作。所描述的模式称为“后端的前端”(BFF)。它不限于Next.JS之类的完整堆栈框架。您也可以为移动应用程序构建BFF。

使用BFF模式,客户端本身不必知道每个服务的位置。但是,实施BFF的开发人员需要了解服务格局。希望您对所有服务都有开放的API规范,并在开发人员门户中很好地介绍了这些规范。如果做到这样地步,编写BFF应该很容易。

使用GraphQL,仍然需要一个实现解析器的开发人员。实现解析器与构建BFF差不多是相同的任务,其逻辑非常相似。那么,真正的区别是什么?

BFF易于实现,因为有更多可用的工具。例如,如果将Next.JS之类的框架与swr挂钩(重新验证时失效)结合使用,则可以自动使用Etags进行缓存,并且可以使缓存失效。这减少了服务器和客户端之间发送的数据量。与GraphQL相比,它的数据更少,因为您没有发送查询有效载荷,并且如果响应仍然有效,服务器将以304(未修改)进行响应。此外,您不必使用像Apollo这样的重量级客户端。Vercel的库swr很小,非常易于使用。它带有对分页,挂钩的支持,并有助于非常有效地来回导航。

GraphQL保留了查询,但是要实现这一点会带来额外的开销。如果您没有使用像Relay这样的客户端(默认情况下会保留查询),则必须自己完成操作或使用第三方库来实现它。与使用Next.JS的BFF方法相比,在前端获得相同结果要涉及更多的复杂性。您将如何使用GraphQL实现Etags?如果未做任何更改,如何使GraphQL服务器返回304状态代码?您不是首先必须将所有查询都转换为GET请求吗?如果是这样,您的GraphQL客户端和服务器是否轻松支持此功能?

在用户体验和易于开发方面,BFF无疑是赢家。客户端和服务器之间的数据传输更少。易于实施。客户更小,活动部件更少。

但是有一个陷阱。您必须为每个前端构建一个BFF。如果您有很多,那么可能会需要很多工作。您必须维护所有BFF。您必须对其进行操作。您必须保护它们。

如果您在不进行折衷的情况下同时获得两者的好处,那岂不是很好吗?这正是WunderGraph的含义,它是使用GraphQL构建BFF的框架。

 

没有更多的版本的API

在下一段中,Kyle继续探讨版本API所涉及的问题。他绝对正确,因为API版本过多会使跟踪变得非常困难。然后他得出结论,在GraphQL中,只有一个版本的图形,并且可以在架构注册表中跟踪更改,这是Apollo的付费功能。因此,您不会在版本控制方面遇到任何问题,他说。

我很难得出相同的结论。仅仅因为GraphQL模式本身不支持版本控制,并不意味着问题就消失了。如果您不对REST API进行版本控制,则将获得相同的效果。实际上,许多专家说,如果不需要也应该始终不要尝试引入API版本。话虽这么说,是什么让您无法运行两个版本的GraphQL模式?我并不是说这是个好主意,但在技术上是可行的。

如果您的组织中存在太多的REST API版本问题,那么在抛出类似GraphQL之类的新工具之前,也许您应该首先看一下组织。有这么多版本的原因是什么?也许流程的改变或新的团队结构会有所帮助?GraphQL绝对不会解决您的版本问题。相反,我认为这实际上使情况变得更糟。

您必须支持移动应用程序吗?您应该意识到,交付本地应用程序需要时间。您必须等待应用商店的批准,并且可以期望许多用户从不(或缓慢地)安装新版本。如果您想在不破坏客户的情况下在这种情况下进行重大更改怎么办?不可能。您必须以不间断的方式引入此类更改。

在GraphQL的情况下发展模式将意味着您不赞成使用旧字段并添加新字段。新客户使用新字段,而您希望使用旧字段的客户数量会越来越少。希望您拥有一个可以迫使您的用户在某个时间点下载新版本的系统。否则,您可能会被迫无限期地支持不推荐使用的字段。如果是这种情况,GraphQL的弃用模型根本无法帮助您。

使用REST,您可以创建一个新的端点或现有端点的另一个版本。问题是一样的,解决方案看起来有点不同。

明确地说,如果您无法控制客户那边的开发,则就确实需要某种版本控制。如果您只有一个Web应用程序,则不需要此功能。但话又说回来,GraphQL可能也太过杀手了。

  

更小的载荷

在本段中,原文作者Kyle声称RESTful API不允许部分响应。

这是错误的。这是一个例子:

GET /users?fields=results(gender,name)

作者Kyle实际上是什么意思?我很确定他知道部分回应。我想他想说的是某人需要实施部分响应。实际上,当您从资源中选择子字段时,它对于GraphQL看起来非常熟悉。使用GraphQL,我们可以立即使用此功能。

另一方面,使用BFF方法,则不需要此方法。只需准确返回所需的数据即可。同样,像Next.JS这样的全栈框架使实现此过程更简单,使缓存更加容易,并且使您免费获得基于Etag的缓存失效。

总结本节,GraphQL可以为您提供所需的确切数据。部分响应可以达到相同的结果。BFF附带了实施和维护的额外费用,但具有更好的UX和DX。

 

严格类型接口

在本段中,Kyle解决了未严格键入REST API的问题。他谈到了API的问题,这些问题尚不清楚,如果您获得大量帖子或其他内容的数组,那么查询参数如何使情况复杂化。他还指出,由于GraphQL具有严格的类型系统,因此不会出现此问题。

我认为Kyle所说的是一个组织问题,您需要一个组织解决方案。

当您允许开发人员部署REST API而不发布Open API Specification(OAS)或类似内容时,您会遇到他所描述的那种问题。使用OAS,可以很容易地描述所有资源。OAS还允许您描述每个端点的OAuth2流和所需范围。此外,您可以描述查询参数的确切类型和验证规则,这是GraphQL所缺少的功能。

从GraphQL来看,无法描述身份验证,授权和输入验证。GraphQL缺少这些功能,因为Facebook的发明者在不同的层上解决了这个问题。无需他们将这些功能添加到GraphQL。您可以向架构中添加自定义指令,以实现类似于OAS的结果,但这将是您必须维护的自定义实现。

您可能会认为OAS无法保证API的响应符合规范。你说的没错。但是GraphQL模式如何保证任何内容?

GraphQL自省是将特定的GraphQL查询发送到服务器以获取有关GraphQL模式的信息的操作。GraphQL服务器可以自由选择所需的任何类型。如果您发送查询,则服务器可以使用内省响应中不符合GraphQL模式的响应进行回答。

以Apollo联盟为例。您将架构上载到架构注册表中,然后错误地部署了错误版本的GraphQL服务器。如果更改字段的类型,客户端可能会感到困惑。

当我们谈论GraphQL中的类型安全性时,实际上是指我们相信GraphQL服务器的行为完全符合自省查询响应所通告的行为。为什么我们不能以相同的方式信任Open API规范?我想我们可以。如果我们不这样做,那就是人员问题,而不是技术问题。

 

更好的客户端性能

下一段简短介绍了GraphQL如何提高客户端性能并减少网络往返次数。

我认为,与重量级的GraphQL客户端相比,我已经充分解释了BFF的功能强大得多,以及从“过时的重新验证模式”中获得了多少收益。

也就是说,GraphQL确实确实减少了请求数量并减少了整体数据传输。但是,您应始终考虑将GraphQL客户端添加到前端的成本。

 

减少记录和浏览API的时间

下一部分将介绍如何将OAS之类的工具用于RESTful API开发以及在微服务环境中维护多个OAS的挑战。Kyle将单个GraphQL模式与分布在多个git存储库中的Swagger文件进行了比较。

我认为很明显,导航单个GraphQL模式比坐在git存储库中查看多个OAS文件要简单得多。但是,公平地说,我们必须将在一个苹果与另外一个苹果进行比较。如果您想提高开发人员的工作效率,就不会将OAS文件粘贴到git存储库中,而是每天都将其命名。您运行的是一个开发人员门户,您可以在其中搜索API并在它们之间导航。

OAS依赖于JSON-Schema,该功能具有惊人的功能:您可以引用另一个文档中的对象类型。您可以将OAS分为多个文件,如果需要,它们可以互相引用。还有工具可以将多个OAS文件合并到一个OAS文档中。然后,您可以使用此文档,并将其输入到开发人员门户中,该门户可让您整体浏览所有API。请记住,设置所有这些都会产生额外的费用。您需要运行一个开发门户或购买一个。您必须描述所有的API,至少在开始时,这可能是一种负担。

要添加的一件事是,有许多框架可以让您用自己喜欢的编程语言来描述架构,例如通过定义对象或类。然后,您将获得一个自动生成的Open API规范,该规范将在知名端点上提供。

让我们将其与GraphQL进行比较。基本上有两种方法,首先是SDL,然后是代码。无论采用哪种方式,最终都会得到一个GraphQL模式,该模式描述所有类型以及字段,并允许您对其进行注释。

那么,有什么区别呢?OAS带有更多的开销来进行设置。另一方面,OAS具有内置的支持文档记录示例用例,身份验证和授权以及输入验证规则。

请记住,GraphiQL本身没有多个GraphQL模式的概念。如果您具有多个GraphQL(微)服务,则必须运行或购买专用组件,例如,类似于REST API开发人员门户的架构注册表。

我想专门介绍一个额外的段落是API用例。仅仅因为您拥有OAS或GraphQL模式,并不意味着您的API有充分的文档记录。API用户可以使用该API做什么?他们如何使用它?什么是好用例?有什么不好的?在哪里寻求帮助?如何验证用户?我需要API密钥吗?用一种可以帮助API使用者使用API​​的方式来记录您的API,比在类型和字段中添加描述要多得多。OAS允许您添加示例有效负载并对其进行描述。GraphQL缺少此功能。在Stripe上看到一个积极的例子。它们远远超出了Swagger或GraphQL Playground所能达到的范围。

另一方面,如果您查看GitHub的公共GraphQL API,您将找不到单个示例查询。假设您要获取有关存储库及其所有问题的信息。您必须打开GraphiQL并开始搜索。但是,GraphiQL中的搜索功能并没有真正帮助您。有人需要坐下来写示例查询和有关如何使用API​​的用例。否则,真的很难上手。

因此,尽管社区一直在说“ GraphQL正在自我记录”,但仅此功能并不能提供有用的API。OAS为您提供了添加用例的工具,但是您仍然必须编写它们。无论您选择哪种工具或语言,都需要努力使API对其他人有用。

 

传统应用程序的支持

在这一段中,作者说,为移动应用保留旧版本的REST API很痛苦。他的结论是,由于我们仅使用单个GraphQL服务器,因此不会出现此问题。

抱歉,我再次得出完全不同的结论。如果将规则设置为禁止版本控制,则可以添加新端点或交换现有端点的实现。在这种情况下,GraphQL和REST之间没有区别。对于REST和GraphQL API而言,支持旧版应用程序都是一个挑战。您需要找到一种不破坏客户端和服务器之间合同的方法。服务器是否公开REST或GraphQL都无关紧要,问题是相同的。

  

更好的错误处理

关于错误处理,作者描述了一个场景,即与将用部分数据进行响应的单个GraphQL查询相比,客户端必须进行3个后续REST API调用。

使用GraphQL,解析部分数据的逻辑就在服务器中。客户端需要具有其他逻辑以对部分响应做出适当反应。

借助REST,获取部分数据的逻辑可以位于客户端或BFF中。无论哪种方式,其逻辑或多或少都与GraphQL相同,只是位于其他地方。显然,REST API用例还需要客户端中的逻辑来处理部分响应。这种逻辑几乎与GraphQL用例中的逻辑相同。

没有什么可以阻止您在REST响应中返回有关失败原因的特定信息。OAS允许联合类型,因此您可以自由地向客户提供有关部分响应的丰富信息。这类似于Sascha Solomon(https://sachee.medium.com/200-ok-error-handling-in-graphql-7ec869aec9bc)描述的响应联合的概念。

GraphQL确实具有更好的错误处理能力吗?我认为OAS和GraphQL都为您提供了很好的工具,以非常用户友好的方式处理错误。开发人员应充分利用这些工具。没有免费的午餐。

 

结论

Kyle在全文中总结说,GraphQL是API的未来,因为它在性能,有效负载大小,开发人员时间和内置文档方面都优越。

我同意GraphQL是API的未来,但出于不同的原因。

更好的性能和更小的有效负载大小不是GraphQL的独特功能。您可以使用其他工具获得更好的结果,或者必须扩展GraphQL,例如使用Relay来获取持久化查询。为了从GraphQL文档中获得真正的好处,您肯定要做的不只是在架构中添加描述。

一旦尘埃落定,炒作就消失了,我们必须看看事实。我们不应该试图让世界相信GraphQL。使用GraphQL有很多优点,但是根据您的用例,您可能不会真正从中受益。与其说GraphQL是圣杯,不如说是更微妙的回应。

解决此问题的最佳方法是先查看问题,然后对解决问题的可能工具进行独特的比较。如果您的组织无法实现REST API,那么GraphQL又能如何解决此问题?也许您组织内的某些事情必须改变?另一方面,如果这不是组织上的问题,并且您完全确定REST不是您的用例的好选择,那么我敢打赌,您一定会喜欢GraphQL。

 

GraphQL本身几乎没有用。而是GraphQL工具使GraphQL如此强大。是社区,是我们!像Apollo,Hasura,The Guild,FaunaDB,Dgraph,GraphCMS之类的公司,我也希望WunderGraph也如此,它们使GraphQL如此强大。它是GraphiQL,各种GraphQL客户端,模式缝合,联合。整个工具生态系统是GraphQL成为下一件大事的原因。

更多工具和服务将加强生态系统。更强大的生态系统将导致更多的采用,这又将吸引更多的公司为GraphQL生态系统添加服务和工具,这是一个非常积极的循环。

GraphQL在这方面与Kubernetes非常相似。Docker(容器运行时)还不够。将复杂的Syscall封装为易于使用的API是使能因素,但是为了创建一个丰富的生态系统,需要一个调度程序,该调度程序应具有足够的表现力并具有非常容易的扩展性。

GraphQL提供了一种与Docker一样简单的语言来定义和使用API​​。如果您以前看过几行Javascript和JSON,则GraphQL会立即让您感到熟悉。但是类似于Docker,该语言本身并不强大。它是可扩展性及其周围的工具。

 

当Kyle问“ Why GraphQL”时,我认为他的实际意思是“ Why Apollo”。答案很简单。没有人愿意围绕REST API构建一个丰富的生态系统。尝试根据开放API规范生成React.JS客户端。与GraphQL客户给您的东西相比,这种体验很烂。没有人想出一种好的商业模式来解决这个问题。输入GraphQL,您将获得大量工具来抽象出您不想处理的问题。

REST API与所描述的用例的相关性将降低,而不是因为GraphQL是高级的。它是使GraphQL继续获得市场份额的工具和生态系统。与REST相比,GraphQL生态系统的扩展速度非常快。

超媒体API在服务器呈现的Web应用程序中一直发挥着巨大作用,并且仍然扮演着重要角色。但是,网络正在向前发展。用户期望从网站获得的原生体验。Jamstack正在接管前端。具有服务器端渲染和动态Javascript客户端的混合模型是这些应用程序的实现者。

RESTful API擅长解决一系列不同的问题。他们不会消失,恰恰相反!对于行业正在转变的这种类型的应用程序,它们并不是正确的工具。我认为REST API是内部API,合作伙伴API和服务器到服务器通信的理想工具。这是GraphQL在REST方面并未真正带来任何好处的领域。与RPC一起,它将在这一领域拥有美好的未来。

 

                   

1
猜你喜欢