In their Phoenix LiveView course (which is excellent!), the Pragmatic Studio guys define a function in a Phoenix context, LiveViewStudio.Volunteers.broadcast/2, like this:
def broadcast({:ok, volunteer}, event) do
Phoenix.PubSub.broadcast(
LiveViewStudio.PubSub,
"volunteers",
{event, volunteer}
)
{:ok, volunteer}
end
… which they then append to the write functions for that Phoenix context, as with LiveViewStudio.Volunteers.update_volunteer/2:
def update_volunteer(%Volunteer{} = volunteer, attrs) do
volunteer
|> Volunteer.changeset(attrs)
|> Repo.update()
|> broadcast(:volunteer_updated)
end
… which they use to implement real-time updates in a LiveView; and this general pattern strikes me as preferable to the absinthe way of doing things, which is to use a Absinthe.Schema.Notation.trigger/2 macro, because the message is sent every time the context function is invoked, rather than ‘just’ when a GraphQL mutation is run.
I would like to continue giving PubSub messages to both the GraphQL subscription and to the LiveView, and I would also like for each to catch events given to the other; I think that I can add an additional call to Absinthe.Subscription.publish/3 to the aforementioned LiveViewStudio.Volunteers.broadcast/2 function, like this:
def broadcast({:ok, volunteer}, event) do
Phoenix.PubSub.broadcast(
LiveViewStudio.PubSub,
"volunteers",
{event, volunteer}
)
Absinthe.Subscription.publish(
LiveViewStudioWeb.Endpoint,
volunteer,
change_volunteers: "volunteers"
)
{:ok, volunteer}
end
It seems like absinthe shards the topics you give it (to avoid collision?), but it seems like it would maybe be better if I could just give the ‘naked’ topic to Absinthe.Schema.Notation.config/1, rather than sending out two different messages. Is that possible, or am I ‘stuck’ sending two events?
