Motivation
Browser APIs have evolved a lot recently. CSS flexbox, web sockets, service workers — you can now build something inside a browser that feels very close to a native desktop app. Chat is a perfect test for this idea. Apps like WeChat and WhatsApp have complex real-time UIs, millions of people use them every day. I want to know: can I reproduce that experience purely in the browser, without asking users to install anything?
I have a simple rule — if I cannot build it, I do not really understand it. So I am building it from scratch.
Design
I am using the WeChat web app as the design reference. Not a pixel-perfect copy, but the same layout patterns — conversation list on the left, chat window on the right, responsive enough to collapse into a single-pane view on mobile. All the mockups are done in Photoshop before writing any code. Having a clear visual target before touching the codebase saves a lot of back-and-forth.
Interesting Challenges
Real-time messaging. This is the core of any chat app. I am using Socket.io on top of Koa.js. Socket.io handles the WebSocket connection with automatic fallback to long-polling for older browsers. The tricky part is managing connection state — reconnects, message ordering when a client goes offline briefly, and broadcasting to the right set of connected users without flooding everyone.
Third-party login. I integrate OAuth-based login so users do not need to create yet another account. Getting the OAuth flow right (redirect, token exchange, session creation) is straightforward in theory but has a lot of small edge cases around token expiry and error handling.
Frontend architecture. The SPA is built with AngularJS, which is the dominant framework right now. The app manages a decent amount of client-side state — active conversation, message list, typing indicators, online status — so keeping the data flow clean is important. I use services to encapsulate the Socket.io communication layer so the components never talk to the socket directly.
Testing. I set up Karma as the test runner with Mocha for the test framework. Automated tests cover the core message handling logic and the Socket.io event contracts. Not full coverage, but enough to catch regressions when refactoring.
Technology Stack
- Frontend: AngularJS, Gulp (build tooling)
- Backend: Koa.js, Socket.io
- Database: MongoDB
- Testing: Karma, Mocha
- Design: Photoshop
Takeaway
Real-time systems have a different set of concerns compared to request-response APIs. You have to think about connection lifecycle, message delivery guarantees, and what happens when the network is flaky. These are things you do not run into with a typical REST app. Building this is giving me a solid understanding of how WebSocket-based architectures work in practice.