五年时间，我们怎样构建一个 GraphQL API 组合？

工程师们都非常喜欢听好故事。我们花 5 年时间构建的由 GraphQL 组合的 API 现在上线了（峰值为每秒 110 个请求，延迟 100ms），这个过程应该是一个不错的故事。

我们的需求

多年来，Pipedrive（在 2020 年初已经 10 年了）一直有针我们的 webapp 的一个公开的 REST API，以及隐藏的未记录的端点——其中一个是 /users/self，这个接口最初是用来加载用户信息的，但是随着时间的推移，它变成了一个页面加载 API，由 30 种不同实体类型组成。它最初是在我们的 PHP 单体应用中创建的，本质上的同步的。我们尝试将它分离到并行线程中，但是结果并不太好。

针对现有流量的 /users/self 的延迟分布

从维护的角度来看，随着每一个新的改动，它变得更加混乱，因为没人想要负责这个巨大的端点。

直接数据库访问的概念验证项目

让我们回顾我们的开发人员刚接触 graphql 的时候。

大约 3-4 年前，在 marketplace 团队，我开始从我们的全栈工程师 Pavel 那里听到“elixir”和“graphql”之类的新术语。他参与了一个概念验证（proof-of-concept，PoC）项目，该项目直接访问 MySQL 并暴露 /graphql 端点来查询核心的 Pipedrive 实体。

原文链接:【https://www.infoq.cn/article/oKtOMtyXrpkRi5kU9J5u】。未经作者许可，禁止转载。