为啥在后端环境中使用 Prisma?

Posted

技术标签:

【中文标题】为啥在后端环境中使用 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 我给你发了一封邮件。感谢您的洞察力!发布后,我会将博客文章编辑为您的答案。 太棒了,非常感谢您的反馈!很高兴听到这篇文章引起您的共鸣 :) 很高兴为您解答任何进一步的问题。 【参考方案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。下周将提供第一个预览版。

【讨论】:

以上是关于为啥在后端环境中使用 Prisma?的主要内容,如果未能解决你的问题,请参考以下文章

Prisma 和 ApolloClient:防止前端覆盖关系的后端包含条件

flutter_bloc - 为啥在 UI 而不是后端声明存储库?

节点刷新令牌为啥不在后端刷新

GAE:进程终止,因为后端在后端作业中关闭的时间过长

prisma 服务器边订阅试用

如何在后端 API 中验证 AzureAD accessToken