3. After initialization, protocol switch happens, WebSocket protocol will takeover.
It can start to handle TCP messages from clients and Erlang messages from the Phoenix channel servers.
* The websocket_handle callback will be called when clients send messages to the socket.
If there's no related Phoenix channel server, a server process will be started under the dynamic supervisor.
* The websocket_info will be called if the channel sends messages to the socket process.
4. Broadcast
when a channel server is spawned, the PID is registered under the full topic name in the registry.
If you broadcast a message to a topic, all the pids are retrieved from the registry, and messages will be sent out to either the channel process or socket process.
5. Your turn
Now it's time to read more codes and do some experiments. Happy building!
A retweet to the first tweet would be greatly appreciated. 💌
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Phoenix.PubSub is probably the most important component in @elixirphoenix@elixirlang .
We will benefit a lot by understanding the internals of Phoenix.PubSub.
* a :pg server is started with the scope name: Pheonix.PubSub
* a pubsub supervisor supervises a registry and an adapter server
* the adapter server joins a :pg group during initialization
The adapter server is also the PubSub shard, they exist to broker broadcasts across the cluster, and relay those messages to local node subscribers which are recorded in the ETS table in the registry.