Do you need WebSockets in Wheels? Real-world demand check for channels

[bpamiri]

Wheels 4.0 ships real-time channels with pub/sub and Server-Sent Events: publish(), subscribeToChannel(), channelSSETag(), a WheelsSSE JS client, and memory/database adapters — see the Channels guide.

Channels are deliberately SSE-only (server → client). Client → server is a plain HTTP POST that calls publish(). This is the same call AdonisJS made with Transmit: SSE is proxy-friendly, reconnects for free, and reuses your existing HTTP auth — no new connection lifecycle to secure.

Before we invest in a first-party WebSocket layer (#3154), we want evidence it's actually needed — especially since the engine landscape makes it expensive: Lucee has cfwebsocket, Adobe deprecated theirs, BoxLang has none, so a portable implementation means an engine-independent HTTP-upgrade path.

If you build (or want to build) real-time features in Wheels, tell us:

1. What are you building? (live dashboard, chat, collaborative editing, presence/"who's online", game, notifications, …)
2. Does the current SSE + HTTP-POST model actually block it — or did "SSE-only" just read like a missing feature when you evaluated Wheels?
3. Do you specifically need any of: bidirectional streaming (not request/response), binary frames, sub-100ms latency, presence tracking?
4. If you needed WebSockets today, would a documented sidecar pattern (e.g. a small WS server bridging to Wheels channels) be acceptable, or does it have to be in-framework?

If nobody hits a real wall, we'll record a no-go on #3154 and keep improving the SSE path (delivery guarantees, client ergonomics, docs). If there's concrete demand, the answers above shape what actually gets built.

---

Update (2026-07-06): the base decision has been made — WebSockets are coming to Wheels as an opt-in first-party package (wheels-websockets), not a core feature: native on RustCFML (which ships full WS support — channel CFCs, rooms, presence, acks, clustering), emulated on Lucee via the official WebSocket extension, and gracefully absent elsewhere (SSE channels keep working). Design + tracking: #3292.

Your answers here still steer the roadmap — they now decide (a) whether Adobe/BoxLang backends get built, and (b) which capabilities (bidirectional, binary, presence, latency) the package prioritizes. Question 4 gains a third option: beyond "sidecar" and "in-framework," there is now "first-party opt-in package" — tell us if that shape works for you.