LiveView, ecto, postgres architecture advice for a chat-ish app

Hi Friends - I’d appreciate your advice. We’re building an app for university classes that is roughly a real-time Q&A board akin to the erstwhile Google Moderator. Teachers create topics, within a topic students ask questions, they can vote and comment on others’ questions.

The main view is a real-time list view of questions sorted by votes: those with the most bubble to the top. We have a “regular” version of this app written in Phoenix and are now moving to LiveView in order to make it real-time. We’d appreciate your critique of the following architecture for propagating database changes in real-time changes to the attached clients.

  • PostgreSQL tables have trigger that call pg_notify
  • A GenServer catches those using Postgrex.Notifications
  • The GenServer sends notifications to LiveComponent processes that are subscribed to topics like “questions:384”, where “384” is the primary key of a particular question.
  • In the view, each question shown is a LiveComponent.

Is that a good way to approach the problem?

I am worried about the memory requirements so I intend to use temporary_assigns in the livecomponents. I should mention, I’m a phoenix noob but experienced full stack dev.

Thanks! Kyle

1 Like

I heard people say on this forum (@benwilson512 I think) that pg_notify scales very poorly and you should stay away from it, by the way.

2 Likes

Yeah pg_notify has its uses but I’m not entirely sure that it’s the right thing to do here. If possible it’d be preferable to do a Phoenix pubsub publication from your context functions, and have your live view modules subscribe to those.

3 Likes

Thanks @benwilson512, @dimitarvp - I’m grateful. I’ll likely abuse your kindness and wisdom again shortly with a follow-up question.