Feed
Pro
Search

Sign in
Darkshift - a dark factory for software Bug0 - The AI-native e2e QA regression testing The foreword by Hashnode - official blog from the Hashnode team Passmark - The open-source AI framework for regression testing Hashnode gql skill - let your AI agent publish to your Hashnode blog Hackathons Changelog Brand @hashnode on X Hashnode on LinkedIn Support - hello+support@hashnode.com Code of Conduct Terms Privacy Sitemap

Search Hashnode

Search posts, tags, users, and pages

Discussion on "I Built a Real-Time Collaborative Whiteboard to Understand Stateful Backends" | Hashnode

FeedDiscussion

Anshuman Praharaj

coffee and goofy ah code

Sep 4

I Built a Real-Time Collaborative Whiteboard to Understand Stateful Backends

the inspiration i wanted to learn websockets and realtime communication since a long time. i did a few failed attempts at it too, trying to learn it all by myself. half-assed a few projects and left t

newsletter.anshumancdx.xyz11 min read

#websockets #nodejs #turborepo

Responses(4)

Julian Neagu

500+ AI tools shipped solo. Founder of VisionVix.

the part about state clicked for me too. building the room map makes the whole websocket flow much easier to reason about

Sep 5

Raunak Singh

Founder of Bookmarx and Vordi, building useful AI products.

Sep 5

Splitting HTTP auth and history from WebSocket broadcast makes the architecture easy to follow. The next scaling challenge would be moving room membership out of a single process. Are you planning Redis pub/sub or sticky sessions first?

Anshuman Praharaj

coffee and goofy ah code

Sep 5

yes will using pub/sub for scale is ofc the next thing

Raunak Singh

Founder of Bookmarx and Vordi, building useful AI products.

Sep 16

Nice. Redis pub/sub is a natural next step. I would keep room state behind a small adapter so you can compare in-memory and Redis implementations without changing the WebSocket handlers. That should make the scaling path easier to test.