Two sources of truth
A separate realtime provider means the socket payload and the database row are maintained by different code.
Workloads
The row changed, so the screen changed.
Chat, collaboration, live dashboards, and order tracking all reduce to the same problem: something happened on the server and a browser needs to know now. Model events, broadcast channels, and STX signals connect those two ends without a second realtime service in the middle.
What this always turns out to involve.
The work that arrives whether you planned for it or not.
Authorisation over sockets
Channel access needs the same rules as the HTTP request, or it becomes the way around them.
Presence is stateful
Who is online, in which room, on how many tabs, and what happens when the process restarts.
Reconnects lose messages
A dropped socket without replay shows a user a stale screen that looks live.
What is already in the box.
All of it in the same install, typed against the rest of your application.
Channels
Public, private, and presence channels with authorisation checked through the same gates as routes.
Model broadcasts
The observe trait emits created, updated, and deleted events, which can broadcast without extra plumbing.
Client signals
STX signals bind an incoming message to the DOM without a client framework or a store to configure.
Queue-backed fan-out
Heavy broadcasts go through the queue, so a fan-out to thousands of sockets does not block the request.
Local and deployed parity
The realtime driver runs in buddy dev exactly as it does in production, configured in config/realtime.ts.
Fallbacks
Polling and server-sent events remain available where sockets are blocked, behind the same API.
The layers it leans on.
Every one of these ships in the same install. Follow one to see what it covers.
From the command line.
Buddy scaffolds, runs, and ships this the same way it does the rest of the app.
buddy make:action BroadcastOrder
buddy dev
buddy queue:work
Next door to this.
Projects of this shape usually grow into one of these.