PubSub instead of polling in liveview?

Hi,

Sorry, I did not look at the LiveView tutorial.
I have worked with polling model for music player a couple of years ago: local_assistant/lib/local_assistant/player/player.ex at f02e6779d011a612a317d41a97aad4c330a7034d · RomanKotov/local_assistant · GitHub

This was a local player. We used it in the office to play tracks.
Pros:

• Easy to implement.
  Cons:
• The player I used to play track (mopidy) could be blocked on long operations. For example, loading very large playlist could crash the whole application. Or the UI was unstable.

I took the issues into account and created another application to play music, and some other stuff (it will be Elixir-based Smart Home). Now it uses PubSub (indirectly) and the other player (mpv).

New examples:

• How I use player state: exshome/lib/exshome_player/live/player.ex at 31ea257f1554eaf0d6b73a0888fb9fb0c864903a · exshome/exshome · GitHub
• Player layout: exshome/lib/exshome_player/live/player.html.heex at 31ea257f1554eaf0d6b73a0888fb9fb0c864903a · exshome/exshome · GitHub
• Place, where I broadcast player events: exshome/lib/exshome_player/services/mpv_socket.ex at 31ea257f1554eaf0d6b73a0888fb9fb0c864903a · exshome/exshome · GitHub
• PubSub itself: exshome/lib/exshome/pub_sub.ex at 31ea257f1554eaf0d6b73a0888fb9fb0c864903a · exshome/exshome · GitHub
• This part allows to make 100% async tests for PubSub: exshome/lib/exshome/pub_sub.ex at 31ea257f1554eaf0d6b73a0888fb9fb0c864903a · exshome/exshome · GitHub

I like how newer approach. It works better

Have streamed the implementation process some time. Here is a thread about the Exshome: Exshome - DIY Elixir Smart Home

Hope this helps

Sorry, have just noticed the context. I thought you were talking about the music player, but it was about ECSx player demo.

I have discussed ECSx topic on Twitter yesterday: https://x.com/kotovr/status/1753315848389865901?s=20

This thread contains ideas of how to use PubSub for ECSx, and it is very closely related to the approach I have described in the previous message with music player.

I have researched ECSx yesterday. Will give my thoughts about version 0.5 (GitHub - ecsx-framework/ECSx at 7520dc6bd4837ad36d60f2d54942e868626fa365 · GitHub) - everything may change in future.

Manager starts :ets tables for each component. It also periodically runs code for each system. So, you have a single process, that runs the logic of your game. If there is an error in one system - it will crash the manager. The more time a system takes to recompute - the lower FPS you will have. I think it is better not to do heavy computations in any system. Possibly you can offload the computations to some task and then send results back via ClientEvents.

Just want to emphasize, that it is better not to overload your systems and keep them as lightweight as possible.

You can broadcast changes directly from your system. But sending messages will also take some time. The sending process needs to copy a message to mailbox of recipient (The BEAM Book: Understanding the Erlang Runtime System). It is OK, if you send only a small number of messages. But since you will have many components, the main loop may only work on broadcasting instead of useful work.

So, I think it is better to start with polling and see how it will work. Each polling process reads directly from :ets table, so it should not be a problem.

If you really want to use PubSub, then I think it will be better not to broadcast everything from the main game loop. You can start own processes, which will poll the required state and then broadcast it to the subscribers. For example, if you have a player (entity), you can launch a process for a player. It will periodically poll player components and then broadcast the data to every subscriber. For example, if your page shows 3 players - you need to subscribe only for them.

Some good insights from @RomanKotov - particularly

Just want to emphasize, that it is better not to overload your systems and keep them as lightweight as possible.

is very important. Remember that reading from ETS (which we use for component storage) is extremely fast and lightweight - so if your goal is to reduce the number of times you are fetching the component data, it might not be a worthwhile goal. Better to save that type of optimization for later if you notice performance becoming a problem (and even then, it’s likely there are other things you could optimize that would make a greater impact)

I have prepared some examples of how it is possible to use PubSub. I have just created a simple .exs file (for example pub_sub.exs) and then ran it as iex pub_sub.exs.
It does not use real LiveView, or ECSx, but shows some concepts:

Mix.install([:phoenix_pubsub])

defmodule HPComponent do
  def get(_id), do: Enum.random(1..100)
end

defmodule ManaComponent do
  def get(_id), do: Enum.random(1..100)
end

defmodule Entity do
  @callback get_value(id :: String.t()) :: map()

  def get_value(entity, id), do: entity.get_value(id)
  
  def subscribe(entity, id) do
    pub_sub_key = generate_pub_sub_key(entity, id)
    :ok = Phoenix.PubSub.subscribe(MyApp.PubSub, pub_sub_key)
    get_value(entity, id)
  end

  def broadcast_value(entity, id, value) do
    pub_sub_key = generate_pub_sub_key(entity, id)
    Phoenix.PubSub.broadcast!(MyApp.PubSub, pub_sub_key, {__MODULE__, entity, id, value})
  end

  defp generate_pub_sub_key(entity, id), do: inspect({__MODULE__, entity, id})
end

defmodule PlayerEntity do
  @behaviour Entity

  @impl Entity
  def get_value(player_id) do
    %{
      hp: HPComponent.get(player_id),
      mana: ManaComponent.get(player_id)
    }
  end
end

defmodule EntityServer do
  use GenServer

  def start_link(params) do
    GenServer.start_link(__MODULE__, params)
  end
  
  @impl GenServer
  def init(params) do
    id = Keyword.fetch!(params, :id)
    entity = Keyword.fetch!(params, :entity)
    refresh_interval = Keyword.get(params, :refresh_interval, 10)
    
    current_value = Entity.get_value(entity, id)
    
    state = %{
      id: id,
      entity: entity,
      value: current_value,
      refresh_interval: refresh_interval
    }
    schedule_refresh(state)
    
    {:ok, state}
  end

  @impl GenServer
  def handle_info(:refresh, state) do
    new_value = Entity.get_value(state.entity, state.id)

    if new_value != state.value do
      Entity.broadcast_value(state.entity, state.id, new_value)
    end

    schedule_refresh(state)
    
    {:noreply, Map.put(state, :value, new_value)}
  end
  
  defp schedule_refresh(%{refresh_interval: interval}) do
    Process.send_after(self(), :refresh, interval)
  end
end

defmodule LiveViewPlayersView do
  use GenServer

  def start_link(params), do: GenServer.start_link(__MODULE__, params)
  
  @impl GenServer
  def init(_) do
    state = [1, 2]
    |> Enum.map(fn id -> {id, Entity.subscribe(PlayerEntity, id)} end)
    |> Enum.into(%{})

    IO.inspect("Players on start: #{inspect(state)}")
    
    {:ok, state}
  end

  @impl GenServer
  def handle_info({Entity, PlayerEntity, id, value}, state) do
    state = Map.put(state, id, value)
    IO.inspect("At least one player changed: #{inspect(state)}")
    {:noreply, state}
  end
end

children = [
  {Phoenix.PubSub, name: MyApp.PubSub},
  Supervisor.child_spec({EntityServer, entity: PlayerEntity, id: 1}, id: :player_1),
  Supervisor.child_spec({EntityServer, entity: PlayerEntity, id: 2}, id: :player_2),
  LiveViewPlayersView,
]
opts = [strategy: :one_for_one, name: MyApp.Supervisor]
{:ok, _pid} = Supervisor.start_link(children, opts)

Process.sleep(:infinity)

Let’s break it down:

• Mix.install(...) part installs all necessary dependencies.
• Modules HPComponent and ManaComponent emulate components from ECS.
• Entity module creates a behaviour for entities. As of 0.5.1 - there is no thing in ECSx related to the entities. Entity is only represented as id. So just thought it can be fine to gather every part related to this id from relevant components here. Behaviour needs get_value/1 function. You can extract behaviour itself to other module, so it will not influence the compilation graph. I could add some __using__ macros, but thought behaviour is enough here.
• Entity module also supports extra functions. get_value/2 returns the current value for the entity. It is up to you whether to keep it. subscribe/2 subscribes to the changes in Entity and returns its current value. broadcast_value/3 incapsulates PubSub details. I find this approach useful in tests - you don’t need to start the whole system, you can just broadcast relevant data.
• PlayerEntity - implements Entity behaviour. Example of the entity. It takes the data directly from components (ETS in case of ECSx) and has no internal state. If you need multiple parts of player data in one place, possibly it is fine to call get_value from such entity. If you need only a couple of components - it is better to call them directly. You may also want to use structs instead of map here.
• EntityServer module is a simple GenServer, that periodically polls the state of the entity and broadcasts changes (if there were any).
• LiveViewPlayersView module is also GenServer that emulates subscription to the Entity changes. IO.inspect/1 parts from it may be replaced with assign/2 or assign/3 in case of single objects. It also can be replaced with stream/4 and related API (if you want to render lists of items). There are some other techniques, but they are LiveView-specific.
• List children starts all necessary dependencies for this demo to work. They are PubSub itself (with all necessary Registries), a couple of Player entities (needed to use this syntax to launch multiple instances) and LiveView emulation process. Starting EntityServer instances may be delegated to own supervisor instead.
• Then I start all necessary dependencies for the demo.
• Process.sleep(:infinity) line just for demo purposes here. It allows script to keep working (and printing changes in player state).

I have also thought about the architecture of manager. Since all logic runs in one process, you may want to give higher priority for this process too (so less relevant ones will not interfere with critical computations). You can do this by updating priority in startup/0 function in your manager, like Process.flag(:priority, :high). Possibly there some other options to do this.

Be extremely careful with this. High priority processes that are also very busy can starve out other important functions like IO.

Thanks for the tip. Yes, you are right - overusing this feature may lead to unexpected results, so it is better to use it with caution.

Right now ECSx (as of 0.5.1) uses only one global process (Manager) that manages all game logic. It periodically runs all mutations (Systems) and updates values in ETS tables for all related Components. The slower it recomputes all those values, the lower will be FPS and overall responsiveness of the game.

I considered raising the priority of the manager, because it is only a single process and it may be critical to the whole application. I would not recommend to update the priority, if system had more than one manager, or VM will have only one CPU (or scheduler).