我不认为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开发人员来说，对话应该更具有内容性和细微差别。