FluxyChatLearn
After Cloudflare’s real-time chat tutorial
You finished the official Workers + Durable Objects walkthrough — here is what production SaaS chat still needs, and how FluxyChat packages it.
What the tutorial proves
Cloudflare’s real-time chat application tutorial validates the core pattern: WebSocket upgrade on a Worker, shared state in a Durable Object, fan-out to clients in a room.
That is the right mental model. It is not yet multi-tenant auth, billing, operator tooling, or client reconnect semantics.
What teams add next (the long tail)
- Project-scoped JWT and room membership — not open rooms.
- D1 (or equivalent) for history, search, and export — not memory-only fan-out.
- Reconnect, loadMore, and delivery status on the client.
- Quotas, webhooks, GDPR flows, and an operator console.
- Agent tool_call / tool_result on the same timeline as user messages.
FluxyChat as the production layer
- One RoomDurableObject per room — same architecture as the tutorial, maintained in MIT source.
- Self-host on your Cloudflare account or try hosted beta — no second socket vendor.
- @fluxy-chat/sdk for React/Next.js; vanilla store for other stacks.
- Dashboard for projects, rooms, agents, and billing hooks.
Astro, Nuxt, or Vercel front
Keep your UI on Pages, Astro, or Vercel. Point the SDK at your Worker URL. You get edge chat without rebuilding the tutorial boilerplate on every feature.
SMS and WhatsApp in production
Production checklist for Sent.dm offline notify, opt-in, rate limits, and template compliance.
Agent events on the same WebSocket as chat
When humans and copilots share a room, debugging and handoffs are easier if tool_call, tool_result, and user messages share one ordered stream — not a side channel.