關於 Prisma 與 GraphQL 之間的關係，存在許多困惑。本文將闡明開發者應如何看待 GraphQL 和 Prisma，並展望 Prisma 的未來。
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 伺服器
很明顯，Graphcool 這樣的工具無法滿足開發者構建複雜 GraphQL 後端的需求。這一認識促使我們開發了 Prisma。Prisma 的第一個版本是 Graphcool 的查詢引擎元件的獨立版本。
透過將 Prisma 作為獨立元件提供，我們讓開發者有機會快速為其資料庫生成一個 CRUD GraphQL API。這個 API 並不是供前端使用的。相反，其理念是在其之上構建一個額外的應用層，以新增業務邏輯並定製面向客戶端的 API。
這個應用層是使用Prisma bindings 實現的。這種心智模型要求開發者理解他們正在處理兩個 GraphQL API（一個自定義的面向客戶端的 API 在一個生成的 CRUD API 之上）
雖然 Prisma 的主要目標仍然是讓開發者儘可能輕鬆地使用 GraphQL，但其重心已經轉移到成為一個連線 GraphQL 解析器與資料庫的資料訪問層。
3) Prisma client：取代傳統 ORM
在與大量客戶和 Prisma 社群交流後，我們對 Prisma 是什麼（以及最終能成為什麼）的理解再次有了很大的發展。
之前使用 Prisma bindings 構建 GraphQL 伺服器的方法存在一些問題：
- 雖然 Prisma bindings 使得入門變得容易，但在更高階的用例中，開發者需要理解的概念的複雜性急劇增加（由於模式委託和
info物件的複雜性）。 - 實現完全型別安全的解析器非常困難且不切實際。
- 僅限於 JavaScript 生態系統。
- 僅限於 GraphQL 作為用例。
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 的核心理念始終如一：
- 開發者在 GraphQL SDL 中定義他們的資料模型，並將其對映到他們的資料庫
- Prisma 根據資料模型生成一個強大的 CRUD GraphQL API
- 生成的 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 的一個重要用例！
投資 GraphQL 生態系統
我們將繼續投資開源 GraphQL 生態系統。我們構建的許多工具已成為許多 GraphQL 開發工作流程中的預設選擇，例如 GraphQL Playground、graphql-yoga 和 GraphQL Nexus（由 Tim Griesser 構建）。
最近釋出的 nexus-prisma 使得在 Prisma 之上實現 GraphQL 伺服器變得異常簡單。藉助即將推出的 Yoga2 框架，我們進一步致力於為 GraphQL 創造一種 Ruby-on-Rails 般的開發者體驗。
為 GraphQL 社群做貢獻
與我們投資 GraphQL 生態系統類似，我們也希望為 GraphQL 社群做出貢獻。我們正在舉辦全球最大的 GraphQL 社群大會，並維護著諸如 How to GraphQL 和 GraphQL Weekly 等熱門資源。
雖然我們不是首批加入的公司之一，但我們也肯定計劃成為 GraphQL 基金會 的一部分，並幫助引導其未來方向。
🔮 展望未來
正如本文通篇所強調的，我們正在為 Prisma 帶來許多激動人心的根本性改進。要了解我們正在做的工作概覽，請隨時檢視我們的路線圖。
我們正在公開規範所有即將推出的功能（透過 GitHub Issues 和 RFC 流程），所以請加入 GitHub 上的討論，並與我們分享您的意見！
如果您有任何問題或評論，請在 Spectrum 上分享。
我們正在招聘！正如您將發現的，路線圖上有一項是使用 Rust 完全重寫 Prisma 核心。如果您是 Rust 工程師，或者對高技術挑戰和開源開發普遍感興趣，請務必檢視我們的招聘頁面。
不要錯過下一篇文章！
訂閱 Prisma 新聞郵件