改变意识以快速掌握GraphQL的三个要点

2 年 ago

清, 宇

1 minute

在实施GraphQL时，应注意的三个要点如下：服务器端和客户端端的实现。

できるだけ薄く

我认为，在考虑以下三点并实施时，与不考虑它们相比，实施速度可能会有几倍的差异，尤其是对于那些注重REST的人来说。

只要找到正确的使用场景，GraphQL是非常有用和有趣的。而且GraphQL的官方网站解释得非常清晰易懂。与那些博客文章相比，它更加精细和高级，几乎没有必要在其他地方阅读有关技术的内容。

但是使用GraphQL初期，有些地方感觉编码进展得很奇怪。原因是一直以来都是用RESTful进行编码，没有从REST思维意识转换到GraphQL。由于GraphQL和REST的设计思想不同，需要改变思维意识。只要改变了这个意识，GraphQL就没有什么困难，可以很容易地实现。即使官方网站上的技术内容写得再清楚易懂，如果没有专注于突出这一点来改变思维意识，就会感到“嗯？以前是这样的，为什么会变成这样？”

如果你不知道GraphQL是什么，可以先阅读这个网站或者官方网站。

GraphQLはタイタニックの救命ボードになりえるかも

假设你已经了解GraphQL的概念，以下进行解释。

【意识改革１】一个终点

GraphQL有且仅有一个端点。不像REST那样有GET api/v1/users、POST api/v1/users/:id之类的。所有请求都发送到/graphql。这是因为GraphQL的查询语言可以吸收所有这样的处理。在实现客户端的时候，每当我想到”哎呀，这个请求应该发送到哪里呢？”时，我自己就会纠正说，不对，“在哪里？”这是REST思维，而不是GraphQL的。

在我个人开发的web应用中使用GraphQL进行实现时，有一个地方需要将缓存和数据库的处理分成两种。于是我考虑了将常规处理放在/graphql下接收，将其他处理设计为另一个端点（例如/graphql2）。现在回想起来，我认为这是一个愚蠢的设计。这样做无法充分利用GraphQL的优势，而且维护性显著下降。在之后当查询或类型发生变化时，必须考虑两个端点和它们的行为。因为我是个人开发，无需与客户端开发者和服务器开发者交流，只需在自己的脑海中扮演两个角色就行了，但如果是在团队中进行这样的开发，我知道工程师们之间会有很多无用的讨论。

GraphQL的好处在于客户端和服务器只需确定“使用这种类型”并进行实施。之后，只需要在需要时请求所需的信息即可完成。
虽然官方网站上只简单提及了“单个端点”，但它是非常重要的。

【意识改革２】没有版本

GraphQL基本上沒有版本。換句話說，不像REST一樣有版本的概念。在使用REST的項目中，當版本升級時，需要將客戶端的實現與之同步，然後開始使用api/v2/…這樣的版本進行發布。
理論上這應該能夠正常運作，但總是會成為一個頭痛的問題。然而，GraphQL沒有版本之分。只需在/graphql端點上持續使用，無論是v1還是v2，都不需要任何更改。

对于一个REST思维的人来说，我感到不安。像是“嗯？没有版本？？？万一出问题怎么办？”这样考虑。但通过这个问题和答案，我注意到了一个事实：“为什么REST的API会有v1或v2这样的版本？”答案是“因为有破坏性的变更，每次都需要增加版本号”。换句话说，“如果使用GraphQL就没有破坏性的变更，不需要进行版本控制”。在GraphQL中，客户端发出的请求并直接返回响应，在基本的变更中不会产生破坏性。删除之前存在的字段可能是破坏性的，但GraphQL推荐使用add-only的方法，即只进行字段的添加。

因此，此次创建的Rails路由遵循最佳实践，而不是使用像“graphql POST /api/v1/graphql”这样的方式，而是使用“graphql POST /graphql”的方式。非常清爽。这样做还可以向外界宣称“我们没有版本号”。如果之前一直忍受着在RESTful API上升版本号的痛苦，那么这种无版本API的思维方式可能会受到您的喜爱。

【意识改革３】尽量做到薄。

正如GraphQL的作者Lee Byron所说，”GraphQL可以做任何事情，但最好让GraphQL尽可能地精简”。Lee Byron的演讲视频非常有启发性，其中最重要的是这一部分”尽可能地精简”。

如果我们实现了认证、会话管理等各种处理，都通过GraphQL来进行，那么我们就不应该在GraphQL内部完成这些处理。必须有适合进行这些处理的类，然后在那里完成。

GraphQL的责任和角色只是查询（类似RESTful的GET）和突变（POST或PATCH），其他功能都不涉及。因此，如果resolve ->（obj，args，ctx）中有逻辑，我们应该考虑这个职责应该由谁负责，并将它移动到那个地方。

随着应用程序源代码的增大，这个原则变得越来越重要。”好在我们保持了精简”。

GraphQL的實際應用案例

这是我个人使用GraphQL、Rails和React+Redux开发的Web应用程序，它是一个叫做”node-node-node”的桌面版SNS，旨在以图解的形式展示工程师们的集体知识。