LiveView + channels + subscriptions between apps in umbrella

Phoenix Forum Questions / Help
, ,
1

Hi everybody

I have a general question about live view and sockets.

We have umbrella porject with several apps in it,: core/backoffice/client/superadmin etc
In the client’s app we have an active event page where users can communicate. It’s quite similar to chat or webinar. There is couple of live-components: user’s list, shared canvas, chat, shared documents etc.
On the backend there is a live console where admin can manage this process: he can see active users, attach documents and send some system notifications to the shared rooms.

Right now there is EventChannel to handle when user’s connect to room via sockets.
So, in app.js we have connection to LiveSocket to handle phoenix live view events and there is connection to custom event’s channel (via phx-hooks)
Live view and specific channel are 2 different processes and they can’t communicate with each other like live-components inside of one live view. For that purpose we need to use PubSub. right?

Live Console at backoffice subscribes to the event’s topic, let’s say: “event:#{id}”, on BackOffice.PubSub
Client’s Live View subscribes to the same topic as well, but on ClientApp.PubSub
Client’s channel uses ClientApp.PubSub as well, so it automatically subscribe to the same topic if it’s configured in user’s socket.
channel “event:*”, ClientApp.EventChannel

In channel implemented tracking of presence, sending events :user_joined/:user_left to both pub-subs, so backoffice and client’s live view can update who is online.
When I want to send an update from backoffice to client only to live view, I make a call to helper function

app_broadcast(socket, ClientApp.PubSub, source, event, payload)

def app_broadcast(socket, to, source, event, payload) do
if !is_nil(Process.whereis(to)) do
PubSub.broadcast to, topic(source), {event, payload}
end
socket
end

From channel, when I want to send event to both, I just make a call

socket
|> app_broadcast(ClientApp.PubSub, source, event, payload)
|> app_broadcast(BackOffice.PubSub, source, event, payload)

But channel receive a message as well and I don’t need to listen to all events in channel and live view at same time.

My question is more about organisation :

  • subscribe in ClientApp to another topic to communicate with BackOffice, and communicate between EventChannel and ClientApp on another one (there is only presence for now and may be that’s all we need)
  • communicate with a clients only through EventChannel: BackOffice ↔ EventChannel, and there is decision on EventChannel what to send to ClientApp ↔ ClientApp if need.

In future another app will need some communication features as well.
what makes more sense in your opinion? Are there any mistakes in my thought and is there any other options?

2

Did You consider Event Sourcing?

I did some experiment with umbrella, ES and CQRS… and had some good result with it. More or less, You focus on events.

Each apps have dependencies to the EventStore, and can publish and subscribe. The store is responsible for dispatching to multiple listeners.

I have apps, liveview and channel listeners. So whatever happens, I can dispatch to the different subscribers.

Not to mention all benefits You get from having an event log.

1 Like
3

No, I didn’t. It looks like one more option. I didn’t mention in my first post, apps are running in cluster of erlang nodes (libcluster used), that’s why I looked for something simple over pubsub.

What library did you use?
I found list of libraries GitHub - slashdotdash/awesome-elixir-cqrs: A curated list of awesome Elixir and Command Query Responsibility Segregation (CQRS) resources.
Most of them are not in development, but some are good:
commanded looks promising, not sure I need all of that functionality.

I am afraid complexity we need to add to the app to solve this problem using ES and CQRS (it wasn’t designed to use it)

Thank you

4

None, I built mine.

5

how did you implement event source?

6

I translated this book from NodeJS to Elixir.

Not all the code is available, but the event store is…

7

understood. probably I will stay with couple of help functions and different topics

8

in the end I’ve just created help module that makes simple event bus in app.
%EventBus{topic: “unique-topic”, pubsub: CoreApp.PubSub, subscribed: true/false}

and help method that creates event bus and subscribe to topic (optionally, in channel I don’t subscribe to topic, but do that at backoffice/client apps and track presence diffs), broadcast info and work with presence.

bus(app1, app2, subject, opts \\ [])
broadcast(%EventBus{} = bus, event, payload)
# a wrapper to bus, where app1 is hardcoded "presence"
presence_bus(channel_name, subject)

Presence helpers to track users:

presence_track(process, user, %EventBus{} = bus)
presence_untrack(process, user, %EventBus{} = bus)

And read presence + merge

get_presence_users(%EventBus{} = bus, opts \\ [])
presence_parse(presence, opts \\ [])
presence_merge_diff(presence, %{joins: joins, leaves: leaves}, opts \\ [])

Presence info for each user I convert to another structure:

defmodule CoreApp.PubSubUser do
  defstruct [id: nil, name: nil, count_processes: nil, user: nil, phx_refs: [] ]
end

In live view from handle_params I just make simple call:

bus = PubSubUtils.presence_bus(EventChannel, event, subscribe: true, prefix: "event")
# read current presence: Presence.list() used
presences = PubSubUtils.get_presence_users(bus, preload: true)
#.....
#At presence_diff handler merge payload and update presence in socket
presences = Lms.Utils.PubSub.presence_merge_diff(presences, payload)

In example above presences is a list of CoreApp.PubSubUser structs. These structs are quite useful as contains some aggregated info from metas (such as number of processes per user etc), I don’t care in views about internal structure of presence’s diffs. Any new live view where I need to track presences and broadcast events to custom rooms needs very small number of code.

Presence module implements fetch(…) to optimize reading data from DB before sending diff to client.
It works quite well