用了6个月的GraphQL,真香!

2020 年 6 月 12 日

用了6个月的GraphQL,真香!


GraphQL 是一种用于 API 的查询语言,同时基于你的现有数据来执行这些查询的服务端运行时。它为 API 中的数据提供了一套易于理解的完整描述,并让客户端能准确地获得它们所需的查询内容,且不会附带任何冗余信息。


最初,GraphQL 只是 Facebook 为其移动 APP 开发的内部解决方案,后来向社区开源。


优点


1. 实用的数据交换


使用 GraphQL 时,开发者可以根据客户端需要的字段对查询进行灵活定义,这样“量体裁衣式”的自定义非常实用,而且执行起来十分简单。如果前端需要一个人的“名字”和“年龄”,GraphQL 就能只对这两个字段进行查询。而这个人的“姓”和“地址”就不会在该查询的响应中被发送。


2. 使用数据加载器来减少网络调用


尽管 GraphQL 库本身并不包含数据加载器(Dataloader),但是数据加载器的确是一个非常实用的程序库,可以用来解耦你的 APP 中互不相关的部分,还不会牺牲批处理数据加载的性能。虽然数据加载器提供了一个加载单个值的 API,但所有并发请求将被组合起来并提交给你的批处理加载函数。这就能让你的 APP 在整个应用程序中安全地执行分布式数据获取。


举个例子:在上述例子的基础上,这次我们从另一个叫做“交易服务”的服务中获取一个“人”的“银行信息”,这时后端可以从“交易服务”中获取相关的“银行信息”,然后将这个结果与这个“人”的“名字”和“年龄”捆绑在一起,再将这些信息资源作为响应发送回去。


3. 在公开数据和数据库模型之间进行解耦


GraphQL 的一大优点是能以解耦的方式将数据库建模数据对用户进行选择性地公开。这样,在对持久层(persistence layer)进行设计时,我们可以在聚焦于该层需求的同时,兼顾考虑怎样才是向外部世界公开数据的最佳方式。该功能还能与数据加载器联合起来使用,因为你可以在将数据发送给用户前将这些数据组合在一起,这样一来为公开数据设计模型就会变得非常容易。


4. 摆脱 API 版本控制的烦恼


API 版本控制是一个经常遇到的问题。一般而言,通过在相同的 API 前面添加一个 v2 标签来添加一个新版本来解决这个问题是相当简单的解决方案。但使用 GraphQL 时情况就大不相同了,尽管你还是可以使用上述解决方案来处理这个问题,但这并不符合 GraphQL 的自由精神。GraphQL 的文档明确指出,你应该升级你的 API,这意味着在不破坏原 API 的情况下向现有端点添加更多字段。前端仍然可以使用相同的 API 进行查询,并且在需要的时候请求新字段。就是这么简单。


这个特性在与前端开发团队协作时非常有用。由于设计更改,前端团队可以请求添加所需要的新字段,而后端团队可以轻松地实现该字段的添加,且不会扰乱现有的 API。


5. 前后端团队独立开发


使用 GraphQL,前端和后端团队可以彼此独立地工作。由于 GraphQL 包含严格类型定义的 schema,前后端团队可以互不干扰地并行工作。首先,前端团队甚至在无需查看代码的情况下,就可以很容易地从后端生成 schema。而这个生成的 schema 可以直接用于查询的创建。其次,前端团队还可以一直使用 API 的 mock 版本进行开发工作。他们还可以用 mock 版本来测试代码。这为开发人员提供了相当令人愉悦的体验,且完全不会对他们的开发工作造成任何妨碍。


缺点


1. 并不是所有的 API 都可以升级


有时,由于来自业务或设计的变化日积月累,迫使 API 的实现需要完全更改。在这种情况下,你将不得不依赖旧的方法来进行 API 版本控制。


2. 难维护的代码


我遇到过好几次,在使用数据加载器来获取数据时,代码有时会分散到多个地方,这对代码的维护造成了一些困难。


3. 响应时间长


由于查询可以不断升级并变得非常庞大,这有时会影响查询的响应时间。要避免这种情况,请确保让响应资源保持简洁。这方面的指南,请查看Github GraphQL API


4. 缓存困难


通常对一个 API 响应进行缓存的主要目的是能更快地从未来的请求中获得响应。与 GraphQL 不同,REST 的 API 所利用的是将缓存内置于 HTTP 技术规范中。正如前面提到的,一个 GraphQL 查询可以请求资源的任何字段,这就使得在 GraphQL 里使用缓存天生就很困难。


结论


我个人强烈推荐使用 GraphQL 作为 REST API 的替代品。GraphQL 所提供的极大灵活性让它的缺点瑕不掩瑜。当然这里提到的优点和缺点可能并不总是适用于所有应用场景,但是值得在决定是否使用 GraphQL 时纳入考虑,希望我所提供的这些意见是否可以对你的项目有所帮助。


英文原文:


6 Months Of Using GraphQL


2020 年 6 月 12 日 17:5010614
用户头像

发布了 63 篇内容, 共 35.7 次阅读, 收获喜欢 113 次。

关注

评论

发布
暂无评论
发现更多内容

S型曲线 - 第一曲线

石云升

S型曲线 第一曲线 连续性创新

ARTS week 04

刘昱

游戏夜读 | 研发运营怎么分成?

game1night

如何设计电商行业亿级用户秒杀系统

奈学教育

大数据

食堂就餐卡系统架构设计

武鹏

原创 | TDD工具集:JUnit、AssertJ和Mockito (二十)编写测试-参数化测试

编程道与术

Java 学习 编程 TDD 单元测试

架构师(week1)总结

满山李子

日志标准化解析的关键内容

secisland

日志 态势感知 关联分析 解析规则 标准化

SaaS:小企业向左、大企业向右

人称T客

微服务架构中分布式事务实现方案怎样何取舍

奈学教育

当选择越来越多,我们为什么反而越来越不开心

七镜花园-董一凡

生活 情感

「架构师训练营」第1周学习总结

guoguo 👻

极客大学架构师训练营

LeetCode | 3. Roman to Integer 罗马数字转整数

Puran

算法 LeetCode arts

你现在极有可能是一个「铁锤人」

非著名程序员

读书笔记 程序员 提升认知 认知提升

极客时间<<架构师训练营>>第一周作业

好名字

极客大学架构师训练营 作业 第0期

课后总结-20200606

caibird1984

ARTS Week 1

黑色柳丁

ARTS 打卡计划

陆强作业

Mr.Monkey

JDK 15 JAVA 15的新特性展望

程序那些事

Java JVM Java 25 周年 新特性

架构师训练营第1周——学习总结

在野

极客大学架构师训练营

极客架构师训练营第一周

大丁💸💵💴💶🚀🐟

学习总结

Mr.Monkey

第一周总结 - 架构文档

孙志平

中台迷局丨只做IT的中台是个神棍

人称T客

内向的程序员如何改变自己,试试摆地摊吧

陆陆通通

程序员 摆地摊 诚信人生

java程序员从小工到专家成神之路(2020版)

程序那些事

Java 学习 Java 25 周年

架构师训练营-架构方法:架构师如何做架构

Pontus

极客大学架构师训练营

c# 之linq——小白入门级

moonlucy

架构方法论学习总结

第一周学习总结:

武鹏

微服务架构中分布式事务实现方案怎样何取舍【转发】

古月木易

微服务架构

用了6个月的GraphQL,真香!-InfoQ