Registering a RabbitMQ consumer within a LiveView Process


I am new to the Elixir ecosystem. We are building system composed of the following layers:

  • A database layer,
  • A middleware layer containing our business logic and being written in a statically typed OOP language for a variety or reasons. This middleware exposes an internal HTTP API that can only be consumed by the web layer.
  • A web layer that we are strongly weighting writing in Phoenix and LiveView. The web layer can be accessed by external consumers

Since Phoenix would not have direct access to the database, I am wondering how we could leverage the real-time update capabilities of LiveView to do things such as notifying individual users when they receive a new message, or when a new article has been added to a feed to which they are subscribed.

Since my understanding is that there is dedicated a LiveView process per user, I am wondering if it would be sound create one RabbitMQ queue per user. Then after a user has logged in, a queue consumer would be registered in the LiveView process of each individual user. The consumer would then be discarded when the user leaves the website.

RabbitMQ makes it easy to have messages discarded if no one is listening to a queue, so i’m thinking this could be a great fit for LiveView. Could you please tell me if you think this approach fits the intended use of Phoenix/LiveView, and if so could you please provide me some pointers on how I’d go about implementing it in Phoenix (namely, what would be the best RabbitMQ client library to use, and where would I need to hook in LiveView).


Phoenix channels (the piece powering real time capabilities, including LV) don’t really care where messages send through them originate. Given you’re working with a beam and non-beam system some external messaging system like rabbitmq sounds reasonable.

1 Like

Thanks! My concern is: from a lifecycle and threading model perspective, is it fine to attach a RabbitMQ “worker” to every LiveView socket? Both with regards to best practices and scalability.

I don’t know enough about rabbitmq to be able to judge that. There’s likely tradeoffs around number of topics vs number of consumers, …

To clarify: my questions are about the Elixir/Phoenix side of things, not about how to use RabbitMQ or how to fit it into an architecture generally speaking. I am not familiar with the Elixir environment and Phoenix, so my question is more about the lifecycle of the objects Phoenix/LiveView framework.

PubSub or more generally messaging within the beam shouldn’t be a problem. Processes and messages are a much more explicit means of modeling something like pubsub, than objects, even though they can seem very alike. Efficiency will likely revolve more around minimizing inter-system communication.

1 Like