Prisma 和 GraphQL 如何整合

TLDR：GraphQL 是 Prisma 的眾多用例之一

我們熱愛 GraphQL，並堅信它有光明的前景！我們將繼續投資 GraphQL 生態系統，並努力使 Prisma 成為構建資料庫支援 GraphQL 伺服器的最佳工具。我們努力的一個例子是即將推出的 Yoga2 框架，它將為 GraphQL 帶來類似 Ruby-on-Rails 的體驗。

Prisma 是 ORM 的替代品，除了 GraphQL 之外，還有更多用例，例如構建 REST 或 gRPC API。 Prisma 的目標是簡化資料庫工作流程。 將其視為一套資料庫工具，以簡化資料庫存取、遷移和資料管理。

---

歷史：從 GraphQL 到 ORM 和資料庫

讓我們從簡短的歷史課程開始，回顧 Prisma 如何演變成今天的樣子。

1) Graphcool：讓前端開發人員輕鬆使用 GraphQL

在 Prisma 發布和 正式品牌重塑 之前，我們的核心產品曾經是 Graphcool（一個開源 GraphQL BaaS）。從一開始，Graphcool 的目標就是讓開發人員盡可能輕鬆地使用 GraphQL。

由於 Graphcool 代表了整個後端堆疊，因此架構很簡單。它包括資料庫、應用程式層和 GraphQL API。

在 Graphcool 生產環境中運行兩年後，我們注意到以下反覆出現的客戶回饋和請求。

• Graphcool 因其易用性而備受喜愛。開發人員使用它進行原型設計，但隨後經常在生產環境中放棄它，轉而構建自己的 GraphQL 伺服器。
• 開發人員希望在其後端堆疊中獲得更多控制權和靈活性，例如
  • 將資料庫與 API 層解耦
  • 定義他們自己的網域驅動 GraphQL 模式（而不是通用 CRUD）
  • 在選擇程式語言、框架、測試和 CI/CD 工具方面的靈活性

2) Prisma bindings：使用任何資料庫構建 GraphQL 伺服器

很明顯，開發人員在構建複雜 GraphQL 後端方面的需求並未被像 Graphcool 這樣的工具滿足。這種意識引導我們走向 Prisma。Prisma 的第一個版本是 Graphcool 查詢引擎組件的獨立版本。

通過將 Prisma 作為獨立組件提供，我們使開發人員有機會為其資料庫快速生成 CRUD GraphQL API。此 API 並非要從前端使用。相反，其想法是在其之上構建額外的應用程式層，以添加業務邏輯並自訂面向客戶端的 API。

這個應用程式層是使用 Prisma bindings 實現的。心智模型要求開發人員理解他們正在處理兩個 GraphQL API（在生成的 CRUD API 之上的自訂面向客戶端的 API）。

雖然 Prisma 的主要目標仍然是讓開發人員盡可能輕鬆地使用 GraphQL，但重點已轉移到成為將您的 GraphQL 解析器與資料庫連接的資料存取層。

3) Prisma client：取代傳統 ORM

在與許多客戶和 Prisma 社群交談後，我們對 Prisma 是什麼（以及最終可能變成什麼）的理解再次發生了很大變化。

先前使用 Prisma bindings 構建 GraphQL 伺服器的方法存在一些問題

• 雖然 Prisma bindings 使入門變得容易，但在更高級的用例中，開發人員需要理解的概念的複雜性卻急劇增加（由於 schema delegation 和 info 物件的複雜性）。
• 非常困難且不切實際地實現完全型別安全的解析器。
• 僅限於 JavaScript 生態系統。
• 僅限於 GraphQL 作為用例。

The Prisma client 解決了這些問題。它是一個自動生成的資料庫客戶端，具有簡單且完全型別安全的資料存取 API。

採用這種新方法，生成的 CRUD GraphQL API 不再是核心 Prisma 開發工作流程的一部分。相反，它成為一個實作細節。

請注意，很快將會有一個版本的 Prisma 可以在您的應用程式伺服器中直接使用，從而無需額外的 Prisma 伺服器。

雖然我們認為今天的 Prisma client API 已經是市面上最好的資料存取 API 之一，但大量的社群回饋幫助我們進一步改進了它。結果是一個極其強大且直覺的資料庫 API，我們將很快發布。

由於 Prisma client 具有內建的 dataloader，因此它是實作 GraphQL 伺服器中解析器的完美工具。

---

如何看待 Prisma 生成的 GraphQL API

理解生成的 Prisma GraphQL CRUD API 被認為是一個實作細節，對於理解 Prisma 的重點和未來方向至關重要。

從宣告式資料模型到生成的 GraphQL CRUD

Prisma 的核心理念始終如一

1. 開發人員在 GraphQL SDL 中定義其資料模型並將其映射到其資料庫
2. Prisma 基於資料模型生成強大的 CRUD GraphQL API
3. 生成的 CRUD GraphQL API 用作應用程式層和面向客戶端的 API 的基礎（Graphcool 除外）

雖然生成的 CRUD GraphQL API 對於 Prisma bindings 絕對是必不可少的，但對於 Prisma client 來說，它已成為一個實作細節。

這也反映在 Prisma 網站 的最新改版中，其中 Prisma client 已取代 GraphQL 成為主要主題。

弱化 Prisma 的 CRUD GraphQL API

今天，開發人員不應關心 Prisma client 如何與底層資料庫對話。 開發人員應該關心的是 Prisma client API！

為了在我們的官方文件中反映這一點，我們在最新的 Prisma 版本中移除了 Prisma GraphQL API 文件。如果您仍然需要該文件，您可以通過導航到 文件中的舊版 Prisma 來存取它。

我們還剛剛推出了 Prisma Admin 作為與您的 Prisma 專案中的資料互動的額外工具（除了 GraphQL Playground 之外）。

在 GraphQL SDL 中進行資料建模

關於 Prisma 和 GraphQL 的另一個常見混淆來源可能是資料建模。使用 Prisma 時，資料模型是使用 GraphQL 模式定義語言 (SDL) 的子集指定的。

雖然我們已經將資料模型的文件類型從 .graphql 調整為 .prisma，但使用 SDL 進行資料建模仍然與 GraphQL 有很強的關聯。但是，我們目前正在開發我們自己的模型語言（它將是 SDL 的修改版本）。

將 Prisma 與 AWS AppSync 和 Hasura 進行比較

隨著對 Prisma 的 CRUD GraphQL API 作用的新理解，很明顯 Prisma 不再屬於「GraphQL 即服務」的範疇。

像 AWS AppSync 和 Hasura 這樣的工具為您的資料庫（或在 AppSync 的情況下也包括其他資料來源）提供生成的 GraphQL API。相比之下，Prisma 可以在各種語言中實現簡化且型別安全的資料庫存取。

---

GraphQL 是 Prisma 的重要用例

自 Prisma client 發布以來，Prisma 在底層使用 GraphQL 被認為是一個實作細節。那麼 GraphQL 對於 Prisma 來說扮演什麼角色呢？

我們熱愛 GraphQL

對我們來說答案很明確：我們仍然認為 GraphQL 是最重要的即將到來的 API 技術之一，並希望使開發人員盡可能輕鬆地構建 GraphQL 伺服器。GraphQL 仍然是 Prisma 的重要 Prisma 用例！

投資 GraphQL 生態系統

我們將繼續投資開源 GraphQL 生態系統。我們構建的許多工具已成為許多 GraphQL 開發工作流程中的預設工具，例如 GraphQL Playground、graphql-yoga 和 GraphQL Nexus（由 Tim Griesser 構建）。

The 最近宣布的 nexus-prisma 使在 Prisma 之上實作 GraphQL 伺服器變得非常容易。借助即將推出的 Yoga2 框架，我們進一步旨在為 GraphQL 創建 Ruby-on-Rails 開發人員體驗。

為 GraphQL 社群做出貢獻

與我們投資 GraphQL 生態系統的方式類似，我們希望為 GraphQL 社群做出貢獻。我們正在舉辦世界上最大的 GraphQL 社群會議，並維護熱門資源，例如 How to GraphQL 和 GraphQL Weekly。

雖然我們不是首批加入的公司之一，但我們當然也計劃成為 GraphQL 基金會 的一部分，並幫助引導其未來方向。

---

🔮 一窺未來

正如本文通篇強調的那樣，我們正在對 Prisma 進行許多令人興奮和根本性的改進。要了解我們正在做什麼的概述，請隨時查看我們的 路線圖。

我們正在公開說明所有即將推出的功能（通過 GitHub issue 和 RFC 流程），因此請加入 GitHub 上的討論，並與我們分享您的意見！

如果您有任何問題或意見，請在 Spectrum 上分享。

我們正在招聘！ 正如您將發現的那樣，路線圖上的一個項目是用 Rust 完全重寫 Prisma 核心。如果您是 Rust 工程師，或者只是對高技術挑戰和開源開發感興趣，請務必查看我們的 職位頁面。