REST is trivial on serverless. WebSockets aren't. (What we built instead of Pusher)

Every time I shipped a Next.js or Cloudflare Pages app, HTTP felt solved. Realtime did not.

The usual path:

• Your app on Vercel / CF Pages, REST is easy
• Pusher / Ably / etc., second vendor, second dashboard, second bill
• Glue: auth, history, reconnect, idempotency, on you

I wanted sockets on the same platform as the Worker, without running a socket fleet.

What FluxyChat is

FluxyChat (MIT) is a Worker + one Durable Object per chat room:

• The Room DO owns WebSocket connections, ordering, and fan-out
• D1 stores history and metadata (async after broadcast)
• HTTP routes for tokens, messages, templates, admin

No separate realtime SaaS account, deploy on your Cloudflare stack (or try the hosted beta).

React side (optional)

If you use React, the SDK is thin transport, not the product:

const { messages, sendMessage, connectionState, loadMore } = useChat({
  roomId,
  client,
});

The hard part for us was reconnect + replay + delivery state, not sendMessage() happy path. Cookbook: transport fallback

Video (architecture in ~1 min)

▶ Watch the walkthrough

Links:

• Repo: https://github.com/AlessandroFare/fluxychat
• npm: @fluxy-chat/sdk
• Technical deep-dive (DO per room): Dev.to

Questions for you

1. 1. On serverless, did you add a second vendor for WS or build on CF DO / similar?
2. What broke first in prod, hibernation, reconnect storms, or write batching?

Honest feedback welcome, especially from people who think this is “just another vendor” (happy to clarify: it replaces the Pusher slot on CF, not your frontend host).