How to design chat room architecture using LiveView without Channel?

I’ve come back to this after the weekend. It is still a work in progress, but it seems a simple PubSub process shared between all of the chat LiveView client processes is the correct approach. Once there is a working prototype I’ll create a simple demo.

LLMs have changed my workflow so much, I’ve realized, that basic tasks like RTFM have gathered some dust in my toolbox. There is another thread on LLM performance with Elixir, and in my recent experience (I first learned Elixir before the current AI boom and only recently returned to writing it full time) ChatGPT very confidently will lead you in the wrong direction regarding LiveView. It has struggled immensely with creating simple forms, imports, any sort of knowledge where best practices have changed immensely in the last few years, yet when implementing functions with well-defined inputs and outputs, as is so often the case with Elixir, it’s basically flawless. The experience really highlights how Phoenix is a paradigm shift from the current mode of Python/Ruby/OOP backend and React/Native/reactive frontend: LLMs don’t learn new paradigms well, and by their nature gravitate (literally descending on a gradient) towards the tried-and-true way of doing things. An interesting thought for those most bullish on AI …

This seems to be a great example: GitHub - dwyl/phoenix-liveview-chat-example: 💬 Step-by-step tutorial creates a Chat App using Phoenix LiveView including Presence, Authentication and Style with Tailwind CSS · GitHub

My own solution turned out something like this:

defmodule DemoWeb.ChatLive.Show do
  use DemoWeb, :live_view

  alias Demo.Chats

  @impl true
  def mount(%{"room_number" => room_number}, _session, socket) do
    chat = Chats.get_chat_by_room_number(room_number)
    messages = Chats.list_messages_for_chat(chat.id)

    if connected?(socket) do
      Chats.subscribe(chat.id)
    end

    {:ok,
     socket
     |> assign(:chat, chat)
     |> assign(:form, to_form(Chats.change_message(%Chats.Message{})))
     |> stream(:messages, messages)}
  end

  @impl true
  def handle_event("send", %{"message" => message_params}, socket) do
    user = socket.assigns.current_user
    chat = socket.assigns.chat

    case Chats.create_message(user, chat, message_params) do
      {:ok, message} ->
        {:noreply, assign(socket, :form, to_form(Chats.change_message(%Chats.Message{})))}

      {:error, changeset} ->
        {:noreply, assign(socket, :form, to_form(changeset))}
    end
  end

  @impl true
  def handle_event("validate", %{"message" => message_params}, socket) do
    changeset = Chats.change_message(%Chats.Message{}, message_params)

    {:noreply,
     socket
     |> assign(:form, to_form(changeset))}
  end

  @impl true
  def handle_info({:new_message, message}, socket) do
    {:noreply, stream_insert(socket, :messages, message)}
  end

    @impl true
  def render(assigns) do
    ~H"""
    <div class="flex justify-between">
      <.back navigate={~p"/chats"}>Back to chats</.back>
    </div>

    <ul id="message-list" phx-update="stream">
      <%= for {_id, message} <- @streams.messages do %>
        <li id={"message-#{message.id}"}>
          <strong><%= message.user.name %>:</strong> <%= message.content %>
        </li>
      <% end %>
    </ul>

    <.simple_form
      for={@form}
      id="message-form"
      phx-change="validate"
      phx-submit="send"
    >
      <.input field={@form[:content]} type="text" />
      <:actions>
        <.button phx-disable-with="Sending...">Send</.button>
      </:actions>
    </.simple_form>
    """
  end
end

I used the Phoenix generators to create a user resource in an accounts context, and then a chat and message resource in the chats context. Messages are associated with particular users and chats when they are created in order to display them in the right chat with the right sender. In terms of technical problems I spent a good few hours before realizing excluding phx-update="stream" from the immediate parent of the stream invocation in the template results in undefined behavior. Perhaps a compiler warning would be helpful for new users here.

defmodule Demo.Chats do
  @moduledoc """
  The Chats context for a basic messaging demo.
  """

  import Ecto.Query, warn: false
  alias Demo.Repo
  alias Demo.Chats.{Chat, Message}

  @doc """
  Returns the list of chats.
  """
  def list_chats do
    Repo.all(Chat)
  end

  @doc """
  Gets a chat by its room number.
  """
  def get_chat_by_room_number(room_number) do
    Repo.get_by(Chat, room_number: room_number)
    |> Repo.preload(:messages)
  end

  @doc """
  Returns the list of messages for a specific chat.
  """
  def list_messages_for_chat(chat_id) do
    from(m in Message,
      where: m.chat_id == ^chat_id,
      order_by: [asc: m.inserted_at],
      preload: [:user]
    )
    |> Repo.all()
  end

  @doc """
  Creates a message and broadcasts it to subscribers.
  """
  def create_message(user, chat, attrs) do
    %Message{}
    |> Message.changeset(attrs)
    |> Ecto.Changeset.put_assoc(:user, user)
    |> Ecto.Changeset.put_assoc(:chat, chat)
    |> Repo.insert()
    |> case do
         {:ok, message} ->
           broadcast_message(message)
           {:ok, message}

         {:error, changeset} ->
           {:error, changeset}
       end
  end

  @doc """
  Subscribes to chat messages.
  """
  def subscribe(chat_id) do
    Phoenix.PubSub.subscribe(Demo.PubSub, "chat:#{chat_id}")
  end

  @doc """
  Broadcasts a new message to the chat.
  """
  def broadcast_message(message) do
    Phoenix.PubSub.broadcast(Demo.PubSub, "chat:#{message.chat_id}", {:new_message, message})
  end
end

My major conceptual misunderstanding was the simplicity of info passing in Elixir. My intuition told me it couldn’t really be as simple as 3 lines, and you have a real-time distributed messaging system coordinating between a server and many clients.

# Defined in context module
Phoenix.PubSub.subscribe(Demo.PubSub, "chat:#{chat_id}")
Phoenix.PubSub.broadcast(Demo.PubSub, "chat:#{message.chat_id}", {:new_message, message})
# Defined in LiveView module
def handle_info({:new_message, message}, socket), do: {:noreply, stream_insert(socket, :messages, message)}

Phoenix has left a strong impression on me that it’s about as close as you can get to an ideal API for distributed systems. In the conventional apps I’ve been writing for many years you are ultimately trying to approach this same API in every project, but the differences in state between server and client, and the inevitable side-effect leaking allowed by OOP languages and JavaScript means you slowly diverge from this API until you have a big ball of mud.

The last week has been a learning process but I’m able to add features to my app very quickly now. I can tell this language Elixir is a labor of love, which is why although I had no replies to this thread I wanted to share what I learned with the community.

Also ran into this . Would be great to have a complier error if it sees a @stream in the markup without an accompanying phx-update="stream"