GitHub采用了新的GraphQL API

Posted 2021-04-30 IT战略家

 

　　近期在 GitHub 全球大会上，GitHub 推出了新 API 的 alpha 预览版，该版 API 使用 Facebook 的 GraphQL（一种允许自服务 API 契约的查询语言）编写。GitHub 在其工程博客写道，GitHub 对 API 范式的转换主要是因为现有的 RESTful 契约缺乏可扩展性。为迎合大量各异客户的需求，REST 不能在提供 GitHub 所需灵活性的同时维持较低的维护代价。

 

　　GitHub 将现有 API 迁移到 GraphQL 的公告，与数日后 Facebook 将最终移除其服务的“技术预览”绰号的决定是遥相呼应的。

虽然早自 2002 年起，GraphQL 就已用于 Facebook 的生产环境中，但由于直至最近 GraphQL 的九月中期版本才得以开源，所以其在技术上依然是一个“预览版”。总体而言，社区对 GraphQL 表现出复杂的反应，一些人宣称GraphQL 给服务器端代码带来了不公平的额外复杂度和管理，也有一些人对 GraphQL 分隔各种个体消费者的数据消费需求和核心数据本身的能力青睐有加，认为这将使 API 更具可扩展性和多样性。

GitHub 在其工程博客上这样描述当前的 API：

不管我们提供了多少信息，来自集成商那里的反馈依然认为我们的 REST API 还不够灵活。有时为构成对一个资源的完整视图，需要做两次或三次单独调用。看上去尽管我们的响应同时发送了太多的数据，但是其中并未包括用户所需的数据。

这里 GitHub 暗示 GraphQL 非常适合于具有大量各异客户的应用场景，其中客户对底层数据具有复杂规模的需求。而对于为一个并没有多少开发人员消费的简单网站提供 API，GraphQL 并不能体现出其相对于 REST 的优越性。

 

　　在其工程博客中，GitHub 指出其 API 的历史开始于 2008 年。其中提及 GitHub 的第一个 RESTful API 成为了很多企业的样板，彼时这些企业正为精雕细琢其自身的 REST API 而寻找实例模板。GitHub 希望 GraphQL 能像其首次涉足 REST 时那样，为那些寻求很好的方式去从多消费者复杂数据需求中受益的开发人员和企业树立样板。

正如在 GraphQL 技术预览版发布后的 InfoQ 文章中，GraphSQL 的早期贡献者之一 Lee Byron 所说的：“社区不仅在使用 GraphQL，同时也在创建它。”作为 GraphQL 的首批主流用户之一，GitHub 自采用 GraphQL 以来就一直在转变它。在 GitHub 上，GraphQL 已从其早期的 javascript 构建，转变为使用从 Java 到 C# 和 Ruby（Ruby 是 GitHub 自身也在使用的）等多种语言构建，现在平台上已有种类繁多的开源工具。

 

　　虽然看上去 Githb 转到 GraphQL 的主要原因是为了实现适合各种客户所需的可扩展性，但是 GitHub 也提及很多额外的优点。在其技术博客中这样写道：“GraphQL 代表了 API 开发中的一个巨大飞跃。类型安全、内省、文档生成和可预测响应，这使我们平台的维护者和客户均可从中受益。”考虑到 GitHub 当前所呈现出的数据规模，文档生成和内省有益于数据的消费。

此外，Swagger 等工具非常有助于 RESTful API 的文档化，GitHub 确需贯穿整个代码库的手工注解创建，这些注解易于变成和代码注释一样的陈旧。GitHub 可以使用 GraphQL 所包括的所有工具，与相应的 API 改变和必要的 API 文档一起发布其中的软件，这对于 GitHub 及其用户而言均为一个重大利好。

 

来自: InfoQ

 

---

IT战略家

把握趋势，洞见未来

这里不打算迎合任何人的三观

但可以保证提供有深度的思考

欢迎长按关注

---