How harshil1030/websocket works
1. Overall shape
- This is a two-part demo application: a Node.js WebSocket server and a plain browser client.
- There is no framework layer, no database, and no build pipeline; the architecture is intentionally minimal.
2. Server subsystem (server.js)
- The backend uses the ws Node.js library to host a WebSocket server on port 8080.
- Its job is to accept persistent socket connections, log incoming messages, and send simple text responses back to the same client.
3. Client subsystem (index.html)
- The frontend is a single static HTML page with embedded JavaScript.
- It opens a WebSocket connection directly from the browser to ws://localhost:8080, listens for server messages, and sends user-entered text through the socket.
4. Connection boundary
- The main architectural boundary is the WebSocket channel between browser and server.
- Unlike a typical request/response HTTP app, this connection stays open and supports bidirectional messaging over one long-lived session.
5. Message flow from server to client
- When a browser connects, the server immediately sends a welcome message to that specific socket.
- Any later server responses are also pushed over the same connection and displayed in the page.
6. Message flow from client to server
- User input in the browser is sent over the open WebSocket connection when the Send action occurs.
- The server receives the payload on the per-connection socket, logs it, and replies with an acknowledgment-style message.
7. State and scope
- Connection state is kept per socket in memory only.
- There is no shared application state, persistence, session store, or message broker; each client connection is isolated and handled directly by the server process.
8. Runtime and dependency boundary
- The only runtime dependency is ws, declared in package.json and locked in package-lock.json.
- node_modules is the installed dependency tree; there are no additional services or runtime components.
9. Operational assumptions
- The server must be running before the browser page can connect.
- The client is hardcoded to localhost:8080, so the deployment model is local/demo-oriented rather than configurable production infrastructure.
10. What an architecture diagram should show
- A browser client on one side, a Node.js process on the other, and a single persistent WebSocket link between them.
- Inside the server, show connection handling plus per-message echo/response logic; inside the client, show UI input, socket send, and message display.
Main entry points: index.html Socket JS · server.js WS server · node_modules ws
Components 8
Browser client
Single static page with embedded JavaScript that connects directly to the server.
- index.html · Browser entry point with embedded client logic and UI.
index.html - Socket JS · Opens the WebSocket, sends user text, and handles incoming messages.
index.html - Message UI · Collects user input and displays server responses.
index.html
Node server
WebSocket server process that accepts connections and replies per socket.
- server.js · Starts the WebSocket server and owns connection handling.
server.js - WS server · Accepts persistent browser connections on port 8080.
server.js - Conn handler · Handles each client socket, logs messages, and keeps state in memory.
server.js - Reply logic · Sends welcome and acknowledgment-style responses back on the same socket.
server.js
Runtime deps
Installed Node.js dependency used to implement the WebSocket server.
- ws · External library used to implement the WebSocket server.
node_modules
Connections 8
- index.html → Socket JS: embeds · The page contains the client-side WebSocket script.
- Message UI → Socket JS: user send · User input is sent through the open socket.
- Socket JS → WS server: connects · Browser opens a persistent WebSocket connection to the server.
- WS server → Conn handler: accepts · Each incoming socket is handed to per-connection handling.
- Conn handler → Reply logic: routes · Incoming messages are logged and turned into replies.
- Reply logic → Socket JS: pushes · Server welcome and responses are delivered over the same connection.
- server.js → ws: depends on · The server process relies on the ws package.
- Socket JS → Message UI: updates · Incoming server messages are rendered in the page UI.