关于 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 schema（而不是通用的 CRUD）
- 在选择编程语言、框架、测试和 CI/CD 工具方面的灵活性
2) Prisma bindings：使用任何数据库构建 GraphQL 服务器
很明显，开发者在构建复杂的 GraphQL 后端方面的需求无法通过像 Graphcool 这样的工具来满足。这种认识引导我们走向了 Prisma。Prisma 的第一个版本是 Graphcool 的查询引擎组件的独立版本。
通过使 Prisma 作为独立组件提供，我们让开发者有机会快速为他们的数据库生成 CRUD GraphQL API。这个 API 不是要从前端消费的。相反，其想法是在其之上构建一个额外的应用层，以添加业务逻辑并自定义面向客户端的 API。
这个应用层是使用 Prisma bindings 实现的。心智模型要求开发者理解他们正在处理两个 GraphQL API（一个自定义的面向客户端的 API，位于生成的 CRUD API 之上）
虽然 Prisma 的主要目标仍然是尽可能让开发者轻松使用 GraphQL，但重点已经转移到成为一个数据访问层，将您的 GraphQL resolvers 与数据库连接起来。
3) Prisma client：取代传统的 ORM
在与大量客户和 Prisma 社区交流后，我们对 Prisma 是什么（以及最终可能成为什么）的理解再次有了很大的发展。
之前使用 Prisma bindings 构建 GraphQL 服务器的方法存在一些问题
- 虽然 Prisma bindings 使入门变得容易，但在更高级的用例中，开发者需要理解的概念的复杂性却急剧增加（由于 schema delegation 和
info对象的复杂性）。 - 非常困难且不切实际地实现完全类型安全的 resolvers。
- 仅限于 JavaScript 生态系统。
- 用例仅限于 GraphQL。
Prisma client 解决了这些问题。它是一个自动生成的数据库客户端，具有简单且完全类型安全的数据访问 API。
使用这种新方法，生成的 CRUD GraphQL API 不再是核心 Prisma 开发工作流程的一部分。它更像是一个实现细节
请注意，很快将有一个版本的 Prisma 可以直接在您的应用程序服务器中使用，从而无需额外的 Prisma 服务器
虽然我们认为今天的 Prisma client API 已经是最好的数据访问 API 之一，但大量的社区反馈帮助我们进一步改进了它。结果是一个极其强大且直观的数据库 API，我们将很快发布。
由于 Prisma client 内置了 dataloader，因此它是实现 GraphQL 服务器中 resolvers 的完美工具。
如何看待 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 schema 定义语言 (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 Foundation 的一部分，并帮助引导其未来的方向。
🔮 未来展望
正如本文通篇强调的那样，我们正在对 Prisma 进行许多令人兴奋和根本性的改进。要了解我们正在做什么，请随时查看我们的 roadmap。
我们正在公开规划所有即将推出的功能（通过 GitHub issues 和 RFC 流程），因此请加入 GitHub 上的讨论，并与我们分享您的意见！
如果您有任何问题或意见，请在 Spectrum 上分享。
我们正在招聘！ 您会发现，roadmap 上的一个项目是用 Rust 完全重写 Prisma 核心。如果您是 Rust 工程师，或者只是对高技术挑战和开源开发普遍感兴趣，请务必查看我们的 招聘页面。
不要错过下一篇文章！
注册 Prisma Newsletter
