关于 Prisma 与 GraphQL 之间的关系，存在很多困惑。在本文中，我们阐明了开发人员应该如何看待 GraphQL 和 Prisma，并对 Prisma 的未来进行展望。
总结：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 新闻通讯
