nathanl
I came across some interactions between Channels and PubSub yesterday which surprised me. This is using phoenix 1.7.1 and phoenix_pubsub 2.1.1.
If I have a Phoenix.Channel on topic "some_topic and a client connected to it:
Phoenix.PubSub.broadcast(MyApp.PubSub, "some_topic", %{some: "message"}will go to that channel process’shandle_info/2even if it did not callPhoenix.PubSub.subscribe/3, and will go N+1 times if it did explicitly subscribe N times.MyApp.Endpoint.broadcast("some_topic", "some_event", %{some: "message"})will go directly to the connected client of the channel without the channel process ever seeing it unless the channel process intercepts it.
Is this how it’s intended to work? My mental model was “only processes which explicitly PubSub.subscribe/3 will get a PubSub event, and it will go to their handle_info/2, where they can do what they will.” I see that handle_out/3 exists for interception, so clearly that’s by design…
I’ve been using Phoenix for years and didn’t realize that the topics were shared between Channels and PubSub. But I may not be the sharpest knife in the drawer. 
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
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.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 4- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
chrismccord
Yes this is working exactly it is supposed to
Channel broadcasts (
broacast(socket, ...)andEndpoint.broadcast)) are “fast-laned” directly to the transport process unless you intercept. This allows us to encode the the message a single time vs N times for every subscriber.Phoenix.PubSub.broadcastis lower level and broadcasts the raw elixir term as is, vs channel broadcast where it is wrapped internally in aPhoenix.Socket.Broadcaststruct. As far as your dup subscriptions go, it’s the subscribers job to avoid duplicate subscriptions as there is a performance cost in checking on the subscribe side. Hope that helps!nathanl
OK, got it, thanks. For our purposes we want to have the Channel process get the published message and do some standard formatting before it goes out, so we’ll just need to make sure our topics are different for Channels vs PubSub.
Is it accurate to say that each Channel process is paired with one transport process?
LostKobrakai
That’s essentially what
interceptwould do as well.nathanl
Yes, with the difference that if I forget to intercept a particular message, it will go to the client, but if I forget to
handle_infoone, it will blow up and I’ll notice in development.