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 服务器
很明显，Graphcool 这样的工具无法满足开发者构建复杂 GraphQL 后端的需求。这一认识促使我们转向 Prisma。Prisma 的第一个版本是 Graphcool 查询引擎组件的独立版本。
通过将 Prisma 作为独立组件提供，我们让开发者有机会为其数据库快速生成一个 CRUD GraphQL API。这个 API 不用于前端消费。相反，其理念是在其之上构建一个额外的应用层，以添加业务逻辑并自定义面向客户端的 API。
这个应用层使用 Prisma bindings 实现。这种心智模型要求开发者理解他们正在处理两个 GraphQL API（一个在生成的 CRUD API 之上的自定义面向客户端 API）
虽然 Prisma 的主要目标仍然是让开发者尽可能轻松地使用 GraphQL，但焦点已转移到成为连接 GraphQL 解析器与数据库的数据访问层。
3) Prisma client：替代传统 ORM
在与大量客户和 Prisma 社区交流后，我们对 Prisma 是什么（以及最终可能成为什么）的理解又有了很大的发展。
之前使用 Prisma bindings 构建 GraphQL 服务器的方法存在一些问题
- 虽然 Prisma bindings 使入门变得容易，但在更高级的用例中，开发者需要理解的概念的复杂性飙升（由于 schema delegation 和
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 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 进行许多令人兴奋和基础性的改进。要了解我们正在进行的工作概况，请随时查看我们的 路线图。
我们正在公开（通过 GitHub issues 和 RFC 流程）详细说明所有即将推出的功能，因此请加入 GitHub 上的讨论，并与我们分享您的意见！
如果您有任何问题或意见，请在 Spectrum 上分享。
我们正在招聘！如您所见，路线图上的一个项目是使用 Rust 完全重写 Prisma 核心。如果您是 Rust 工程师或只是对高技术挑战和开源开发感兴趣，请务必查看我们的 招聘页面。
不要错过下一篇文章！
订阅 Prisma 新闻通讯