Prisma 查询引擎是用 Rust 编写的,一直是 Prisma ORM 的核心部分。它的开发是为了未来,但不再与 Prisma ORM 当前的方向兼容。请继续阅读以了解更多关于我们从 Rust 重写为 TypeScript 的信息。
Prisma 现在要做什么?!
在我们最近发布的 ORM 宣言中,我们描述了 Prisma ORM 在未来几个月和几年内的管理方式。其中一个小小的包含是以下内容
我们正在通过将 Prisma 的核心逻辑从 Rust 迁移到 TypeScript,并重新设计 ORM 以使定制和扩展更容易来解决这个问题。
这可能只是我们帖子中的一句话,但它引起了相当多的反响
例如,我们非常喜欢 Theo 的这个视频
总而言之,这些都是相当合理的反应。Rust 查询引擎从一开始就与 Prisma ORM 同在。我们在线上看到的讨论很棒,但我们也想介入并提供一些更新,因为我们的 TypeScript 实现正在接近 Early Access 阶段。
简而言之,我们想让社区中的每个人都了解正在发生什么变化,这些变化背后的动机,以及这些变化将如何实施。
为什么 Prisma 选择 Rust?
在我们探索 Prisma ORM 的未来之前,我们需要了解为什么 Prisma ORM 使用 Rust 引擎。当我们开始规划 Prisma 2(现在称为 Prisma ORM)时,我们有一个非常清晰的愿景:我们想为尽可能多的语言构建 ORM——TypeScript、Go、Python、Scala、Rust 和其他语言。我们需要一个解决方案,使添加对新语言的支持相对简单。Rust 的性能优势和系统级方法使其成为这个核心查询引擎的自然选择。
这个决定也是对 GraphCool 和 Prisma 1 上所做工作的延续。这些早期解决方案的核心、可部署的基础设施演变为基于 Rust 的查询引擎——一个旨在处理生成 SQL 查询、管理连接池和从数据库返回结果的繁重工作的二进制文件。这使得诸如 prisma-client-js
之类的特定于语言的客户端可以保持在引擎之上的轻量级层。
为什么要放弃 Rust?
虽然拥有强大的 Rust 引擎帮助我们快速交付了出色的性能,但我们后来发现它带来了一些明显的挑战
- 技能门槛: 贡献查询引擎需要 Rust 和 TypeScript 技能的结合,减少了社区参与的机会。
- 部署复杂性: 每个操作系统和 OpenSSL 库版本都需要自己的二进制文件,这使得部署复杂化并减慢了开发速度。
- 兼容性问题: 现代 JavaScript 运行时、无服务器和边缘环境并不总是与大型 Rust 二进制文件兼容,这限制了 Prisma 的部署方式和部署地点。
此外,查询引擎的核心优势——支持多个客户端的能力——不再是我们的重点。Prisma ORM 是一个 TypeScript 项目,虽然我们支持我们的社区客户端,但我们不会在内部开发它们。
考虑到这些因素,并加上我们致力于构建一个包容性的、社区驱动的生态系统(正如我们在ORM 宣言中概述的那样),这促使我们尽可能多地将我们的 Rust 查询引擎中的组件迁移到 TypeScript——简化贡献并减少部署难题,同时不牺牲 Prisma ORM 用户已知和喜爱的开发者体验。
重新定义查询执行
我们在 Early Access 中引入的主要架构更改涉及将查询执行和数据库结果处理从 Rust 移至 TypeScript。
为了理解这个变化,让我们回顾一下当前的查询引擎设置。
今天 Prisma ORM 查询的执行
今天,您可以通过两种方式使用 Prisma ORM 查询数据库
- 使用用 Rust 编写的数据库驱动程序。
- 使用用 TypeScript 编写的 驱动程序适配器 和驱动程序。
在第一种方法中,Prisma ORM 查询被传递到用 Rust 编写的查询引擎。这个引擎管理着从构建查询计划到执行查询并将结果返回给 JavaScript 客户端的所有事情
然而,这种架构无法支持仅提供 JavaScript 驱动程序的数据库,例如 D1 和 Turso。为了解决这个限制,我们引入了驱动程序适配器。
当使用驱动程序适配器时,查询引擎仍然制定查询计划并生成 SQL 语句。然而,执行通过驱动程序适配器委托给数据库
这种方法实现了与 JavaScript 驱动程序的兼容性,但也引入了一个权衡:数据必须从 JavaScript 序列化到 Rust,然后再序列化回 JavaScript,从而降低了效率并抵消了这种方法的一些好处。
明天 Prisma ORM 查询的执行
在新的架构中,驱动程序适配器将继续使用。然而,Prisma ORM 将查询传递给 WASM 编译器,而不是依赖于基于 Rust 的查询引擎,WASM 编译器将返回查询计划。然后,这个计划将完全在 TypeScript 中执行
这种简化的架构带来了几个直接的好处
- 保留对经过验证的 JavaScript 数据库驱动程序的支持。
- 减少 JavaScript 和 Rust 之间数据转换的需求。
- 最大限度地减少 Rust 和 JavaScript 之间传输的数据量。
- 消除了运送外部二进制文件的需要,因为查询编译器不再依赖于系统特定的实用程序。
通过将查询执行转移到 TypeScript,我们简化了架构,并增强了开发人员的兼容性和性能。
即将到来的精简体验
跨语言移动逻辑是一项重大转型,但我们正在逐步进行,以最大限度地减少中断。虽然这些变化是实质性的,但我们的首要任务是确保平稳过渡,保持您对 Prisma 的期望的简单性和可靠性。在这次迁移中,我们不仅要解决今天的挑战,还要为增强开发者体验奠定基础。
迈向平稳过渡的步骤
我们的工程团队正在逐步将查询引擎逻辑过渡到代码库的 TypeScript 侧。尚无法移动的组件正在被重新打包到包含在 @prisma/client
npm 模块中的 WASM 文件中。这个 WASM 文件充当查询编译器,简化了工作流程,而无需进行重大的 API 更改。
例如,我们计划删除对 binaryTargets
的要求,进一步简化开发者体验。总的来说,Prisma ORM 体验将保持熟悉和直观。
解锁未来的机会
这种转变不仅仅是为了解决当前的挑战——它为创新创造了新的机会。事实上,查询编译器为我们的团队和社区探索许多可能性提供了条件。例如,使用参数化查询计划可以保存查询计划以供重用,从而加快执行速度。另一种途径是在编译时构建初始查询计划,进一步减少运行时计算需求。
我们对这些可能性感到兴奋,并渴望听到您的想法!加入我们在 GitHub 或 Discord 上的讨论。
帮助我们构建更好的 Prisma ORM 体验
这个项目是朝着使 Prisma ORM 对每个人都更好的重要一步。Prisma ORM 的核心是为像您这样的开发者构建的。您的反馈和协作对这个旅程至关重要。
以下是您可以提供帮助的方式
- 提交 issue 以报告错误或建议功能。
- 使用讨论 来分享您的想法。
- 加入我们的 Discord 以参与社区活动和开发者 AMA。
最后,测试我们的 Early Access 客户端!我们将在 GitHub 和 Discord 上分享更新。
对于 Prisma 来说,这是一个激动人心的时刻,未来会有更多改进和机会。感谢您激励我们成长,并感谢您成为这个旅程的一部分。
想成为首批试用我们新的 Early Access 客户端的用户吗?在 X 上关注我们 并 加入我们的 Discord 以保持更新。
不要错过下一篇文章!
注册 Prisma Newsletter