What I Learned Building a Real-Time Social Media App (Flux)

Flux was my first attempt at combining a social media app with real-time features done properly, not just bolted on. The first big decision was switching to TypeScript across the stack. It slowed me down at first, but catching type mismatches at compile time — especially around API responses and Socket.io event payloads — saved me from a lot of runtime bugs later. Authentication went beyond simple JWT this time. I added an OTP-based password reset flow using Nodemailer, where a 6-digit code is generated, emailed, and verified server-side before a reset token is issued. It taught me how to think about short-lived, single-use credentials as their own small subsystem. Real-time notifications were the hardest part. Using Socket.io rooms scoped per authenticated user, I had to make sure events for follows, reactions, and comments were emitted reliably and only to the right client. I ran into a race condition where sockets connected before the auth context finished hydrating, so notifications silently failed on first load. Delaying socket initialization until auth resolved fixed it — a good reminder that timing bugs in real-time systems are often invisible until you're staring at the network tab. Building Instagram-style stories pushed me further into data modeling. Auto-expiring content via MongoDB TTL indexes, per-image view tracking, and a viewers list meant thinking carefully about what data actually needs to persist versus what can just disappear. I also hit subtle bugs from comparing MongoDB ObjectIds to plain strings in the follow/block logic — silent failures that only showed up in specific edge cases. Normalizing IDs with `.toString()` at the service layer, plus adding a proper AppError class with error codes, made debugging far less painful going forward. Flux taught me that real-time features aren't just an extra layer on top of a REST API — they're a different way of thinking about state, timing, and consistency across clients.