amjr
Hi,
I’m currently diving into world of websockets via Phoenix channels. Absolutely awesome stuff.
The thing I’m wondering is Phoenix presence. Almost all of the examples are chat-examples however my use-case is not a chat but rather a game.
Usually everybody handles the presence state diff-messages in Javascript. For example:
room.on("presence_diff", diff => {
presences = Presence.syncDiff(presences, diff)
render(presences)
})
given this channel implementation:
defmodule PhoenixChat.RoomChannel do
use PhoenixChat.Web, :channel
alias PhoenixChat.Presence
def join("room:lobby", _, socket) do
send self(), :after_join
{:ok, socket}
end
def handle_info(:after_join, socket) do
Presence.track(socket, socket.assigns.user, %{
online_at: :os.system_time(:milli_seconds)
})
push socket, "presence_state", Presence.list(socket)
{:noreply, socket}
end
end
How can I suppress the sending of presence_diffs to clients? As I don’t want to expose the presence information to connected clients but keep it only on the server side.
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
We build reliable cloud platforms for business-critical systems.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #ai
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 5 to 1- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
chrismccord
intercepting is the way to go to easily filter out the
presence_diffeventsamjr
Great. This helps me forward. Thanks!
By the way. Gotta love the Elixir/Phoenix community. You guys rock!
OvermindDL1
That is precisely it.
Personally I would have a few processing processes that handle the messages of what is happening, and ‘they’ would then send messages to topics to send updates to clients, and the clients would connect to as many topics as they need for the data they want to receive.
amjr
Intercepting would be something like this?
The target is to use the channel for sending in-game data and event to clients and utilize the presence internally on the server-side. Client side would only connect the websocket (swift / iOS, Android) and get updates on the game events.
Clients wouldn’t get updates on who is online and who is not (prevent players for example attacking players who go offline in the hopes of catching them off-guard)
OvermindDL1
Two ways, you can also PubSub subscribe to a new process that does all the actual processing with the messages then posts to the client as needed, this would also let clients share a ‘processing’ actor. Or you can hook the ‘outgoing’ messages in Phoenix Channels (detailed in the docs) for the outgoing message of “presence_diff” then do what you wish, such as pushing it out or canceling it or whatever.
For note, if the client should get the pubsub messages then they should get them all or will desync.
If the client should get none then it should be handled by another process.
The client should never just get ‘some’, what you probably want here is an intermediary process as well to coalesce the updates.