为什么在后端环境中使用 Prisma？答案

【问题标题】：Why use Prisma in a backend environment?为什么在后端环境中使用 Prisma？
【发布时间】：2019-07-26 21:22:33
【问题描述】：

在学习了 GraphQL 并在几个项目中使用它之后，我终于想给Prisma 一个机会。它承诺消除对数据库的需求，并从 GraphQL Schema 生成 GraphQL 客户端和工作数据库。到目前为止一切顺利。

但我的问题是：对我来说，GraphQL 客户端真的只对客户端有用（防止过度获取、加快页面速度、React 集成……）。然而，Prisma 并没有消除对业务逻辑的需求，因此最终会使用 Node.js 中生成的客户端库，只是为了将另一个 GraphQL 服务器中的许多功能重新导出到实际客户端。

为什么我应该更喜欢 Prisma 而不是自定义数据库解决方案？是否必须将大量端点重新暴露给实际客户端？

【问题讨论】：

我刚刚向您在您的网站上找到的地址发送了一封电子邮件，并分享了我在回答中提到的博客文章的预览。我希望这能解决你所有的问题！如果您有任何其他问题，请告诉我。 @NikxDa
@nburk 感谢您的帮助！今晚我会查看博客文章，我会通过邮件回复你。感谢您的帮助！ :)
@nburk 我给你发了一封邮件。感谢您的洞察力！发布后，我会将博客文章编辑为您的答案。
太棒了，非常感谢您的反馈！很高兴听到这篇文章引起您的共鸣 :) 很高兴为您解答任何进一步的问题。

标签： graphql prisma

【解决方案1】：

即使我在开始学习 graphql 时也有类似的问题。这是我在使用后学到和体会到的。

Prisma 充当数据库的代理，为您提供现成的使用允许您过滤和排序数据的 GraphQL API 一些自定义类型，例如 DateTime，它们不是 graphql 的一部分，并且你必须以其他方式实现自己。它不是 GraphQL 服务器。只是一个像 ORM 一样在数据库和后端服务器之间分层。
它涵盖了您可能从具有在模式中预定义的所有 CRUD 操作的数据模型连同订阅，因此您不必做所有这些事情并更多地关注您的业务逻辑方面。
它还消除了您编写不同查询的依赖性不同的数据库（如 Sql 或 MongoDb）充当一个层将其查询语言转换为实际的数据库查询。
您可以使用 API(graphql) 服务器仅公开所需的架构给客户而不是一切。由于graphql查询可以得到高度嵌套，实现它可能是困难和棘手的也可能导致性能问题，这在 Prisma 中并非如此，因为它自己处理所有事情。

您可以查看此article 了解更多信息。

【讨论】：

【解决方案2】：

我在 Prisma 工作，很想澄清这一点！

这里有一个快速说明：Prisma 不是“GraphQL 即服务”工具（就像 Graphcool、AppSync 或 Hasura 那样）。 Prisma 客户端不是“GraphQL 客户端”，它是一个数据库客户端（类似于 ORM）。因此，在前端不使用 Prisma 客户端的原因与您不使用 ORM 或直接从前端连接到数据库的原因相同。

它承诺消除对数据库的需求，并从 GraphQL Schema 生成一个 GraphQL 客户端和一个工作数据库。到目前为止一切顺利。

我真的很想知道您究竟是从哪里得到这种感觉的！我们很清楚，我们需要改进关于 Prisma 提供的价值及其运作方式的沟通。你所阐述的关于 Prisma 的一个非常普遍的误解是我们希望在未来防止的。实际上，我们计划在下周发布一篇关于这个确切主题的博文，希望能澄清很多。

具体点：

Prisma 并没有消除对数据库的需求。与 ORM 类似，Prisma 客户端用于简化数据库访问。它还通过声明性数据建模和迁移方法使数据库迁移更容易（我们实际上目前正在对我们的迁移系统进行重大改进，您可以找到它的 RFC here）。
Prisma 的另一个主要优势是即将推出的数据管理工具 Prisma Admin。下周将提供第一个预览版。

【讨论】：