超越 REST

作者 | Dane Avilla

策劃 | 田曉旭

娛樂業一直在努力應對 COVID-19 對全球製作的影響衝擊。自 2020 年初以來,Netflix 一直在迭代開發系統,以向內部利益相關方和企業領導者提供有關疫情最新信息的最新工具和儀表盤。這些軟件解決方案使得管理層可以就給定的實體產品是否以及何時能夠安全地開始在全球範圍內創建引人注目的內容而做出最明智的決策。在 Netflix Studio Engineering 內部,一種備受關注的方法是將 GraphQL 微服務(GQLMS)作爲後端平臺來促進應用程序的快速開發。

許多組織都在擁抱 GraphQL,以其作爲統一企業範圍內數據模型的一種方式,並提供了一個用其相關實體網絡來導航大量結構化數據的單一入口點。這種努力值得稱讚,但往往需要內部組織之間歷經幾個季度的協調,然後將所有相關實體開發並集成到一個單一的單體圖中。

GraphiQL:爲 《星球大戰》API 自動生成的測試 GUI

我們的經驗已經爲對 GQLMS 作爲快速開發平臺感興趣的團隊帶來了一個具有許多最佳實踐的架構。

1Graphile

在早期的 GraphQL 探索過程中,Netflix 的工程師意識到 Graphile 庫可以將 PostgreSQL 數據庫對象(表、視圖和函數)作爲 GraphQL API 來呈現。Graphile 支持 智能註解,支持通過使用特定格式的 PostgreSQL 註解標記數據庫的表、視圖、列和類型來控制各種特性。文檔甚至可以嵌入到數據庫註解中,以便在 Graphile 生成的 GraphQL 模式中顯示。

我們假設有一個 Docker 容器,其上運行了一個帶有 Graphile 庫的非常簡單的 NodeJS Web 服務器(以及一些用於安全、日誌、度量和監控的 Netflix 內部組件),可以爲快速開發工作提供 “比 REST 更好的 REST” 或“REST++”平臺。使用 Docker,我們定義了一個輕量級的獨立容器,它允許我們將 Graphile 庫及其支持的代碼打包成一個獨立的包,任何團隊都可以在 Netflix 上使用它,而無需額外的編碼。只需下拉定義 Docker 的基礎鏡像,並使用適當的數據庫連接符運行它即可。這種方法被證明是非常成功的,並且對 Graphile 的使用產生了一些深刻洞察。

具體來說:

2 數據庫視圖作爲 API

我們決定將數據表放在一個 PostgreSQL 模式中,然後在另一個模式中定義這些表的視圖,同時 Graphile Web 應用程序使用專用的 PostgreSQL 用戶角色連接到數據庫。這最終能實現幾個不同的目標:

關於最後一點:更改表中列的類型將會打破關聯的視圖,但是通過封裝在事務中的更改,可以刪除視圖、更新該列,然後可以在提交事務之前重新創建視圖。我們在啓用 pgWatch 的情況下運行 Graphile,只要對數據庫做任何更新,GraphQL 模式就會立即更新以反映所做的更改。

3PostgreSQL 複合類型

Graphile 在讀取 PostgreSQL 數據庫模式以及將表和基本視圖轉換爲 GraphQL 模式方面做得非常出色,但我們的經驗表明,當視圖中存在 PostgreSQL 聚合函數 或 JSON 函數 時,Graphile 在如何描述嵌套類型方面存在侷限性。原生 PostgreSQL 函數,比如json_build_object,將被轉換成 GraphQLJSON類型,該類型只是一個String,沒有任何內部結構。例如,以這個返回JSON對象的簡單視圖爲例:

1postgres_test_db=# create view postgraphile.json_object_example as
2  select json_build_object(‘hello world’::text, 1, ‘2’::text, 3)
3  as json;
4postgres_test_db=# select * from postgraphile.json_object_example;
5          json
6— — — — — — — — — — — — -
7{“hello world”: 1, “2”: 3}
8(1 row)
9

在生成的模式中,數據類型爲JSON

json字段的內部結構(hello world2這兩個子字段)在生成的 GraphQL 模式中是不透明的。

爲了進一步描述json字段的內部結構(將其在生成的模式中公開),定義一個複合類型,並創建一個返回該類型的視圖:

1postgres_test_db=# CREATE TYPE postgraphile.custom_type AS (
2  "hello world" integer,
3  "2" integer
4);
5

接下來,創建一個返回該類型的函數:

1postgres_test_db=# CREATE FUNCTION postgraphile.custom_type(
2  "hello world" integer,
3  "2" integer
4)
5RETURNS postgraphile.custom_type
6AS 'select $1, $2'
7LANGUAGE SQL;
8

最後,創建一個返回該類型的視圖:

1postgres_test_db=# create view postgraphile.json_object_example2 as
2  select postgraphile.custom_type(1, 3)
3  as json;
4postgres_test_db=# select * from postgraphile.json_object_example2;
5 json
6— — — -
7(1,3)
8(1 row)
9

乍一看,這似乎沒有什麼用,但要記住:在查看生成的模式之前,請在視圖、自定義類型和自定義類型的字段上定義註解,以利用 Graphile 的智能註解:

 1postgres_test_db=# comment on
 2  type postgraphile.custom_type
 3  is E’A description for the custom type’;
 4postgres_test_db=# comment on
 5  view postgraphile.json_object_example2
 6  is E’A description for the view’;
 7postgres_test_db=# comment on
 8  column postgraphile.custom_type.”hello world”
 9  is E’A description for hello world’;
10postgres_test_db=# comment on
11  column postgraphile.custom_type.field_2
12  is E’@name field_two\nA description for the second field’;
13

現在,當查看模式時,json字段不再顯示爲不透明的類型JSON,而是顯示爲CustomType

(還要注意,對視圖所做的註解(A description for the view)顯示在查詢字段的文檔中)。

單擊CustomType將顯示自定義類型的字段及其註解:

請注意,在自定義類型中,第二個字段被命名爲field_2,但 Graphile 智能註解將該字段重命名爲field_two,通過 Graphile 將駝峯式大小寫轉換爲fieldTwo。另外,對這兩個字段的描述都被顯示在生成的 GraphQL 模式中。

4 允許 Graphile 生成的模式具有 “所有權限”(在開發期間)

最初,當討論使用 Graphile 作爲 “一種模式來管理所有模式” 架構中的一個選項時,該提議遭到了強烈的反對。關於安全性(如何將其與我們的 IAM 基礎設施集成,以及如何在數據庫中實施行級訪問控制?)和性能(如何限制查詢以避免一次選擇所有行來對數據庫進行 DDoS 攻擊?)的合法性問題引起了人們的關注,提出了使用類似於 SQL 的查詢接口以提供對數據庫表的打開權限(open access)。然而,在小團隊快速開發內部應用程序的 GQLMS 環境中,默認的 Graphile 行爲是讓所有列都可用來過濾,這允許 UI 團隊可以快速迭代大量新特性,而無需後端團隊的參與。這與其他開發模型不同,在其他模型中,UI 和後端團隊首先就初始 API 契約達成一致,後端團隊實現 API,UI 團隊使用 API,然後 API 契約隨着 UI 需求在開發生命週期中的變化而演變。

最初,整個應用程序的性能很差,因爲 UI 通常需要多次查詢才能獲取所需的數據。然而,一旦應用程序的行爲被充實起來,我們就可以快速創建新視圖,以滿足每個 UI 交互的需求,這樣每次交互只需要一個調用即可。因爲這些請求是以本機代碼運行在數據庫上,所以我們可以通過適當地使用索引、去規範化、集羣等來執行復雜的查詢並獲得高性能。

一旦 UI 和後端之間的 “公共 API”(“public API”)固化,我們就“加固” 了 GraphQL 模式,通過使用智能註解@omit標記表和視圖來刪除所有不必要的查詢(由 Graphile 的默認設置創建)。另外,Graphile 的默認行爲是爲表和視圖生成突變,但是智能註解@omit create,update,delete將從模式中刪除突變。

5 結論

對於那些採用模式優先方法進行 GraphQL API 開發中的用戶來說,Graphile 的自動 GraphQL 模式生成功能可能會對模式設計者造成難以接受的限制。如果需要細粒度的訪問控制,Graphile 可能很難集成到現有的企業 IAM 基礎設施中。向 Graphile 生成的模式中添加自定義查詢和突變(即公開 UI 所需的 gRPC 服務調用)是我們目前在 Docker 鏡像中不支持的。然而,我們最近注意到 Graphile 的 makeExtendSchemaPlugin,它允許將自定義類型、查詢和突變合併到 Graphile 生成的模式中。

也就是說,在初始需求有限並且有一個臨時的分佈式團隊(之前沒有合作過)的情況下,一個內部應用在 4-6 周內就能成功實現,這引起了整個 Netflix Studio 的極大興趣。Netflix 的其他團隊也正在尋找對應的 GQLMS 方法:

  1. 使用標準的 GraphQL 構造函數和實用程序將數據庫公開爲 API

  2. 利用自定義的 PostgreSQL 類型構建 GraphQL 模式

  3. 通過從數據庫自動生成大型 API 來提高靈活性

  4. 並在 Graphile 生成的業務邏輯和數據類型之外,額外公開其他自定義的業務邏輯和數據類型

這是一個替代之前使用 REST 實現內部 CRUD 工具的可行解決方案。擁有託管 Graphile 的標準化 Docker 容器爲團隊提供了必要的基礎設施,通過這些基礎設施,他們可以快速迭代新工具的原型以及快速開發應用程序,從而解決全球媒體工作室在這個充滿挑戰時期內不斷變化的需求。

原文鏈接:

https://netflixtechblog.com/beyond-rest-1b76f7c20ef6

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/9Bkcaf5sNaXZN0GovG4fqw