Home

Extend

Hashnode Pro
Hashnode for Agents

Resources

The foreword
Hashnode gql skill

Buildful - AI coding agent that delivers frontier-level results at a fraction of the cost Bug0 - The AI-native e2e QA regression testing 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

Feed/

Discussion

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

Responses4

Markdown supported · ⌘↵ to post

Julian Neagu

500+ AI tools shipped solo. Founder of VisionVix.

Sep 5

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

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.