REST和GraphQL不是构建HTTP API唯一的选择 - Ben Nadel

19-08-28 banq
                   

我不认为Web开发社区正在就GraphQL 进行诚实的讨论。这是因为,GraphQL几乎作为REST(Representational State Transfer)的完全替代方案。而且,虽然GraphQL可以消除REST中发现的摩擦点,但是当涉及到API实现时,不诚实的根源在于错误和隐含的二分法。

事实上,在构建基于HTTP的API时,GraphQL和REST 不是您唯一的选择。虽然这对许多有经验的Web应用程序开发人员来说可能是显而易见的,但对于新手来说这并不是那么明显。因此,我认为社区应该努力进行更细致的对话。

从本质上讲,HTTP API只是一种从Producer到Consumer获取数据的方法。在今天的胖客户端世界中,通过AJAX(异步JavaScript和JSON)消耗HTTP API; 并且,将数据从服务器传递到浏览器(通常作为单页应用程序或SPA的一部分)。

在这个密集客户端的世界中,单个团队很可能同时拥有客户端和服务器实现。这是BFF(Backend-For-Frontend)模式中价值主张的一部分 ; 并且,这意味着围绕API的决策只不过是一个封装良好的实现细节:

在这种情况下:AJAX,WebSockets,长轮询,整页重新加载,iframe,动态图像源 - 您的选择并不重要。您甚至可以将几种不同的方法组合在一起。无论哪种方式适合您的团队,并允许您为您的用户群提供价值,您应该采用的实施或实施方式。

也就是说,您可以使用AJAX而无需使用GraphQL或REST。例如,您可以使用AJAX来使用静态JSON(JavaScript Object Notation)文件。想象一下将国家代码列表写入country_codes.json文件的构建过程?或者,将本地化字符串写入一系列基于语言的JSON文件的构建过程lang_${ language }.json。

在我的主要应用程序中 - 在我的所有权范围内(见上图) - 我经常创建为特定用户界面定制的 API端点。当我有一个新的界面时,我创建了一个新的端点。这不是REST。也不是GraphQL。它只是一个基于HTTP的AJAX调用,它返回一个JSON有效负载。而且,随着前端需求的不断发展,我改变了服务器端点的实现,以满足这些需求。

由于我的团队拥有前端和后端,因此这种方法快速且极其灵活。它可以轻松运行孤立的实验,而不会破坏任何不相关的终点; 它可以轻松地为可以应对陈旧性的页面使用不同的数据源(如读取副本); 并且,它使得在应用程序逻辑中删除内聚垂直切片变得非常容易(即,删除前端和后端代码)。

我不在此上下文中使用GraphQL,因为它无法解决我的团队实际拥有的问题。REST也是如此。在这种情况下, GraphQL和REST都会添加可能减慢我们速度的结构和抽象,或者至少限制我们的一些灵活性。

这并不是说我的方法比GraphQL或REST更好; 只是说在我的特定上下文中

GraphQL和REST都没有解决问题。而且,这也是重点:上下文是王道。我的团队拥有全栈上下文,因此我们使用最能满足我们需求的API实现。如果我自己不消费使用API,我就会构建一个公共API,或者一个跨服务API。

REST和GraphQL都可以作为API实现的良好选择。但是,当涉及到HTTP API时,它们肯定不是您唯一的选择。您应该选择最适合您的场景上下文,所有权范围和团队技能的实施 - 或实施的组合。我知道GraphQL解决了REST中存在的许多摩擦点; 但是,作为一个社区,我们不应该将GraphQL和REST呈现为“要么A要么B”的选项。对于崭露头角的Web开发人员来说,对话应该更具有内容性和细微差别。

其他REST与GraphQL的争论

                   

2