🌍 NodeJS · flashcards

NodeJS Networking Flashcards

50 question-and-answer cards covering Networking as it is examined in NodeJS. 24 of them are printed below, taken from across the deck — no signup, no paywall on the preview.

50Cards in deck
24Free preview
6Syllabus topics
~241Chars per answer
FreePrice

24 sample cards from the Networking deck

Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.

  1. With the `ws` library, how does a server send a message to a single connected client?

    Call `ws.send(data)` on that client's socket object, e.g. `ws.send('hello');`. The data can be a string or binary (Buffer/ArrayBuffer).

  2. What key WebSocket events should a server typically handle for each connection?

    'message' (data received from the client), 'close' (client disconnected), and 'error' (connection error). The server-level 'connection' event fires for each new client.

  3. How do you attach a `ws` WebSocket server to an existing Node.js HTTP server so both share a port?

    Pass the HTTP server to the WebSocketServer: `const wss = new WebSocketServer({ server: httpServer });`. This lets HTTP requests and WebSocket upgrade requests be served on the same port.

  4. What does 'broadcasting' mean in a WebSocket server, and how is it implemented with `ws`?

    Broadcasting means sending a message to all connected clients. With `ws` you iterate the server's client set: wss.clients.forEach(client => { if (client.readyState === WebSocket.OPEN) client.send(msg); });

  5. What are the four WebSocket readyState values and their meanings?

    CONNECTING (0) — handshake in progress; OPEN (1) — connection established, ready to communicate; CLOSING (2) — close handshake started; CLOSED (3) — connection closed or could not open.

  6. Before calling client.send() during a broadcast, why check client.readyState === WebSocket.OPEN?

    Because sending to a socket that is CONNECTING, CLOSING, or CLOSED throws an error or fails silently. Checking readyState === OPEN (1) ensures the client is ready to receive, preventing errors on stale/closing connections.

  7. On the browser (client) side, how do you open a WebSocket connection and listen for messages?

    const socket = new WebSocket('ws://localhost:8080'); socket.onopen = () => socket.send('hi'); socket.onmessage = (event) => console.log(event.data); The browser's built-in WebSocket API also supports onclose and onerror handlers.

  8. What is Socket.IO, and how does it differ from the raw WebSocket/`ws` protocol?

    Socket.IO is a higher-level real-time library built on top of WebSockets (with fallbacks like HTTP long polling). It adds features like automatic reconnection, rooms/namespaces, event-based named messages, and broadcasting. Raw WebSockets provide only the basic bidirectional message channel.

  9. In Socket.IO, what are 'rooms' and what are they used for?

    Rooms are arbitrary named channels a socket can join or leave (e.g. `socket.join('room1')`). They let the server target messages to a subset of clients, e.g. `io.to('room1').emit(...)`, which is useful for chat rooms, game lobbies, or per-user channels.

  10. In Socket.IO, what is the difference between socket.emit(), io.emit(), and socket.broadcast.emit()?

    socket.emit() sends only to that one client. io.emit() sends to every connected client including the sender. socket.broadcast.emit() sends to all connected clients except the sender.

  11. What is a 'namespace' in Socket.IO?

    A namespace is a communication channel that lets you split the connection logic over a single shared connection, e.g. `io.of('/admin')`. It allows separating concerns (different endpoints/features) while reusing the same underlying WebSocket.

  12. What is a heartbeat / ping-pong mechanism in WebSockets and why is it needed?

    It is periodic control frames (ping from one side, pong in reply) used to verify the connection is still alive and to keep it open through proxies/firewalls. It detects dead/half-open connections so the server can terminate stale clients.

  13. What CORS-related consideration differs between HTTP requests and WebSocket connections?

    WebSockets are not restricted by the browser's same-origin CORS policy in the same way as HTTP (no preflight); the browser sends an `Origin` header but does not block the connection. Therefore the server must validate the Origin header itself to prevent cross-site WebSocket hijacking.

  14. Give three canonical use cases where WebSockets/real-time communication are the right choice.

    Chat/messaging apps, live notifications and feeds (sports scores, stock tickers), and collaborative or multiplayer applications (shared documents, online games) — anywhere the server must push frequent low-latency updates to clients.

  15. What does the 'upgrade' event on a Node.js http.Server allow you to do?

    It fires when a client requests a protocol upgrade (e.g. to WebSocket) via the Upgrade header. Handling `server.on('upgrade', (req, socket, head) => {...})` lets you take over the raw TCP socket to complete the WebSocket handshake, which is how libraries integrate WS with an HTTP server.

  16. What is the purpose of the Sec-WebSocket-Key and Sec-WebSocket-Accept headers in the handshake?

    The client sends a random base64 `Sec-WebSocket-Key`. The server hashes it with a fixed GUID using SHA-1, base64-encodes the result, and returns it as `Sec-WebSocket-Accept`. This confirms the server understood the upgrade request and completes the handshake.

  17. How does a WebSocket close handshake work, and what is a close code?

    Either side sends a close control frame, optionally with a numeric status code and reason; the peer replies with its own close frame, then the TCP connection is torn down. Close codes (e.g. 1000 = normal closure, 1001 = going away, 1006 = abnormal) indicate why the connection ended.

  18. Can WebSocket messages carry binary data, and how does that compare to HTTP?

    Yes — WebSocket frames support both text (UTF-8) and binary payloads (Blob/ArrayBuffer/Buffer) natively with low framing overhead. HTTP can also carry binary but each transfer needs a full request/response cycle, whereas WebSocket streams frames over the persistent connection.

  19. When building a JSON API route in Node.js, how do you send a JSON response correctly?

    Set the header and stringify the object: res.writeHead(200, { 'Content-Type': 'application/json' }); res.end(JSON.stringify(data)); In Express simply use `res.json(data)`, which sets the header and serializes automatically.

  20. What is the difference between res.send() and res.json() in Express?

    res.send() infers the Content-Type from the argument (string → text/html, object → JSON, Buffer → octet-stream). res.json() always serializes the argument as JSON and sets Content-Type to application/json, even for null/undefined/primitives.

  21. Why should scaling a WebSocket application across multiple server instances use a message broker/adapter (e.g. Redis)?

    Because each server instance only holds its own set of connected clients in memory. To broadcast across all instances, a shared pub/sub backplane (like the Socket.IO Redis adapter) relays messages between servers so a client on one instance receives events emitted from another.

  22. What is backpressure in the context of a WebSocket (or any writable stream) server?

    Backpressure occurs when data is produced faster than the socket can send it, causing the send buffer to grow. In `ws` you can inspect `ws.bufferedAmount`; if it grows unbounded you should pause/throttle sending to avoid memory exhaustion.

  23. How does an HTTP keep-alive connection differ from a WebSocket connection?

    HTTP keep-alive reuses one TCP connection for multiple sequential request-response pairs, but communication is still client-initiated and half-duplex per exchange. A WebSocket permanently upgrades the connection to full-duplex, allowing unsolicited server-to-client messages at any time.

  24. What is the typical event flow for a real-time chat message using a WebSocket server?

    1) A client sends a message over its socket ('message' event on the server). 2) The server optionally validates/persists it. 3) The server broadcasts it to the relevant clients (all, a room, or others) via send/emit. 4) Each recipient's client receives it on its 'message'/onmessage handler and updates the UI — all without any new HTTP request.

What this deck covers

The Networking deck follows the NodeJS Networking syllabus — 2 chapters and 6 topics — so questions land on material that is genuinely examinable rather than trivia around it. That works out to roughly 25.0 cards per chapter.

Answers are written to be recallable, not just readable — averaging about 241 characters, which is long enough to carry the reasoning and short enough to say out loud.

A deck like this earns its keep on the second and third pass. Read the syllabus first so you know the shape of the subject, then use the cards to find the specific facts that have not stuck.

Networking flashcards FAQ

How many Networking flashcards are in this NodeJS deck?

50 cards. This page previews 24 of them, sampled evenly across the deck so you can judge the difficulty before installing anything.

Are these NodeJS flashcards free?

Yes. The preview here is free to read with no signup, and the full 50-card deck is free inside the Examius app.

What do the Networking cards cover?

They follow the NodeJS Networking syllabus — 2 chapters and 6 topics — so the questions track what is actually examinable.

How should I use these flashcards?

Read the syllabus first so you know the shape of the subject, then drill the deck. Examius schedules each card with spaced repetition, so cards you keep missing come back sooner and ones you know drift further apart.