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

Question

在了解了 GraphQL 并在几个项目中使用了它之后，我终于想试一试Prisma。它承诺消除对数据库的需求，并从 GraphQL Schema 生成一个 GraphQL 客户端和一个工作数据库。到现在为止还挺好。

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

为什么我更喜欢 Prisma 而不是自定义数据库解决方案？是否有必须将许多端点重新暴露给实际客户端的想法？

Answer 1

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

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

它承诺消除对数据库的需求，并从 GraphQL Schema 生成一个 GraphQL 客户端和一个工作数据库。到现在为止还挺好。

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

要找出具体的要点：

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

Answer 2

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

• Prisma 充当您的数据库的代理，为您提供随时可用的 GraphQL API，允许您过滤和排序数据以及一些自定义类型，例如DateTime不属于 graphql 的一部分，否则您必须自己实现。它不是 GraphQL 服务器。只是数据库和后端服务器之间的一层，如 ORM。

• 它涵盖了您可能从数据模型中获得的几乎所有可能的用例，以及在模式中预定义的所有CRUD操作以及订阅，因此您不必做所有这些事情，而是更多地关注您的业务逻辑方面事物。

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

• 您可以使用 API(graphql) 服务器仅向客户端公开所需的模式，而不是所有内容。由于 graphql 查询可以高度嵌套，因此实现它可能很困难且棘手，这也可能导致性能问题，而在 Prisma 中则不然，因为它自己处理所有事情。

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