How can I broadcast the result of a mutation with a subscription in Actix?

[Teajey]

My ideas about how this could work are a bit feeble. Perhaps you would put an event iterator stream (?) in the GraphQL context that the mutations push to and the subscription consumes? Or is there an event system in either Juniper or Actix that I should be leveraging? Or is Juniper's support for subscriptions just too nascent to enable something like this yet?

[tyranron]

@Teajey

Or is Juniper's support for subscriptions just too nascent to enable something like this yet?

Yes. It's far beyond Juniper responsibilities.

Or is there an event system in either Juniper or Actix that I should be leveraging?

Juniper definitely doesn't have something like that. While you may try to use Actix channels/actors for that purpose.

Perhaps you would put an event iterator stream (?) in the GraphQL context that the mutations push to and the subscription consumes?

Context is a thing to leave per-request only. You may still wire them via link to something global though.

In our codebases we solve this by having a "reactive state". Either in-memory (futures-signals, for example, or even sled), or in form of a separate standalone database. So, the subscriptions aren't wired to mutations directly. Rather the mutations changes the state the way they need, and subscriptions listen to changes of the state they require.

[Teajey]

Thanks for the info! futures-signals sounds like it might be what I'm after. Are there any codebases on GitHub you know of that use this pattern that you could direct me to, as an exemplar?

[tyranron]

@Teajey yup, see here. I don't contribute and follow that codebase anymore for more than a year now, so some things may be changed. But when I designed it, it was the way I've described above.

[Teajey]

Thank you! I already use Redis in my project and I've just realized that it has a pubsub system built-in, so I'll use that 😁