后端数据库GraphQL【免费下载链接】prisma1 Database Tools incl. ORM, Migrations and Admin UI (Postgres, MySQL MongoDB) [deprecated]项目地址https://gitcode.com/gh_mirrors/pr/prisma1点击查看免费下载导读服务端订阅Server-side Subscriptions是 Prisma 在 GraphQL 订阅能力之外提供的事件通知机制它复用 GraphQL 订阅的查询语法与过滤能力但通过Webhook将数据变更事件投递给外部业务系统天然适配现代 Serverless 基础设施。本文以 docs/1.3/04-Reference/04-Server_side-Subscriptions/01-Overview.md 为核心骨架结合仓库内 API 服务器、Worker 服务器与共享模型的源码实现系统讲解服务端订阅的配置方法、事件投递链路与订阅查询语法读完即可在自己的 Prisma 服务中落地数据变更 → HTTP 回调的完整方案。服务端订阅是什么服务端订阅与普通的 GraphQL 订阅见 GraphQL API 参考在能力上是等价的它们共享同一套 API例如同样支持在where中提供过滤条件从而只接收你感兴趣的事件。两者的核心差异在于投递机制delivery mechanism普通 GraphQL 订阅客户端建立持久连接WebSocketPrisma 在数据变更发生时把事件实时推送到客户端。服务端订阅当服务端订阅被配置好后Prisma 会持续监控数据变更并在匹配时执行与之关联的查询——这一点与普通 GraphQL 订阅一致——但事件的消费方不再是连接的客户端而是你配置的外部端点。从源码看服务端订阅被建模为一等公民的函数类型。在 server/shared-models/src/main/scala/com/prisma/shared/models/Functions.scala 中FunctionType枚举定义了ServerSideSubscription值对应的ServerSideSubscriptionFunction同时持有name、isActive、delivery和query四个字段其中delivery当前只有一种实现——WebhookDelivery包含url与headerscase class ServerSideSubscriptionFunction( name: String, isActive: Boolean, delivery: FunctionDelivery, query: String ) extends Function sealed trait FunctionDelivery { def typeCode: FunctionDeliveryType.Value } object FunctionDeliveryType extends Enumeration { val WebhookDelivery Value(webhook-delivery) } case class WebhookDelivery( url: String, headers: Vector[(String, String)] ) extends FunctionDelivery这印证了文档中的描述当前 Prisma 通过 Webhook 投递服务端订阅事件同时按照 01-Overview.md 的说明未来计划补充直接调用 AWS Lambda 以及不同的队列queue实现。服务端订阅正是为与现代 Serverless 基础设施协同工作而设计的你无需维护常驻的订阅连接只需暴露一个 HTTP 端点接收回调。事件投递链路从 Mutation 到 Webhook理解服务端订阅最好的方式是追踪一次数据变更如何最终变成一次 HTTP 请求。结合仓库源码完整链路如下变更进入 API 服务器客户端执行一次 GraphQL mutation例如updateUser。生成副作用动作API 服务器将 mutation 解析为内部的动作序列其中与服务端订阅相关的动作是ExecuteServerSideSubscription。在 server/servers/api/src/main/scala/com/prisma/api/mutactions/SideEffectMutactionExecutor.scala 中SideEffectMutactionExecutorImpl.execute按类型分发def execute(mutaction: SideEffectMutaction): Future[Unit] mutaction match { case mutaction: PublishSubscriptionEvent PublishSubscriptionEventExecutor.execute(mutaction, apiDependencies.sssEventsPubSub) case mutaction: ExecuteServerSideSubscription ServerSideSubscriptionExecutor.execute(mutaction) }执行订阅查询并构造 WebhookServerSideSubscriptionExecutor.deliverWebhook调用SubscriptionExecutor.execute以skipPermissionCheck true、alwaysQueryMasterDatabase true的方式执行订阅函数中配置的查询只有当返回结果包含data键即事件确实匹配了过滤条件时才构造一个Webhook并发布到webhookPublishersubscriptionResult.map { case Some(json) if json.as[JsObject].keys.contains(data) val webhook Webhook( projectId project.id, functionName function.name, requestId requestId, url webhookDelivery.url, payload json.toString, id requestId, headers webhookDelivery.headers.toMap ) apiDependencies.webhookPublisher.publish(webhook) case _ () }Worker 服务器投递投递动作最终落到 server/servers/workers/src/main/scala/com/prisma/workers/WebhookDelivererWorker.scala。该 Worker 从消息总线队列消费Webhook使用SimpleHttpClient.post以Content-Type: application/json向配置的url发送POST请求并把配置的 headers 一并带上httpClient .post(wh.url, wh.payload, ContentTypes.application/json, wh.headers.toList) .recover { ... }注意其中的注释// Current decision: Do not retry delivery, treat all return codes as work item success ( ack).——从源码看当前实现不对投递失败进行重试所有返回码都被视为工作项成功即确认消费失败仅在日志中输出。如果你在真实环境使用该版本的服务端订阅应基于这个前提设计你自己的重试与告警策略。Webhook数据结构定义在 server/servers/api/src/main/scala/com/prisma/subscriptions/Webhook.scala包含projectId、functionName、requestId、url、payload、id、headers等字段方便在消息总线中流转与追踪。在 prisma.yml 中配置服务端订阅服务端订阅通过在服务配置文件prisma.yml中添加subscriptions属性来完成配置。subscriptions是一个映射map每个键对应一个订阅函数的名称其值描述该订阅的投递方式当前为webhook与订阅查询query。完整配置示例下面是 01-Overview.md 中给出的完整示例它定义了一个名为userChangedEmail的服务端订阅当任意user节点被更新时向http://example.org/sendSlackMessage发送一个包含用户name与email的 Webhook 请求该示例的语义是用户改了邮箱后向 Slack 发送消息service: my-service stage: ${env:PRISMA_STAGE} secret: ${env:PRISMA_SECRET} cluster: ${env:PRISMA_CLUSTER} datamodel: database/datamodel.graphql subscriptions: userChangedEmail: webhook: url: http://example.org/sendSlackMessage headers: Content-Type: application/json Authorization: Bearer cha2eiheiphesash3shoofo7eceexaequeebuyaequ1reishiujuu6weisao7ohc query: | subscription { user(where: { mutation_in: [UPDATED] }) { node { name email } } }配置项说明对照上面的示例与源码模型各配置项的作用如下配置层级配置项说明subscriptions.name订阅函数名如userChangedEmail对应源码中ServerSideSubscriptionFunction.name用于在日志与投递链路中标识该函数Webhook 中的functionName字段。name.webhook.urlWebhook 目标地址数据变更匹配时Prisma 将向该 URL 发送POST请求对应WebhookDelivery.url最终出现在Webhook.url字段。name.webhook.headers自定义请求头键值对形式的 HTTP 头例如Content-Type: application/json、Authorization: Bearer token对应WebhookDelivery.headers向量化的键值对投递时原样附加到请求上。生产环境建议用环境变量注入敏感令牌而不是硬编码在配置文件中。name.query订阅查询一段 GraphQLsubscription查询决定监听哪类变更、过滤哪些节点、返回哪些字段。对应ServerSideSubscriptionFunction.query由SubscriptionExecutor.execute在每次变更时执行。prisma.yml 的全局结构与env:变量引用等细节可参考 服务配置参考 目录下的文档。订阅查询语法要点订阅查询使用标准 GraphQLsubscription语法其过滤能力与普通 GraphQL 订阅一致重点包括mutation_in指定要监听哪类变更可选值为CREATED、UPDATED、DELETED。示例中mutation_in: [UPDATED]表示只对更新事件感兴趣如需监听多种类型可写成mutation_in: [CREATED, UPDATED, DELETED]。node对变更节点自身的字段做过滤仅当节点满足条件时才触发投递。测试代码中出现了node: { status: ACTIVE }、node: { text: test }之类的用法见 EmbeddedServerSideSubscriptionSpec.scala。previousValues在node之外还可以请求变更前的字段值例如previousValues { title }便于你的回调逻辑做前后对比如检测邮箱是否真的变了。node与previousValues字段选择器在node中列出你希望随 Webhook 回调携带的字段例如name、email以及关联嵌套字段。这些过滤与字段选择能力在订阅解析器 server/servers/subscriptions/src/main/scala/com/prisma/subscriptions/resolving/SubscriptionResolver.scala 及其配套的SubscriptionsManager、DatabaseEvents等组件中实现与普通 GraphQL 订阅共用同一套解析与过滤管线因此文档中的等价于普通 GraphQL 订阅在实现层面也是成立的。触发示例一次 updateUser Mutation配置好userChangedEmail之后只要客户端执行下面这样的 mutation把某个用户的email改为新地址服务端订阅就会被触发Prisma 会执行配置中的订阅查询并把匹配结果通过 Webhook 发送到http://example.org/sendSlackMessagemutation { updateUser( data: { email: newemail.com }, where: { id: cjcgo976g5twb018740bzyy4q } ) { id } }因为订阅查询中的mutation_in: [UPDATED]只关心更新事件且该 mutation 恰好是UPDATED类型并匹配user模型所以事件会被投递若执行的是创建或删除该用户的 mutation则不会触发该订阅。测试与验证仓库中为该机制提供了完整的集成测试可作为你理解行为与自行验证的参照EmbeddedServerSideSubscriptionSpec.scala针对嵌入式类型embedded的端到端测试覆盖了mutation_in、node过滤、previousValues、嵌套字段选择以及 Webhook 发布等场景。NonEmbeddedServerSideSubscriptionSpec.scala非嵌入式模型下的对应测试。WebhookDelivererWorkerSpec.scala验证 Worker 对 Webhook 的实际 HTTP 投递行为含失败日志格式。测试通过注入的webhookPublisher见webhookTestKit testDependencies.webhookPublisher断言 Webhook 是否被正确发布这与上文投递链路中apiDependencies.webhookPublisher.publish(webhook)的实现一一对应是验证配置 → 变更 → Webhook闭环最直接的证据。适用前提与限制基于当前仓库对应 Prisma 1.x 文档体系的代码实现使用服务端订阅时有几点需要明确投递方式目前仅支持 WebhookAWS Lambda 直连与队列投递是规划中的能力见 01-Overview.md 原文当前版本请以 Webhook 为准。投递不自动重试从 WebhookDelivererWorker.scala 的注释与实现看失败投递不会重试且所有返回码都会被确认请在你的回调端点做好幂等与日志记录。订阅查询的过滤能力与普通 GraphQL 订阅一致mutation_in、node、previousValues等语法均可直接使用配置时不要忘记在query中用|块语法书写多行查询字符串。本文涉及的prisma.yml、datamodel 等概念可参见 服务配置参考 与 Prisma API 参考。至此你已经掌握了 Prisma 服务端订阅的完整图景从 prisma.yml 中的一段配置到 mutation 触发的过滤查询再到 Webhook 投递的源码链路足以独立构建数据变更驱动外部系统的集成方案。赞分享后端数据库GraphQL【免费下载链接】prisma1 Database Tools incl. ORM, Migrations and Admin UI (Postgres, MySQL MongoDB) [deprecated]项目地址https://gitcode.com/gh_mirrors/pr/prisma1点击查看免费下载相关推荐Prisma 服务端订阅Server-side Subscriptions指南基于 Webhook 的事件投递机制与 prisma.yml 配置实战Prisma 服务端订阅Server side Subscriptions指南基于 Webhook 的事件投递机制与 prisma.yml 配置实战 Pr后端数据库GraphQLPrisma 服务端订阅Server-side Subscriptions实战指南在 prisma.yml 中配置 Webhook 事件订阅Prisma 服务端订阅Server side Subscriptions实战指南在 prisma.yml 中配置 Webhook 事件订阅 Prisma后端数据库GraphQLdarktable 入门7 步走完一张 RAW 的免费处理全流程darktable 入门7 步走完一张 RAW 的免费处理全流程 darktable 是一款开源的摄影工作流应用与 RAW 开发者它负责从文件管理、RAW后端数据库GraphQL上一篇构建专业级气象数据服务Open-Meteo开源平台核心技术解析与实战部署下一篇Node.js 23.3.0 (Current) 发布说明精读特性变更、完整提交与 nodejs.org 仓库如何自动生成和渲染该发布文章创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
后端数据库GraphQL【免费下载链接】prisma1 Database Tools incl. ORM, Migrations and Admin UI (Postgres, MySQL MongoDB) [deprecated]项目地址https://gitcode.com/gh_mirrors/pr/prisma1点击查看免费下载导读服务端订阅Server-side Subscriptions是 Prisma 在 GraphQL 订阅能力之外提供的事件通知机制它复用 GraphQL 订阅的查询语法与过滤能力但通过Webhook将数据变更事件投递给外部业务系统天然适配现代 Serverless 基础设施。本文以 docs/1.3/04-Reference/04-Server_side-Subscriptions/01-Overview.md 为核心骨架结合仓库内 API 服务器、Worker 服务器与共享模型的源码实现系统讲解服务端订阅的配置方法、事件投递链路与订阅查询语法读完即可在自己的 Prisma 服务中落地数据变更 → HTTP 回调的完整方案。服务端订阅是什么服务端订阅与普通的 GraphQL 订阅见 GraphQL API 参考在能力上是等价的它们共享同一套 API例如同样支持在where中提供过滤条件从而只接收你感兴趣的事件。两者的核心差异在于投递机制delivery mechanism普通 GraphQL 订阅客户端建立持久连接WebSocketPrisma 在数据变更发生时把事件实时推送到客户端。服务端订阅当服务端订阅被配置好后Prisma 会持续监控数据变更并在匹配时执行与之关联的查询——这一点与普通 GraphQL 订阅一致——但事件的消费方不再是连接的客户端而是你配置的外部端点。从源码看服务端订阅被建模为一等公民的函数类型。在 server/shared-models/src/main/scala/com/prisma/shared/models/Functions.scala 中FunctionType枚举定义了ServerSideSubscription值对应的ServerSideSubscriptionFunction同时持有name、isActive、delivery和query四个字段其中delivery当前只有一种实现——WebhookDelivery包含url与headerscase class ServerSideSubscriptionFunction( name: String, isActive: Boolean, delivery: FunctionDelivery, query: String ) extends Function sealed trait FunctionDelivery { def typeCode: FunctionDeliveryType.Value } object FunctionDeliveryType extends Enumeration { val WebhookDelivery Value(webhook-delivery) } case class WebhookDelivery( url: String, headers: Vector[(String, String)] ) extends FunctionDelivery这印证了文档中的描述当前 Prisma 通过 Webhook 投递服务端订阅事件同时按照 01-Overview.md 的说明未来计划补充直接调用 AWS Lambda 以及不同的队列queue实现。服务端订阅正是为与现代 Serverless 基础设施协同工作而设计的你无需维护常驻的订阅连接只需暴露一个 HTTP 端点接收回调。事件投递链路从 Mutation 到 Webhook理解服务端订阅最好的方式是追踪一次数据变更如何最终变成一次 HTTP 请求。结合仓库源码完整链路如下变更进入 API 服务器客户端执行一次 GraphQL mutation例如updateUser。生成副作用动作API 服务器将 mutation 解析为内部的动作序列其中与服务端订阅相关的动作是ExecuteServerSideSubscription。在 server/servers/api/src/main/scala/com/prisma/api/mutactions/SideEffectMutactionExecutor.scala 中SideEffectMutactionExecutorImpl.execute按类型分发def execute(mutaction: SideEffectMutaction): Future[Unit] mutaction match { case mutaction: PublishSubscriptionEvent PublishSubscriptionEventExecutor.execute(mutaction, apiDependencies.sssEventsPubSub) case mutaction: ExecuteServerSideSubscription ServerSideSubscriptionExecutor.execute(mutaction) }执行订阅查询并构造 WebhookServerSideSubscriptionExecutor.deliverWebhook调用SubscriptionExecutor.execute以skipPermissionCheck true、alwaysQueryMasterDatabase true的方式执行订阅函数中配置的查询只有当返回结果包含data键即事件确实匹配了过滤条件时才构造一个Webhook并发布到webhookPublishersubscriptionResult.map { case Some(json) if json.as[JsObject].keys.contains(data) val webhook Webhook( projectId project.id, functionName function.name, requestId requestId, url webhookDelivery.url, payload json.toString, id requestId, headers webhookDelivery.headers.toMap ) apiDependencies.webhookPublisher.publish(webhook) case _ () }Worker 服务器投递投递动作最终落到 server/servers/workers/src/main/scala/com/prisma/workers/WebhookDelivererWorker.scala。该 Worker 从消息总线队列消费Webhook使用SimpleHttpClient.post以Content-Type: application/json向配置的url发送POST请求并把配置的 headers 一并带上httpClient .post(wh.url, wh.payload, ContentTypes.application/json, wh.headers.toList) .recover { ... }注意其中的注释// Current decision: Do not retry delivery, treat all return codes as work item success ( ack).——从源码看当前实现不对投递失败进行重试所有返回码都被视为工作项成功即确认消费失败仅在日志中输出。如果你在真实环境使用该版本的服务端订阅应基于这个前提设计你自己的重试与告警策略。Webhook数据结构定义在 server/servers/api/src/main/scala/com/prisma/subscriptions/Webhook.scala包含projectId、functionName、requestId、url、payload、id、headers等字段方便在消息总线中流转与追踪。在 prisma.yml 中配置服务端订阅服务端订阅通过在服务配置文件prisma.yml中添加subscriptions属性来完成配置。subscriptions是一个映射map每个键对应一个订阅函数的名称其值描述该订阅的投递方式当前为webhook与订阅查询query。完整配置示例下面是 01-Overview.md 中给出的完整示例它定义了一个名为userChangedEmail的服务端订阅当任意user节点被更新时向http://example.org/sendSlackMessage发送一个包含用户name与email的 Webhook 请求该示例的语义是用户改了邮箱后向 Slack 发送消息service: my-service stage: ${env:PRISMA_STAGE} secret: ${env:PRISMA_SECRET} cluster: ${env:PRISMA_CLUSTER} datamodel: database/datamodel.graphql subscriptions: userChangedEmail: webhook: url: http://example.org/sendSlackMessage headers: Content-Type: application/json Authorization: Bearer cha2eiheiphesash3shoofo7eceexaequeebuyaequ1reishiujuu6weisao7ohc query: | subscription { user(where: { mutation_in: [UPDATED] }) { node { name email } } }配置项说明对照上面的示例与源码模型各配置项的作用如下配置层级配置项说明subscriptions.name订阅函数名如userChangedEmail对应源码中ServerSideSubscriptionFunction.name用于在日志与投递链路中标识该函数Webhook 中的functionName字段。name.webhook.urlWebhook 目标地址数据变更匹配时Prisma 将向该 URL 发送POST请求对应WebhookDelivery.url最终出现在Webhook.url字段。name.webhook.headers自定义请求头键值对形式的 HTTP 头例如Content-Type: application/json、Authorization: Bearer token对应WebhookDelivery.headers向量化的键值对投递时原样附加到请求上。生产环境建议用环境变量注入敏感令牌而不是硬编码在配置文件中。name.query订阅查询一段 GraphQLsubscription查询决定监听哪类变更、过滤哪些节点、返回哪些字段。对应ServerSideSubscriptionFunction.query由SubscriptionExecutor.execute在每次变更时执行。prisma.yml 的全局结构与env:变量引用等细节可参考 服务配置参考 目录下的文档。订阅查询语法要点订阅查询使用标准 GraphQLsubscription语法其过滤能力与普通 GraphQL 订阅一致重点包括mutation_in指定要监听哪类变更可选值为CREATED、UPDATED、DELETED。示例中mutation_in: [UPDATED]表示只对更新事件感兴趣如需监听多种类型可写成mutation_in: [CREATED, UPDATED, DELETED]。node对变更节点自身的字段做过滤仅当节点满足条件时才触发投递。测试代码中出现了node: { status: ACTIVE }、node: { text: test }之类的用法见 EmbeddedServerSideSubscriptionSpec.scala。previousValues在node之外还可以请求变更前的字段值例如previousValues { title }便于你的回调逻辑做前后对比如检测邮箱是否真的变了。node与previousValues字段选择器在node中列出你希望随 Webhook 回调携带的字段例如name、email以及关联嵌套字段。这些过滤与字段选择能力在订阅解析器 server/servers/subscriptions/src/main/scala/com/prisma/subscriptions/resolving/SubscriptionResolver.scala 及其配套的SubscriptionsManager、DatabaseEvents等组件中实现与普通 GraphQL 订阅共用同一套解析与过滤管线因此文档中的等价于普通 GraphQL 订阅在实现层面也是成立的。触发示例一次 updateUser Mutation配置好userChangedEmail之后只要客户端执行下面这样的 mutation把某个用户的email改为新地址服务端订阅就会被触发Prisma 会执行配置中的订阅查询并把匹配结果通过 Webhook 发送到http://example.org/sendSlackMessagemutation { updateUser( data: { email: newemail.com }, where: { id: cjcgo976g5twb018740bzyy4q } ) { id } }因为订阅查询中的mutation_in: [UPDATED]只关心更新事件且该 mutation 恰好是UPDATED类型并匹配user模型所以事件会被投递若执行的是创建或删除该用户的 mutation则不会触发该订阅。测试与验证仓库中为该机制提供了完整的集成测试可作为你理解行为与自行验证的参照EmbeddedServerSideSubscriptionSpec.scala针对嵌入式类型embedded的端到端测试覆盖了mutation_in、node过滤、previousValues、嵌套字段选择以及 Webhook 发布等场景。NonEmbeddedServerSideSubscriptionSpec.scala非嵌入式模型下的对应测试。WebhookDelivererWorkerSpec.scala验证 Worker 对 Webhook 的实际 HTTP 投递行为含失败日志格式。测试通过注入的webhookPublisher见webhookTestKit testDependencies.webhookPublisher断言 Webhook 是否被正确发布这与上文投递链路中apiDependencies.webhookPublisher.publish(webhook)的实现一一对应是验证配置 → 变更 → Webhook闭环最直接的证据。适用前提与限制基于当前仓库对应 Prisma 1.x 文档体系的代码实现使用服务端订阅时有几点需要明确投递方式目前仅支持 WebhookAWS Lambda 直连与队列投递是规划中的能力见 01-Overview.md 原文当前版本请以 Webhook 为准。投递不自动重试从 WebhookDelivererWorker.scala 的注释与实现看失败投递不会重试且所有返回码都会被确认请在你的回调端点做好幂等与日志记录。订阅查询的过滤能力与普通 GraphQL 订阅一致mutation_in、node、previousValues等语法均可直接使用配置时不要忘记在query中用|块语法书写多行查询字符串。本文涉及的prisma.yml、datamodel 等概念可参见 服务配置参考 与 Prisma API 参考。至此你已经掌握了 Prisma 服务端订阅的完整图景从 prisma.yml 中的一段配置到 mutation 触发的过滤查询再到 Webhook 投递的源码链路足以独立构建数据变更驱动外部系统的集成方案。赞分享后端数据库GraphQL【免费下载链接】prisma1 Database Tools incl. ORM, Migrations and Admin UI (Postgres, MySQL MongoDB) [deprecated]项目地址https://gitcode.com/gh_mirrors/pr/prisma1点击查看免费下载相关推荐Prisma 服务端订阅Server-side Subscriptions指南基于 Webhook 的事件投递机制与 prisma.yml 配置实战Prisma 服务端订阅Server side Subscriptions指南基于 Webhook 的事件投递机制与 prisma.yml 配置实战 Pr后端数据库GraphQLPrisma 服务端订阅Server-side Subscriptions实战指南在 prisma.yml 中配置 Webhook 事件订阅Prisma 服务端订阅Server side Subscriptions实战指南在 prisma.yml 中配置 Webhook 事件订阅 Prisma后端数据库GraphQLdarktable 入门7 步走完一张 RAW 的免费处理全流程darktable 入门7 步走完一张 RAW 的免费处理全流程 darktable 是一款开源的摄影工作流应用与 RAW 开发者它负责从文件管理、RAW后端数据库GraphQL上一篇构建专业级气象数据服务Open-Meteo开源平台核心技术解析与实战部署下一篇Node.js 23.3.0 (Current) 发布说明精读特性变更、完整提交与 nodejs.org 仓库如何自动生成和渲染该发布文章创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
)
