GraphQL是API的未来 但不是万灵药
作者| Jens Neuse
翻译|平川
策划|蔡芳芳
我觉得GraphQL会改变世界。以后可以用GraphQL查询世界上任何系统。我在创造这个未来。那么我为什么要反对使用GraphQL呢？我个人最讨厌的是，社区一直在宣传GraphQL的好处，但这些好处是很常见的，与GraphQL无关。如果要普及，那就要坦诚，摘下有色眼镜。本文是对Kyle Schrade的文章《为什么要用GraphQL》的回应。这不是批评。这篇文章是一个很好的讨论基础，因为它代表了我在社区中经常听到的观点。如果你看完整篇文章，当然这需要一些时间，你就会完全理解为什么我觉得凯尔的文章应该改名为“为什么用阿波罗”。
如果你没看过Kyles的文章，建议你先看看。
本文最初发表于WunderGraph官方博客(《Why not use GraphQL？》)，经原作者授权由InfoQ中文站翻译分享。
一个
REST的缺点
作者指出了REST API的一系列缺点以及GraphQL是如何克服所有这些缺点的：
过度收购；
多个请求请求多个资源；
对嵌套数据的瀑布网络请求；
每个客户都需要知道每个服务的位置。
前三个问题可以通过编写另一个REST API来解决。使用新编写的应用编程接口作为特定用户界面的外观。拿下一个。JS为例。接下来提供了一个非常轻量级的语法定义API。您可以将多个调用封装到一个API中，并让它们在服务器端完成，而不是从客户端发送多个请求。这种方法也可以解决超取和欠取的问题，因为你可以在将数据发送回客户端之前对其进行操作。这里描述的模式称为“前端后端(BFF)”。它不局限于像Next这样的全栈框架。JS你也可以为移动应用创建一个BFF。
使用BFF模式，客户端不需要知道每个服务的位置。但是，实现BFF的开发人员需要了解服务环境。希望你所有的服务都有接口定义规范，显示在开发者门户。这种情况下，写BFF应该很容易。
GraphQL要求开发人员实现解析器。实现解析器的任务类似于构建BFF，逻辑非常相似。那么，真正的区别是什么呢？
BFF更容易实现，因为可用的工具更多。例如，如果您使用像Next这样的框架。JS结合SWR钩子(一边旋转一边停留)，可以直接使用Etags自动缓存，并使缓存无效。这减少了服务器和客户端之间发送的数据量，甚至比GraphQL更少，因为您不发送查询负载。如果响应仍然有效，服务器将发回一个304响应(未修改)。另外，你不需要用阿波罗这样的重量级客户。Vercel提供的swr库非常小，很容易使用。它支持分页和挂钩，可以帮助我们非常有效地来回导航。
GraphQL保留了查询，但是这种实现会带来额外的开销。如果您不使用像Relay这样的客户端(默认情况下它会持续查询)，您必须自己做，或者使用一些第三方库来实现它。与使用Next的BFF方法相比。JS，前端得到同样的结果就比较复杂了。如何用GraphQL实现Etags？如果没有变化，如何让GraphQL服务器返回304状态码？不是要先把所有的查询转换成GET请求吗？在这种情况下，您的GraphQL客户端和服务器支持这一点容易吗？
从用户体验和易开发性来说，BFF显然是赢家。客户端和服务器之间传输的数据更少，这使得它更容易实现。客户端更小，移动部件更少。
但是有一个问题。您必须为每个前端单独构建一个BFF。如果你有很多前端，那可能是一份很棒的工作。您必须维护所有BFF，操作它们并确保它们的安全。
如果不用权衡取舍就能得到两者的好处，岂不是很棒？这就是WunderGraph的目的，一个用GraphQL构建BFF的框架。