关于 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 新闻邮件