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

Question

在学习了GraphQL并在一些项目中使用它之后，我终于想尝试一下Prisma。它promise消除对数据库的需求，并从GraphQL模式中生成一个GraphQL客户端和一个工作数据库。到目前为止还不错。

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

为什么我更喜欢Prisma而不是自定义数据库解决方案？在必须向实际客户机重新公开大量endpoint的背后有什么想法吗？

Answer 1

当我开始学习图形时，甚至我也有类似的问题。这是我在使用它后学到并意识到的。

>

Prisma作为您的数据库的代理，为您提供一个现成的GraphQL API，允许您过滤和排序数据以及一些自定义类型，如DateTime，这些类型不是GraphQL的一部分必须以其他方式实现自己。它不是GraphQL服务器。只是数据库和后端服务器之间的一层，就像ORM一样。

它涵盖了数据模型中几乎所有可能的用例，其中所有CRUD操作都是在模式中预先定义的，还有订阅，因此您不必做所有这些事情，只需更多地关注业务逻辑方面的事情。

它还消除了为不同数据库编写不同查询的依赖性，如Sql或MongoDb，作为将其查询语言转换为实际数据库查询的层。

您可以使用API（graphql）服务器仅向客户机公开所需的架构，而不是所有内容。由于graphql查询可以得到高度嵌套，因此实现这些查询可能很困难，也很棘手，这可能会导致性能问题，而Prisma却不是这样，因为它自己处理所有事情。

您可以查看这篇文章了解更多信息。

Answer 2

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

这里有一个简短的提示：Prisma不是一个“GraphQL-as-a-Service”工具（以GraphTool、AppSync或Hasura的方式）。Prisma客户端不是“GraphQL客户端”，而是数据库客户端（类似于ORM）。因此，不在前端使用Prisma客户端的原因与不使用ORM或不直接从前端连接到DB的原因相同。

它promise不再需要数据库，并从GraphQL模式生成GraphQL客户机和工作数据库。到现在为止，一直都还不错。

我真的很想知道你到底是从哪里得到这种感觉的！我们很清楚，我们需要改善关于Prisma提供的价值及其工作方式的沟通。你所阐述的是一个关于棱镜的极其普遍的误解，我们希望在未来防止这种误解。事实上，我们计划下周发表一篇关于这个话题的博客文章，希望这能澄清很多。

为了抓住具体的要点：

• Prisma并没有消除对数据库的需求。与ORM类似，Prisma客户端用于简化数据库访问。它还通过声明性数据建模和迁移方法简化了数据库迁移（实际上，我们目前正在对迁移系统进行大规模改进，您可以在这里找到RFC）