五年時間,我們怎樣構建一個 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】。未經作者許可,禁止轉載。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章