This document outlines the updated architectural decisions, structure, and flow for our messaging app project based on Next.js (frontend) and Node.js (Express + Socket.IO) (backend).
messaging-app/
├── client/ # Next.js (React) frontend
│── server/ # Node.js + Express + Socket.IO backend-
JWT token is stored in a secure, HTTP-only cookie.
-
Token is automatically sent in the
Cookieheader on every request. -
Consumers of the token:
- Frontend (Client) — for page access checks and protecting routes.
- Backend (Server) — for API request authentication and user validation.
-
Server components can read the token from cookies for SSR data fetching.
-
Socket connections read the token from cookies during handshake.
-
Built with Next.js App Router.
-
Uses server components for initial data fetching and SSR.
-
Client components handle:
- Real-time socket events via
useChatSocket. - UI state management for messages, typing indicators, and chat actions.
- Real-time socket events via
-
UI is broken down into reusable parts (Toolbar, Thread, Composer).
-
No direct socket logic inside UI components; all handled in hooks.
-
Built with Express.js + Socket.IO.
-
Middleware stack includes:
- Cookie parsing.
- JWT verification.
-
Socket.IO namespaces/rooms for chats.
-
API endpoints for:
- Fetching chat history.
- Managing members.
- Authentication.
-
Emits and listens for real-time events:
message:new,typing:start,typing:stop.
- Separation of Concerns — Shared responsibilities are clearly defined between client and server.
- Central Socket Layer — All real-time logic is contained in one place for maintainability.
- Composable UI — Reusable, isolated UI components.
- Unified Auth Strategy — Both client and server use the same token source via cookies.
This project is licensed under the MIT License - see the LICENSE file for details.