关于 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 绑定：使用任何数据库构建 GraphQL 服务器
很明显，开发人员构建复杂的 GraphQL 后端的需求无法通过像 Graphcool 这样的工具来满足。这种认识使我们走向了 Prisma。Prisma 的第一个版本是 Graphcool 查询引擎组件的独立版本。
通过将 Prisma 作为独立组件提供，我们使开发人员有机会为其数据库快速生成 CRUD GraphQL API。此 API 不是供前端消费的。相反，其想法是在其之上构建一个额外的应用程序层，以添加业务逻辑并自定义面向客户端的 API。
此应用程序层是使用 Prisma 绑定实现的。心智模型要求开发人员理解他们正在处理两个 GraphQL API（在生成的 CRUD API 之上的自定义面向客户端的 API）
虽然 Prisma 的主要目标仍然是让开发人员尽可能轻松地使用 GraphQL，但重点已转移到成为一个数据访问层，将您的 GraphQL 解析器与数据库连接起来。
3) Prisma 客户端：取代传统的 ORM
在与大量客户和 Prisma 社区交流后，我们对 Prisma 是什么（以及最终可能成为什么）的理解再次发生了很大的演变。
使用 Prisma 绑定构建 GraphQL 服务器的先前方法存在一些问题
- 虽然 Prisma 绑定使入门变得容易，但开发人员需要在更高级的用例中理解的概念的复杂性却急剧增加（由于 模式委托和
info对象的复杂性）。 - 非常困难且不切实际地实现完全类型安全的解析器。
- 仅限于 JavaScript 生态系统。
- 仅限于 GraphQL 作为用例。
Prisma 客户端解决了这些问题。它是一个自动生成的数据库客户端，具有简单且完全类型安全的数据访问 API。
使用这种新方法，生成的 CRUD GraphQL API 不再是核心 Prisma 开发工作流程的一部分。它更像是一个实现细节
请注意，很快将有一个版本的 Prisma 可以直接在您的应用程序服务器中使用，从而无需额外的 Prisma 服务器
虽然我们相信今天的 Prisma 客户端 API 已经是最好的数据访问 API 之一，但大量的社区反馈帮助我们进一步改进了它。结果是一个极其强大且直观的数据库 API，我们很快就会发布。
由于 Prisma 客户端具有内置的 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 绑定绝对必不可少，但在 Prisma 客户端中，它已成为实现细节。
这也反映在 Prisma 网站的最新重新设计中，其中 Prisma 客户端已取代 GraphQL 成为主要主题
弱化 Prisma 的 CRUD GraphQL API
今天，开发人员不应关心 Prisma 客户端如何与底层数据库通信。开发人员应该关心的是 Prisma 客户端 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 客户端发布以来，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 问题和 RFC 流程），因此请加入 GitHub 上的讨论，并与我们分享您的意见！
如果您有任何问题或意见，请 在 Spectrum 上分享它们。
我们正在招聘！ 正如您将发现的那样，路线图上的一个项目是用 Rust 完全重写 Prisma 核心。如果您是 Rust 工程师，或者只是对高技术挑战和开源开发普遍感兴趣，请务必查看我们的 招聘页面。
不要错过下一篇文章！
注册 Prisma 新闻通讯