I've been building FluxyChat — a realtime chat backend running on:

• Cloudflare Workers
• Durable Objects
• D1

Part of the project became a React SDK:

useChat({
  roomId,
  client
})

Current SDK pieces:

• FluxyChatClient
• useChat()
• FluxyRealtimeProvider
• replay/history modes
• connection status handling

Backend architecture is:

• one Durable Object per room
• Worker handles HTTP + WebSocket
• D1 persists history + metadata

One thing I underestimated:
reconnect/replay UX matters way more than the happy-path sendMessage flow.

Repo:
https://github.com/AlessandroFare/fluxychat

npm:
@fluxy-chat/sdk

Would love feedback from React devs:

• is a dedicated chat hook useful?
• what APIs would you expect from useChat()?
• would you rather manage WS state manually?

Hi,

I spent the last 2 months building FluxyChat because deploying realtime WebSockets on serverless is still surprisingly painful.

Most platforms basically say:

>"WebSockets aren't supported properly — use another vendor."

So you end up adding Pusher, Ably, or another realtime provider on top of your existing stack.

I wanted something smaller and more inspectable that I could fully own.

So I built FluxyChat on:

• Cloudflare Workers
• Durable Objects
• D1
• Next.js
• TypeScript

What FluxyChat is

FluxyChat is a hosted multi-tenant realtime chat backend with:

• REST + WebSocket APIs
• a Next.js operator console
• a TypeScript SDK
• self-host support

The idea is:

npm i @fluxy-chat/sdk

Connect your Worker and get realtime rooms running quickly.

SDK example

import { FluxyChatClient, useChat } from '@fluxy-chat/sdk';

const client = new FluxyChatClient({
  baseUrl: 'https://your-worker.example.com',
  userId: 'alice',
  token: 'your-member-jwt'
});

Current architecture

• Cloudflare Worker handles HTTP + WebSocket
• One Durable Object per room
• D1 for messages + metadata
• Next.js console on Vercel
• @fluxy-chat/sdk for frontend integration

What's live in open beta

• Multi-tenant rooms over WebSocket
• JWTs scoped by tenant/project
• AI agents streamed directly in the room timeline
• Webhooks + billing hooks
• MIT licensed
• Fully self-hostable on your own Cloudflare account

Links

Demo video: Build Real Time Chat With FluxyChat

Try it: https://www.fluxychat.com/get-started

Repo: https://github.com/AlessandroFare/fluxychat

I'd genuinely love feedback from people who've worked with Durable Objects or realtime infra before.

Especially curious about:

1. Whether one-DO-per-room feels like the right pattern
2. If signup friction is too high right now
3. What would make you choose hosted vs self-hosted

Spent the last couple months building FluxyChat on:

• Workers
• Durable Objects
• D1

The core pattern is:

>one Durable Object per room

The Room DO handles:

• WebSocket sessions
• ordering
• realtime broadcast
• coordination

D1 stores:

• messages
• quotas
• metadata

A few things that worked well:

• single-writer room ownership
• simpler fan-out logic
• idle room hibernation

Things that became harder later:

• reconnect storms
• cross-room analytics
• replay consistency
• D1 write amplification

Implementation is here:
https://github.com/AlessandroFare/fluxychat/tree/main/apps/worker/src/durable-objects

Questions for people running DOs in production:

1. How are you handling reconnect storms after hibernation?
2. Are you batching D1 writes aggressively?
3. Have you kept the “one DO = one room” model long term?