DEV Community: Nikhil Sharma

How Messages Actually Flow in a Custom Real-Time Chat App

Nikhil Sharma — Thu, 09 Jul 2026 18:54:19 +0000

When I set out to build Relay, I had one clear goal: I wanted to truly understand what happens under the hood when you hit "send" on an app like WhatsApp or Telegram. No Firebase, no Socket.IO, no magic. Just raw WebSockets, Node.js, and a PostgreSQL database.

In my previous project updates, I outlined the high-level architecture. Today, I want to go deeper. This is a deep dive into the 5-step message send flow—expanding on the sequence of events, the ACK pattern, and how the system gracefully handles offline users.

If you're curious about the mechanics of real-time distributed systems, grab a coffee. Let's dissect how a message actually gets from User A to User B.

The Architecture at a Glance

Before we dive into the code, let's visualize the flow. Here is the exact sequence of events when a user sends a message:

(Note: In a local single-instance setup, Server A and Server B are the same server, but relying on Redis Pub/Sub means this scales horizontally out of the box).
P.S. Sorry about the blurry architecture diagram—I couldn't get it to export at a higher resolution. I'll replace it with a better version soon.

Step 1: The Frontend Send (JSON Frames)

With raw WebSockets, you don't get the luxury of Socket.IO's fancy event emitters. Everything sent over the wire is just a string. In Relay, I use JSON frames with a discriminated union structure to strictly type all messages.

When you hit "Send" in the React frontend, it triggers the sendMessage function inside my custom useWebSocket hook:

const sendMessage = useCallback((to: string | undefined, content: string, id: string, groupId?: string) => {
  if (socketRef.current?.readyState === WebSocket.OPEN) {
    if (groupId) {
      // Group message logic...
    } else if (to) {
      socketRef.current?.send(
        JSON.stringify({
          type: "send_message",
          payload: { to, content, id },
        }),
      );
    }
  }
}, []);

It’s completely asynchronous from the frontend's perspective. We just fire the JSON frame into the void and trust the WebSocket connection to carry it.

Step 2: The Backend Handler & Database Persistence

When the backend receives this frame, the send_message event is routed to my message handler. The handler does two critical things simultaneously: it persists the message to PostgreSQL and publishes it to Redis.

export async function sendMessage(
  senderId: string,
  msg: Extract<WsMessage, { type: "send_message" }>,
) {
  const { to, content } = msg.payload;

  // 1. Check if user is online to determine delivery status
  const deliveredAt = (await presence.isOnline(to)) ? new Date() : null;

  // 2. Persist to Postgres via Prisma
  await saveMessage(to, senderId, content, msg.payload.id, deliveredAt);

  const sender = await prisma.user.findUnique({ where: { id: senderId } });

  // 3. Publish to Redis Pub/Sub for cross-instance delivery
  await pubsub.publishMessage({
    userId: to,
    payload: {
      type: "receive_message",
      payload: {
        from: senderId,
        name: sender?.name,
        content,
        id: msg.payload.id,
      },
    },
  });

  // (Delivery acknowledgment logic for the sender omitted for brevity)
}

Notice the presence.isOnline(to) check. I am definitively recording whether this message is undelivered or delivered right at the moment of creation. If the user is offline, deliveredAt is set to null.

Step 3: The Redis Pub/Sub Delivery

Why use Redis here instead of just looking up the recipient in an in-memory Map of active WebSockets?

If you rely solely on a local Map<userId, WebSocket>, your chat app can never scale beyond a single Node.js process. If User A connects to Server 1 and User B connects to Server 2, Server 1 has no way to natively push a message to User B's socket.

By publishing the receive_message payload to a Redis channel, every backend instance hears it. The instance that actually holds User B's live WebSocket connection intercepts the Redis event and pushes it down the wire:

{
  "type": "receive_message",
  "payload": {
    "from": "user-a-uuid",
    "content": "Hey, what's up?",
    "id": "msg-1234"
  }
}

Step 4: The ACK Pattern

Here’s a subtle but crucial detail of building raw WebSocket apps: How does the sender know the server actually received and processed the message?

HTTP has status codes. You make a POST request, you get a 201 Created back. WebSockets, however, are full-duplex streams. When the client calls socket.send(), there is no automatic confirmation.

To solve this, I implemented an ACK (acknowledgment) pattern in the main socket listener.

ws.on("message", async (data) => {
  try {
    const msg = WsMessageSchema.parse(JSON.parse(data.toString()));

    switch (msg.type) {
      case "send_message": {
        await sendMessage(id, msg); // DB save and Redis publish happens here

        // Return the ACK to the sender
        ws.send(
          JSON.stringify({ type: "ack", payload: { status: "sent" } }),
        );
        break;
      }
      // ... other cases
    }
  } catch (e) {
    ws.send(JSON.stringify({ type: "error", payload: { message: "Failed to process message" } }));
  }
});

When the frontend receives this { type: "ack" }, it knows the message safely made it to the database. Before this ACK, the message should technically show a "sending..." state (like a clock icon) in the UI. Once the ACK hits, we transition to a single checkmark (Sent).

Step 5: What Happens When the Recipient is Offline?

If the recipient is completely offline (their phone is off, tab is closed), the Redis publish happens, but no server instance picks it up to deliver via WebSocket.

Because presence.isOnline(to) returned false back in Step 2, the database row has deliveredAt: null.

When the recipient finally opens the app, two things happen:

REST History Fetch: The frontend fetches the chat history via a standard HTTP REST endpoint (/messages). I use HTTP for history because it's stateless, easily cacheable, and better suited for loading large JSON arrays than WebSocket frames.
Delivery Confirmation: During the WebSocket connection handshake for the newly online user, the backend runs a cleanup task:

// Inside the WebSocket connection handler
sockets.addUser(id, ws);

// Find all messages sent to this user where deliveredAt is null
// Update them with the current timestamp and notify senders
await markMessagesAsDelivered(id);

markMessagesAsDelivered queries the database for all pending messages, updates them, and then fires off delivered_messages events through Redis back to the original senders. The sender's UI instantly flips from a single checkmark to a double checkmark, knowing their message has finally landed on the recipient's device.

Wrapping Up

As I said in the previous post in the series, abstracting WebSockets with tools like Socket.IO is great for getting an MVP out the door quickly. But building the message framing, persistence logic, ACK patterns, and Redis pub/sub layer yourself gives you an unparalleled understanding of system design.

You stop seeing a chat app as "magic" and start seeing it as a beautifully orchestrated dance of database rows, pub/sub channels, and TCP streams.

If you're building something similar or want to dive into the codebase, Relay is completely open-source. Feel free to reach out in the comments!

I'll be back with more next week. Until then, stay consistent!

Why I Ditched Socket.IO for Raw WebSockets (And What I Learned)

Nikhil Sharma — Sat, 04 Jul 2026 06:34:18 +0000

When you google "how to build a chat app in Node.js," the very first result will almost certainly point you to Socket.IO. It is the de facto standard for a reason. When I started my project, I used it without a second thought. It worked like magic.

But as I got deeper into the project, that magic started to feel more like a black box. I eventually ripped out Socket.IO and replaced it with raw, native WebSockets. It was a daunting decision, but having built and managed it myself, I have some strong opinions on what Socket.IO abstracts away, what I had to build from scratch, and whether the headache was actually worth it.

The Magic of Socket.IO (And Why We Use It)

To understand why walking away from Socket.IO is hard, you have to understand exactly how much heavy lifting it does for you behind the scenes. It isn't just a WebSocket library; it is a real-time framework.

The Polling Fallback: Historically, if a user's corporate firewall blocked WebSockets, Socket.IO would seamlessly downgrade to HTTP long-polling.
Automatic Reconnections: If a user drives through a tunnel and loses the connection, Socket.IO automatically handles the exponential backoff to reconnect them when they emerge.
Rooms and Namespaces: It gives you a beautiful socket.to("room-1").emit() API for broadcasting messages to specific groups of users.
Heartbeats: It manages ping/pong messages under the hood to ensure the connection hasn't silently died.

When you drop Socket.IO, you lose all of this for free.

So, Why Did I Walk Away?

First, the fallback mechanism is largely a relic of the past. Today, native WebSocket support across modern browsers and network infrastructure is essentially ubiquitous. I didn't need to ship a massive client bundle just to support HTTP polling for the 0.1% of edge cases.

Second, the lock-in is real. If you use Socket.IO on the client, you must use a Socket.IO server implementation. You can't just connect to a standard WebSocket server. I wanted the freedom to swap out my backend without being tied to the Socket.IO ecosystem.

Most importantly, I hated not understanding my own system. When a connection failed in Socket.IO, debugging the complex state machine of fallbacks and upgrades was a nightmare. I wanted full control over the wire.

Building It Myself: What I Had to Think About

Moving to raw WebSockets meant I was suddenly responsible for the entire connection lifecycle. Here is exactly what I had to build to replicate the "magic."

1. The Reconnection Engine

Native WebSockets do not reconnect when they drop. If the connection closes, it stays closed. I had to write a custom wrapper that implemented exponential backoff.

// Initializing refs to track reconnection state
const reconnectAttemptsRef = useRef(0);
const reconnectTimeoutRef = useRef<number | null>(null);
const shouldReconnectRef = useRef(true);

const connect = () => {
  const socket = new WebSocket(WS_URL);

  socket.onopen = () => {
    // Reset backoff attempts on successful connection
    reconnectAttemptsRef.current = 0;
  };

  // ... (message handling logic)

  socket.onclose = () => {
    // Don't reconnect if the component is unmounting
    if (!shouldReconnectRef.current) return;

    // Exponential backoff: 1s, 2s, 4s, 8s, up to a maximum of 30s
    const delay = Math.min(1000 * 2 ** reconnectAttemptsRef.current, 30000);
    reconnectAttemptsRef.current++;

    reconnectTimeoutRef.current = window.setTimeout(() => {
      connect();
    }, delay);

    console.log(`Reconnecting in ${delay}ms...`);
  };
};

// Cleanup on unmount
useEffect(() => {
  // ...
  return () => {
    shouldReconnectRef.current = false;
    if (reconnectTimeoutRef.current !== null) {
      clearTimeout(reconnectTimeoutRef.current);
    }
    socketRef.current?.close();
  };
}, [user]);

2. Custom Payload Routing

Socket.IO lets you do socket.on('new_message', handler). Raw WebSockets only give you a single onmessage event with a text payload. I had to build my own event router using standard JSON parsing and switch statements.

ws.onmessage = (event) => {
  const payload = JSON.parse(event.data);

  switch (payload.type) {
    case 'NEW_MESSAGE':
      handleNewMessage(payload.data);
      break;
    case 'USER_TYPING':
      handleUserTyping(payload.data);
      break;
  }
};

Wrapping up

You may ask was it worth it?
I would say it absolutely was.

Yes, it took a few days to write robust wrapper classes for reconnects and message routing. But once it was built, the benefits were immediate.

My client bundle size dropped significantly. My backend was no longer coupled to a specific framework, allowing me to route raw WebSockets through standard load balancers with ease. But the biggest benefit was mental clarity. When a connection drops now, there is no magic "black box" trying to fix it behind the scenes. I know exactly how my code reacts, I know exactly what bytes are going over the wire, and debugging is as simple as reading my own logs.

If you are at a hackathon and need real-time features done yesterday, use Socket.IO. It is brilliant for rapid prototyping. But if you are building a production system and want deep, fundamental control over your architecture, raw WebSockets are nowhere near as scary as people make them out to be. Doing it the hard way is how you actually learn the web.

Again, you can check out the codebase on my github and the live deployment here.

I'll be back with more next week. Till then, stay consistent!

Why I Chose a Dual Protocol Architecture: REST + WebSockets

Nikhil Sharma — Thu, 25 Jun 2026 06:50:51 +0000

When I first started building the real-time chat features for my project, the initial architectural decisions seemed quite simple to me. It was going to be a "real-time" app so 'obviously' I needed WebSockets. My first instinct was to use a socket event for everything whether it be authentication or even loading chat history.
Eventually, I read some articles pertaining to the same and then shifted to the dual architecture which is in place now. Which is REST+WebSockets and using each protocol for what its good at.

The common first thought

It is incredibly tempting to establish a WebSocket connection and route the entire application state through it. It feels clean to have a single pipe to the server.

But I quickly ran into the architectural realities of stateful WebSocket connections. While they are good for maintaining persistent duplex connections, they provide a much lower-level transport abstraction than HTTP.

On fetching the older chat history, I immediately missed standard HTTP status codes. If a request failed, I had to myself make my own error-handling payload structure as there was no automated 404 or 401 code being sent. As in WebSockets, after a connection is established, there are no HTTP responses, its all just messages. So I lost out on all standard HTTP semantics, which meant a lot more work for me.

WebSockets are inherently stateful which makes load balancing and scaling much more complex, each connection has to stay attached to a server, so horizontally scaling requires connection-aware load balancing and some shared mechanism (such as Redis Pub-Sub) to broadcast events across instances as compared to spinning up stateless REST APIs behind a standard reverse proxy.

Why Not Just HTTP Polling?

On the other end of the spectrum I very briefly considered avoiding WebSockets entirely. Why not just use REST for everything and implement polling?

// The classic polling trap
function startPolling(roomId) {
  setInterval(async () => {
    const newMessages = await fetch(`/api/rooms/${roomId}/messages?since=${lastTimestamp}`);
    // Handle new messages...
  }, 3000);
}

The issue with polling became apparent the moment I thought about the user experience and server load. With short polling I would be sending HTTP requests every few seconds. And 90% of the time the server's response would be an empty array because no new messages had arrived. This results in massive HTTP overhead, unnecessary server strain and an inherent latency equal to the polling interval, which I just did not like seeing when I tested a dummy app.

Even long-polling (where the server holds the request open until a message arrives) felt like a hacky workaround to simulate the persistent connection that WebSockets natively provide.

And so I instantly knew that polling, long or short, is not an option for my case.

The Ideal Architecture

            React Client
                 │
      ┌──────────┴──────────┐
      │                     │
      ▼                     ▼
 REST (Request/Response)   WebSocket (Events)
      │                     │
      │                     │
 Load state            Live updates
(Login, Users,         (Messages,
 History, etc.)        Typing, Presence)
      └──────────┬──────────┘
                 ▼
         Backend + Database

I eventually landed on a dual-protocol approach. The mechanism was easy to understand, anything that is coming out of the database(essentially older stuff) comes from the HTTP side of things, anything realtime comes from the WS side of things.

1. REST for initial state

I use standard REST endpoints for operations that follow a Request-Response model.

Fetching a user's profile.
Fetching the list of users.
Loading the initial chat history for an open chat.
Authenticating the user.

By doing this I could keep my backend mostly stateless for the heavy queries.

2. WebSockets for the Real-Time Pipeline

Once the static state is loaded via REST, I open a WebSocket connection strictly as an event pipeline. The socket's only job is to push real-time events from the server to the client.

new message
typing event
isOnline event

Here is a simplified snippet(not from the codebase because there is a lot of other stuff going on there) of how I orchestrate this dual approach when a user enters a chat room:

async function enterChatRoom(roomId) {
  // 1. Fetch the static history via REST
  try {
    const response = await fetch(`/api/rooms/${roomId}/history`);
    if (!response.ok) throw new Error('Failed to load history');

    const pastMessages = await response.json();
    setMessages(pastMessages);

  } catch (error) {
    handleRestError(error);
    return;
  }

  // 2. Open the WebSocket strictly for real-time events
  // We get low-latency, bi-directional communication without HTTP overhead
  const ws = new WebSocket(`wss://api.myproject.com/rooms/${roomId}/live`);

  ws.onmessage = (event) => {
    const data = JSON.parse(event.data);

    if (data.type === 'NEW_MESSAGE') {
      setMessages(prev => [...prev, data.message]);
    } else if (data.type === 'USER_TYPING') {
      showTypingIndicator(data.userId);
    }
  };

  return () => ws.close();
}

Conclusion

Building this project taught me that just because a technology can do something doesn't mean it should. WebSockets are an incredible tool for real-time, low-latency communication, but they are a poor substitute for the robust, heavily-standardized world of RESTful HTTP.

By utilizing a dual-protocol architecture, I avoided the heavy overhead of HTTP polling while simultaneously saving myself from the nightmare of reinventing routing, caching, and error handling over a raw socket connection.

I'll be back with more next week. Till then, stay consistent!

The Stale Closure Bug That Haunted My Chat App

Nikhil Sharma — Sun, 14 Jun 2026 05:53:19 +0000

Building a real-time chat app sounds straightforward until React's rendering model meets WebSockets . In Relay, I built what I thought was a solid real-time integration. Everything seemed to work perfectly—until I started switching between conversations.

What I Built

In Relay, I wanted a clean separation of concerns, so I extracted my WebSocket logic into a custom hook called useWebSocket. It takes an onMessage callback so my Chat UI can decide how to handle incoming messages:

// Chat.tsx
const { sendMessage } = useWebSocket((msg) => {
  // If the message is from the person I'm actively chatting with, add it to the window
  if (selectedUser && msg.senderId === selectedUser.id) {
    addMessage(msg);
    return;
  }

  // Otherwise, show a toast notification
  toast(`${msg.sender.name}: ${msg.content}`);
});

Inside useWebSocket.ts, I wired up the actual WebSocket connection inside a useEffect:

// useWebSocket.ts (The broken version)
export function useWebSocket(onMessage: (msg: Message) => void) {
  const { user } = useAuth();
  useEffect(() => {
    const socket = new WebSocket(WS_URL);

    socket.onmessage = (e) => {
      const msg = JSON.parse(e.data);
      if (msg.type === "receive_message") {
        onMessage(msg.payload);
      }
    };
    return () => socket.close();
  }, [user]); // Only reconnect if the authenticated user changes
}

What Broke

At first glance, this code looks entirely reasonable. I'd open Relay, click on Alice's profile, and we'd start chatting. It worked flawlessly.

Then, I'd switch my active chat to Bob. Bob would send me a message, but instead of the message appearing in Bob's chat window, a toast notification would pop up. Even worse, if Alice sent me a message while I was looking at Bob's chat, her message silently injected itself directly into Bob's chat window!

I was literally watching the messages of one user show up in another user's chat after I switched.

Why It Broke (The Mental Model)

The culprit was a classic React gotcha: the stale closure.

When the useWebSocket hook ran for the first time, the useEffect established the WebSocket connection. The socket.onmessage event listener was created, and it permanently "captured" the onMessage function from that specific initial render.

In that first render, selectedUser was Alice.

When I clicked on Bob in the sidebar, React re-rendered my Chat component. A brand new onMessage function was created where selectedUser was Bob. However, because my useEffect dependency array only included user, the effect didn't re-run. The WebSocket stayed connected—which is what we want.

But this meant the socket.onmessage listener was still holding onto the very first onMessage function it captured—the one where selectedUser is permanently frozen as Alice.

If I simply added onMessage to the useEffect dependency array to fix the stale state, the WebSocket would brutally disconnect and reconnect every single time I clicked a new user, typed a character, or triggered a re-render. That's terrible UX and a massive performance killer.

The useRef Fix

I needed a way for the WebSocket listener to always access the freshest version of the onMessage callback, without actually triggering the useEffect to tear down the socket.

Enter useRef.

Unlike state, updating a ref doesn't trigger a re-render. More importantly, a ref is a mutable object that persists across renders. By continuously storing the latest callback in a ref, the WebSocket listener can just peek into ref.current and always find the most up-to-date function.

Here is the exact code that fixed the bug in Relay:

// useWebSocket.ts (The fixed version)
export function useWebSocket(onMessage: (msg: Message) => void) {
  const { user } = useAuth();

  // 1. Create a ref to hold the callback
  const onMessageRef = useRef(onMessage);
  // 2. Silently update the ref every time the callback changes (on every render)
  useEffect(() => {
    onMessageRef.current = onMessage;
  }, [onMessage]);
  useEffect(() => {
    const socket = new WebSocket(WS_URL);

    socket.onmessage = (e) => {
      const msg = JSON.parse(e.data);
      if (msg.type === "receive_message") {
        // 3. Always call the freshest callback stored in the ref!
        onMessageRef.current(msg.payload);
      }
    };
    return () => socket.close();
  }, [user]); 
}

The Takeaway

Whenever you integrate long-lived event listeners (like WebSockets, window events, or setInterval) with React components, you have to be paranoid about what variables are being captured in their closures. If you need access to constantly changing React state inside a permanent event listener, the useRef escape hatch is your best friend.

I'll be back with more next week. Until then, stay consistent!

Sidenote

Relay is now live: https://relay.nikshrma.dev

It's running on a DigitalOcean droplet and has been a great playground for learning WebSockets, authentication, testing, and deployment.

You can also find my portfolio at https://nikshrma.dev.

The WebSocket Auth Problem: Cookies vs. Bearer Tokens

Nikhil Sharma — Wed, 03 Jun 2026 20:23:14 +0000

If you've ever built a real-time web app using WebSockets, you've probably hit this exact wall - how do I do the auth.

On the HTTP side, the answer is pretty simple. You either use a cookie, which has so many npm packages, or you attach an Authorization: Bearer <token> header to your requests, which is a simple JWT signed string. However, things get a bit weird on the WebSocket side of things.

The fundamental issue stems from how WebSocket connections are established. Before a WebSocket connection becomes a continuous bidirectional channel of data, it starts off as a simple HTTP GET request with an Upgrade header. This is known as the WebSocket Handshake.

Let's dive into why this handshake makes the seemingly simple task of authentication a surprisingly nuanced architectural decision.

Why Bearer Tokens are Clunky for WebSockets

If your application relies on Bearer tokens (usually stored in memory or local storage on the client side), you are used to attaching them via the Authorization header using an interceptor or a fetch wrapper.

// A typical HTTP request with a Bearer token
fetch('/api/data', {
  headers: {
    'Authorization': `Bearer ${myToken}`
  }
});

However, the native browser WebSocket API does not support custom headers.

// This is all we get.
const ws = new WebSocket('wss://api.myapp.com/socket');

Since you can't pass the token in an Authorization header during the initial HTTP Upgrade request, developers are forced into clunky workarounds:

Query Parameters: Passing the token in the URL (wss://api.myapp.com/socket?token=ey...). This is generally considered a bad practice because URLs (and the sensitive tokens within them) end up in server logs, browser histories, and proxy logs.
First Message Auth: Opening the WebSocket connection unauthenticated, and then requiring the client to immediately send an authentication message containing the token before the server accepts any further messages. While secure, this adds latency and complexity to the connection lifecycle logic. You have to write boilerplate to handle connections that open but never authenticate.
Subprotocols: A hacky but working method where the token is passed as a WebSocket subprotocol (new WebSocket('wss://...', ['access_token', token])).

None of these feel particularly clean or idiomatic.

Why Cookies Work Naturally

This brings us to cookies, the method that I chose for Relay! Cookies are managed by the browser. Whenever the browser makes an HTTP request to a domain, it automatically attaches the cookies associated with that domain.

Because the WebSocket handshake is just a standard HTTP GET request, the browser automatically includes your cookies in the first request itself!

If your authentication system sets an HTTP-only cookie containing your JWT or session ID when the user logs in, you literally don't have to change any client-side code to authenticate your WebSockets. The browser handles it natively and securely.

// The browser automatically attaches the JWT auth cookie!
const ws = new WebSocket('wss://api.myapp.com/socket');

The Backend Implementation: Parsing the Cookie

While the client side becomes trivial, the backend need manual cookie parsing. When your WebSocket server receives the upgrade request, it hands you a raw Node.js IncomingMessage object.

Unlike Express requests which come with the cookies objects provided by middleware, the IncomingMessage just gives you the raw cookie header string. You have to parse it yourself before accepting the WebSocket connection.

Below is how I did the cookie parsing in Relay!

1. Extracting and Verifying the Token

First, we need a utility function to take the raw IncomingMessage, parse the cookie string, and verify our JWT.

import cookie from "cookie";
import jwt from "jsonwebtoken";
import type { IncomingMessage } from "http";
import { jwtPayloadSchema } from "../../http/schemas/auth.schema.js";

// Extract user ID from the raw HTTP upgrade request
export function extractUserId(req: IncomingMessage): string | null {
  // Parse the raw cookie header string
  const cookies = cookie.parse(req.headers.cookie ?? "");
  const token = cookies.token;

  if (!token) return null;

  try {
    // Verify the JWT signature
    const decoded = jwt.verify(token, process.env.JWT_SECRET as string);

    // Validate the payload shape
    const parsed = jwtPayloadSchema.safeParse(decoded);
    if (!parsed.success) {
      return null;
    }

    // Return the authenticated User ID
    return parsed.data.id;
  } catch {
    return null; // Token is invalid or expired
  }
}

2. The main Socket handling code

Now here, I integrate this utility into my WebSocket server initialisation. I intercept the connection, attempt to extract the user ID, and immediately close the connection with a 4001 Unauthorized status if the authentication fails.

import { WebSocketServer, type WebSocket } from "ws";
import type { Server as HttpServer } from "http";
import { extractUserId } from "./handlers/message.handler.js";
import { sockets } from "./store.js";

export function initWebSocketServer(server: HttpServer) {
  const wss = new WebSocketServer({ server });

  wss.on("connection", (ws: WebSocket, request: IncomingMessage) => {
    ws.on("error", console.error);

    // 1. Authenticate immediately using the parsed cookie
    const id = extractUserId(request);

    // 2. Reject unauthenticated connections at the handshake level
    if (!id) {
      ws.close(4001, "Unauthorized");
      return;
    }

    // 3. Connection is fully authenticated!
    // We can safely associate this socket with the user
    sockets.addUser(id, ws);

    // Proceed with authorized application logic...
    console.log(`User ${id} connected successfully.`);

    ws.on("message", async (data) => {
      // ... handle incoming messages knowing the sender's true identity
    });

    ws.on("close", () => {
      sockets.removeUserSocket(id, ws);
    });
  });
}

Wrapping up

When building real-time applications, relying on HTTP-only cookies for authentication eliminates the friction of securing WebSockets. By leaning on the browser's native cookie management, we avoid leaking tokens in URLs and bypass the complexity of first-message authentication handshakes. It requires a tiny bit of manual header parsing on the backend, but the resulting client-side simplicity and security posture are well worth the trade-off.

For those of you who would like to go through the codebase, you can do so here.
I'll be back with more next week. Until then, stay consistent!

I Built a Real-Time Chat App from scratch - Here's What I Learned

Nikhil Sharma — Tue, 26 May 2026 18:03:37 +0000

When dealing with WebSockets, most tutorials will straightaway hand you Socket.io and call it a day. You get a working chat app in short period of time but you have no idea what happened.

I actually wanted to understand what was going on, how WebSockets work, how auth happens, how to deal with cookies when working with WebSockets and so many more tiny things.
So I built Relay. A full stack real-time chat app with raw WebSockets, Express for the backend, React for the frontend and PostgreSQL.
The reason for doing everything manually was that I wanted to learn. I did not want to launch and make a chat app and sell it. I just wanted to learn the implementation of these technologies.

Thus, here we are. This is the first post in a series where I will be exploring the project and breaking down the most interesting technical problems I ran into. But first, let's see what Relay is, how it works, and why I built it the way I did.

What Relay Does

Real-time messaging — Messages are sent and received instantly over WebSockets. No polling, no long-polling, no hacks.
Persistent history — Every message is stored in PostgreSQL via Prisma ORM. Close the tab, logout, the messages will still be there when you come back.
Cookie-based auth — JWT tokens stored in httpOnly cookies. The WebSocket handshake authenticates by manually parsing cookies from the upgrade request headers.
Dual-protocol architecture — REST API(the express part) handles the CRUD stuff (auth, fetching users, loading message history). WebSockets handle the real-time stuff (sending messages, live delivery). Each protocol does what it's good at and that is exactly what I wanted to learn to do myself. And also the fact that how would I implement both these protocols in the same project for maximum efficiency.

Architecture and Flow

The app follows a fairly standard real-time chat architecture with a clear separation between frontend and backend responsibilities.

On the frontend, the application is built using React, TypeScript, and Vite. Authentication state is managed through an AuthContext, chat history is handled using a useMessages hook, and real-time communication is managed by a useWebSocket hook. The frontend communicates with the backend in two ways:

REST API calls using Axios over HTTP for things like authentication, fetching users, loading messages, and logout.
WebSocket connections (ws://) for real-time messaging and live updates.

On the backend, the application uses Node.js with Express for REST APIs and the ws library for WebSocket support. The backend exposes REST routes such as /signup, /signin, /users, /messages, /me, and /logout. Alongside this, a WebSocket server handles persistent connections, live message delivery, and connection management.

Both the REST API layer and WebSocket server interact with the database through Prisma ORM, which connects to a PostgreSQL database for storing users, messages, authentication data, and related application state.

Now for the flow. This is the part I find most interesting. Here's what happens when you hit send:

Frontend calls sendMessage(to, content) which writes a JSON frame to the open WebSocket: { type: "send_message", payload: { to, content } }
Backend WS handler receives it, validates the payload, and does two things simultaneously:
- Persists the message to PostgreSQL via Prisma
- Looks up the recipient's socket in the in-memory connection store (which I will update to be a singleton SocketManager class instead of just a map)
If the recipient is online, the backend pushes the message to their socket as a receive_message event, they see it instantly
If they're offline, the message is still in the database. Next time they open the chat, the frontend fetches history via the REST endpoint /messages?userId=...
The sender gets an ack back over the WebSocket confirming the message was processed

No message broker, no queue, no Redis (yet, as that is the plan for v2). Just an in-memory Map<userId, WebSocket> and a database. It's simple, it works for a single server, and it's the kind of thing that makes you appreciate what a system like Kafka(v2.5 maybe?) is actually solving when you eventually need it.

Here are the interesting bits

All of these will be individual posts in the coming days.

1. Cookie auth over WebSockets

Auth over REST is easy, but how does it happen when dealing with persistent connections. WebSockets don't have a middleware chain and also have no authorization header during the upgrade handshake.
The solution - cookies!.

2. The React Stale Closure bug

Imagine opening a chat in two tabs, you receive a message from User A, but see it silently render in the chat window for User B. No backend errors, just a complete UI mismatch.

3. The dual protocol magic

How the HTTP and WS protocols interleave.

4. Raw WS

How you create every feature you need using raw WebSockets instead of Socket.io and have so much more understanding of the concepts.

Wrapping up

For those of you who would like to go through the codebase, you can do so here.
I'll be back with more next week. Until then, stay consistent!

I Built a Real-Time Chat App from scratch - Here's What I Learned

Nikhil Sharma — Tue, 26 May 2026 18:03:37 +0000

When dealing with WebSockets, most tutorials will straightaway hand you Socket.io and call it a day. You get a working chat app in short period of time but you have no idea what happened.

What Relay Does

Real-time messaging — Messages are sent and received instantly over WebSockets. No polling, no long-polling, no hacks.
Persistent history — Every message is stored in PostgreSQL via Prisma ORM. Close the tab, logout, the messages will still be there when you come back.
Cookie-based auth — JWT tokens stored in httpOnly cookies. The WebSocket handshake authenticates by manually parsing cookies from the upgrade request headers.
Dual-protocol architecture — REST API(the express part) handles the CRUD stuff (auth, fetching users, loading message history). WebSockets handle the real-time stuff (sending messages, live delivery). Each protocol does what it's good at and that is exactly what I wanted to learn to do myself. And also the fact that how would I implement both these protocols in the same project for maximum efficiency.

Architecture and Flow

The app follows a fairly standard real-time chat architecture with a clear separation between frontend and backend responsibilities.

REST API calls using Axios over HTTP for things like authentication, fetching users, loading messages, and logout.
WebSocket connections (ws://) for real-time messaging and live updates.

Now for the flow. This is the part I find most interesting. Here's what happens when you hit send:

Frontend calls sendMessage(to, content) which writes a JSON frame to the open WebSocket: { type: "send_message", payload: { to, content } }
Backend WS handler receives it, validates the payload, and does two things simultaneously:
- Persists the message to PostgreSQL via Prisma
- Looks up the recipient's socket in the in-memory connection store (which I will update to be a singleton SocketManager class instead of just a map)
If the recipient is online, the backend pushes the message to their socket as a receive_message event, they see it instantly
If they're offline, the message is still in the database. Next time they open the chat, the frontend fetches history via the REST endpoint /messages?userId=...
The sender gets an ack back over the WebSocket confirming the message was processed

Here are the interesting bits

All of these will be individual posts in the coming days.

1. Cookie auth over WebSockets

2. The React Stale Closure bug

Imagine opening a chat in two tabs, you receive a message from User A, but see it silently render in the chat window for User B. No backend errors, just a complete UI mismatch.

3. The dual protocol magic

How the HTTP and WS protocols interleave.

4. Raw WS

How you create every feature you need using raw WebSockets instead of Socket.io and have so much more understanding of the concepts.

Wrapping up

For those of you who would like to go through the codebase, you can do so here.
I'll be back with more next week. Until then, stay consistent!

Week 12: Typescript Magic!

Nikhil Sharma — Sun, 01 Feb 2026 17:11:40 +0000

Last week, we talked about how Prisma helps us in simplifying our DB queries, but as a project grows, we face another massive challenge: consistency. When you have dozens of files and data moving between them, it's very easy to lose track of what "shape" an object has.

In plain JavaScript, you might call a property user_id in your database logic, userId in your controller, and just id in your frontend. In a small project, you can keep that in your head. In a production-level app?

It’s a straight-up disaster waiting to happen. You won't know something is broken until the code actually runs and crashes with the dreaded Cannot read property 'id' of undefined.

The solution is TypeScript. It’s not just "JavaScript with types"; it’s a high-tech safety net. It creates a development environment where the editor itself understands your data structures. It ensures that if you change a property name in one place, the rest of your app doesn't quietly crumble—it screams at you until you fix it.

1a. Setting Up the Environment📎

Unlike JavaScript, which Node.js or a browser can read directly, TypeScript needs to be "transpiled." Think of it as a pre-processing step where your type-heavy TS code is stripped down into clean, performant JS that engines can actually execute. To get started, the setup involves a few key commands that I now have on muscle memory:

# Initialize a node project to manage dependencies
npm init -y

# Install TypeScript as a dev dependency (we don't need it in production)
npm install typescript --save-dev

# Initialize the TypeScript compiler and create the config
npx tsc --init

This generates a tsconfig.json file. This file is the "brain" of your project. It’s where you tell the compiler exactly how strict you want to be, which version of JavaScript to target, and where to look for your files.

1b. Organizing with rootDir and outDir

In a professional workflow, you never want your source code (the stuff you edit) and the distribution code (the stuff that runs) mixed together. It makes version control a nightmare and the project structure confusing.

To solve this, we dive into the tsconfig.json and configure two crucial settings:

rootDir: This points the compiler to our source folder. Usually, we set this to ./src. This is where all our .ts files live.
outDir: This tells the compiler where to dump the generated JavaScript. We usually use ./dist (distribution) or ./build.

By setting these up, your workflow becomes streamlined: you write code in src, run npx tsc, and TypeScript replicates your entire folder structure inside dist, but converted to JavaScript. This keeps your project clean and ready for deployment.

2. Beyond Basics: Interfaces, Enums, and Generics

A. The Power of Interfaces

Interfaces enforce a "contract." If a blueprint says a house needs four windows, TypeScript won't let you build it with three.

export interface User {
    id: string;
    username: string;
    email: string;
    role: UserRole; // Using an Enum
    tags?: string[]; // Optional property
}

B. Enums: Eliminating "Magic Strings"

Don't use strings like "admin" or "guest" throughout your code. Use Enums to create a single source of truth for constant values.

enum UserRole {
    Admin = "ADMIN",
    Moderator = "MODERATOR",
    User = "USER"
}

const myUser: User = {
    id: "1",
    username: "Nikhil_Dev",
    email: "nikhil@example.com",
    role: UserRole.Admin // Type-safe and discoverable
};

C. Generics: Writing Reusable Logic

Generics allow you to create components that work over a variety of types rather than a single one. This is crucial for API responses.

interface ApiResponse<T> {
    status: number;
    data: T;
    error?: string;
}

// Now we can reuse this for Users, Products, or Orders
const userResponse: ApiResponse<User> = {
    status: 200,
    data: myUser
};

3. End-to-End Type Safety (Frontend + Backend)

The "Holy Grail" of development is sharing types across your stack. By exporting interfaces from a shared folder, your Frontend knows exactly what the Backend is sending.

Shared Function Signatures

Imagine a function that updates a user profile. In TypeScript, we can ensure the payload matches the expected structure before the API call is even made.

type UpdateUserPayload = Pick<User, "username" | "tags">;

async function updateUser(id: string, payload: UpdateUserPayload): Promise<void> {
    // TypeScript ensures payload only contains username or tags
    await fetch(`/api/user/${id}`, {
        method: 'POST',
        body: JSON.stringify(payload)
    });
}

New things I learnt this week🔄

The Power of strict: true: Turning this on in tsconfig is like playing a game on "Hard Mode." It forces you to handle null and undefined cases explicitly. It’s annoying at first, but it eliminates about 90% of common runtime bugs.
Targeting Environments: I learned that I can write modern ES6+ TypeScript but tell the compiler to output older ES5 code if I need to support legacy environments.
Type Inference: I realized I don't have to define everything. If I write let name = "Nikhil", TypeScript is smart enough to know it's a string. You only need to be explicit when things get complex.

Wrapping up

While the topics that I covered this week were small, they are crucial and of immense importance when building production-ready apps. If you have any questions or feedback, make sure to comment and let me know!

I'll be back next week with more. Until then, stay consistent!

Week 11: Prisma!

Nikhil Sharma — Wed, 17 Dec 2025 04:57:00 +0000

This week I explored the Prisma ORM, which simplifies our SQL journey by a LOT. Let’s get right into it!

Topics Covered✅

Last week, I worked with basic schemas and simple database interactions. But once our data starts to grow and multiple entities are involved, raw SQL queries or loosely typed database access quickly become messy and error-prone.

That’s where Prisma comes in.

This week revolved around:

Understanding what an ORM actually solves
Defining a database schema using Prisma
Generating type-safe database clients
Performing CRUD operations cleanly and safely

1. What is Prisma and why do we need it? 🧠

Prisma is an ORM (Object Relational Mapper). In simple terms, it acts as a bridge between our database and our application code.

Without Prisma, we might write raw SQL like this:

SELECT * FROM users WHERE email = 'test@gmail.com';

With Prisma, the same thing looks like:

const user = await prisma.user.findUnique({
  where: { email: "test@gmail.com" }
});

Why this matters

We don’t manually write SQL for every operation
Queries become type-safe
Refactoring database fields doesn’t silently break things
Autocomplete + compile-time checks save us from runtime bugs

2. Prisma Schema — the single source of truth 📄

First we initialise Prisma in our project (for which you can refer to the docs here).
At the heart of all generated files lies the schema.prisma file. This file defines:

our database connection
our models (tables)
relationships between models

A basic example:

model User {
  id        Int      @id @default(autoincrement())
  email     String   @unique
  name      String?
  createdAt DateTime @default(now())
}

This schema:

Creates a User table
Automatically enforces uniqueness on email
Generates types that our editor understands

Once this is written, running:

npx prisma generate

creates a fully typed Prisma Client for us — which we can just import in our DB setup files and use as simply as this -

import { PrismaPg } from '@prisma/adapter-pg'
import { PrismaClient } from "@/app/generated/prisma/client";

const adapter = new PrismaPg({
  connectionString: process.env.DATABASE_URL,
})
const prisma = new PrismaClient({
  adapter,
});

3. Migrations — evolving the database safely 🔁

Databases are never static. Fields get added, removed, or changed. Prisma handles this through migrations.

Example:

npx prisma migrate dev --name add-user-model

What this does:

Creates a migration file
Applies changes to the database
Keeps history of schema evolution

This ensures our local DB, staging DB, and production DB all stay in sync. And the generated migration files are simply the SQL versions of the queries that we can write easily using Prisma.

4. CRUD operations with Prisma ✍️

Prisma makes CRUD operations intuitive and readable.

Create

await prisma.user.create({
  data: {
    email: "nikhil@gmail.com",
    name: "Nikhil"
  }
});

Read

const users = await prisma.user.findMany();

Update

await prisma.user.update({
  where: { id: 1 },
  data: { name: "Updated Name" }
});

Delete

await prisma.user.delete({
  where: { id: 1 }
});

Each of these operations is:

Typed
Validated at compile time
Predictable in behaviour

And to see what parameters these functions expect we can just refer to the docs.

5. Relations and foreign keys made simple 🔗

Defining relations in Prisma is surprisingly clean.

Example:

model User {
  id    Int    @id @default(autoincrement())
  posts Post[]
}

model Post {
  id     Int  @id @default(autoincrement())
  title  String
  user   User @relation(fields: [userId], references: [id])
  userId Int
}

Now Prisma understands:

One user → many posts
How to join data internally
How to fetch nested data safely

Fetching related data:

const user = await prisma.user.findUnique({
  where: { id: 1 },
  include: { posts: true }
});

New things I learnt this week 🔄

Prisma acts as an intermediary between our code and database - increasing our ease while also giving type safety, which is an absolute game changer.
Schema-first design prevents an entire class of bugs

Wrapping up

While Prisma might feel like “just another tool”, it fundamentally changes how confidently we interact with our database. Clean schemas and safe migrations make production systems far more reliable.

If you have any questions or feedback, make sure to comment and let me know! Also, if you have any project ideas for me, please drop em in the comments!

I’ll be back next week with more. Until then, stay consistent!

Week 10: Databases - The Real Backbone of Our Apps!

Nikhil Sharma — Mon, 08 Dec 2025 18:14:30 +0000

This week, I went deeper into something that quietly run the entire show behind our apps - databases.

Honestly, this was one of those weeks where everything just clicked. The more I understood, the more things felt structured and “ohhh, so that's how it's done.” Let’s get right into it!

🗂️ Types of Databases

At the highest level, we can split databases into two big families:

1. SQL Databases (Relational)

These are structured, rigid, strict but all in a good way.

Data lives in tables
Tables have columns with fixed types
There are relationships between tables
Everything is based on a schema we define upfront
We interact using SQL (Structured Query Language)

Examples: PostgreSQL, MySQL, MariaDB, SQL Server

2. NoSQL Databases (Non-Relational)

These are way more flexible and relaxed with structure.

No fixed schema
Great for rapidly changing data
Designed for quick reads, massive scale
Data can be documents, key-value pairs, graphs, columns…

Examples: MongoDB, Redis, Cassandra, DynamoDB

Where MongoDB Fits

MongoDB is a NoSQL Document Database.

Instead of rows and columns, MongoDB stores data as documents that look like JSON.

A user record might look like this:

{
  "name": "Ayu",
  "age": 20,
  "hobbies": ["painting", "reading"]
}

This is super flexible! We can add or remove fields anytime and get no schema alerts.

MongoDB Advantages

MongoDB does a bunch of things really well:

Schema flexibility - perfect for fast prototyping
Horizontal scaling - adding more servers is easier
Great for document-shaped data
Works naturally with JavaScript since it uses JSON-like syntax
High read performance when queries align with document structure

When we want speed and flexibility(say in a hackathon), MongoDB feels amazing.

But MongoDB Has Its Downsides Too

As we scale, we start to notice some cracks:

Relationships are painful Joining data across collections feels messy.
Data integrity isn’t guaranteed by default If we expect strict correctness → things get tricky.
Query patterns can degrade performance Indexing becomes super important and manually tuned.
Harder to enforce structure Which means bugs can slip into the data layer.

MongoDB is perfect until we need the kind of discipline that big systems demand.

🧠 Why Most Companies Still Prefer SQL

Across the industry, SQL remains the default, and once we dig into it, the reasons feel obvious.

SQL databases like Postgres give us:

Structure
Predictability
Reliability
Better Relationships
ACID guarantees
Rich querying capabilities

When correctness matters, SQL usually wins.

Say in payments, inventory, authentication, banking, analytics, logistics and so many more. Basically anything where one mistake can cause a lot of trouble, SQL wins.

Why SQL (especially Postgres) feels better for many use cases:

Every table has a schema → fewer “surprise bugs”
Strong JOIN support → complex relationships are easy
Transactions → either everything succeeds or nothing does
Indices, constraints, triggers → very mature tooling
Postgres-specific power-ups:
- JSON support (best of both worlds)
- Window functions
- Full-text search
- Extensions like pgvector, PostGIS

Postgres feels like that reliable friend who just never drops the ball.

⚠️ But SQL Has Some Cons Too

Nothing is perfect.

Schema changes can be heavy
Horizontal scaling is harder
Rigid structure might feel slow during rapid iteration
Requires more planning upfront

Still, for most of the systems we want to build, SQL’s strengths massively outweigh its weaknesses.

🐘 Our Choice This Week: PostgreSQL

So this week was all about Postgres, one of the most powerful SQL databases out there.

We focused on understanding:

How tables are created
How constraints keep our data safe
How relationships work using foreign keys
How SQL queries are structured
Why good database design matters

And since we’re building in the JavaScript ecosystem, we’ll be pairing Postgres with Prisma as our ORM but that’s a whole topic by itself, so that’s coming next week.

This week is pure SQL.

SQL Examples — With Intuition

▶ Creating a Table

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  email TEXT UNIQUE NOT NULL
);

What’s happening?

We’re designing a structure where:

id auto-increments
name must always exist
email must be unique
Postgres will now enforce these rules for us

This is the kind of discipline that NoSQL doesn’t enforce.

▶ Inserting Data

INSERT INTO users (name, email)
VALUES ('Ayu', 'ayu@example.com');

This just means:

“Put a new row into the users table with these values.”

SQL has a learning curve which could be slow in the beginning but, as is the case with everything, gets easier with practice.

▶ Querying Data

SELECT * FROM users WHERE email = 'ayu@example.com';

We’re pulling only the data that matters.

This precision is where SQL shines.

▶ Updating Data

UPDATE users
SET name = 'Ayu'
WHERE id = 1;

We’re telling Postgres:

“Find the row where id = 1”
“Change the name to Ayu”

▶ Deleting Data

DELETE FROM users WHERE id = 1;

Again - clean and readable(because our use-case is simple – SQL queries can get very complex, but an ORM helps simplify it further).

Wrapping Up

This week gave us a solid foundation in understanding why databases behave the way they do, and why SQL (especially Postgres) is still the king for most real-world applications. MongoDB is incredible for flexibility and fast-moving projects but SQL is unbeatable for consistency and correctness.

Next week, we’ll take all this knowledge and plug it into Prisma, making database interactions feel a LOT easier.

If you have any questions or feedback, make sure to comment and let me know!

I'll be back next week with more. Until then, stay consistent!

Week 9: Using Recoil in React!

Nikhil Sharma — Mon, 01 Dec 2025 18:28:41 +0000

Back after 2 weeks of vacation!(it was actually a continuous battle with so many evaluations and exams at college). During this time I've been covering State Management with context API and Recoil! Let's get right into it!

Topics Covered✅

Context API
Problems with Context API
Recoil and why it's better
Atoms & Selectors
Recoil hooks (useRecoilState, useRecoilValue, useSetRecoilState)
Using RecoilRoot
When to still use useState

1. Starting with the Context API 🧩

Last week, we spoke about prop drilling and how passing props through multiple layers can make your code look messy. The Context API is React’s built-in solution to this.

It lets you create global-ish state without prop drilling.

Here’s a tiny example:

// UserContext.jsx
import { createContext } from "react";

export const UserContext = createContext(null);
// App.jsx
import React, { useState } from "react";
import { UserContext } from "./UserContext";

function App() {
  const [user, setUser] = useState("Nikhil");

  return (
    <UserContext.Provider value={{ user, setUser }}>
      <Parent />
    </UserContext.Provider>
  );
}

export default App;
// Child.jsx
import { useContext } from "react";
import { UserContext } from "./UserContext";

function Child() {
  const { user } = useContext(UserContext);

  return <h2>Hello, {user}!</h2>;
}

export default Child;

This appears to work well. But it does so only for small and simple apps.

2. The problem? 😵‍💫

As our app grows, Context API introduces a few issues:

1. Re-renders

Any value change in the context re-renders every component that consumes it, even if only one component actually needed the update.

2. Too many contexts

You often end up creating multiple contexts:

UserContext
ThemeContext
NotificationContext

and so on.

This becomes hard to organise and maintain.

3. Not a full state management solution

Context wasn't designed for big, complex global state. It's more of a “prop drilling escape hatch”.

3. Recoil ⚛️ - The solution

Recoil is a super-lightweight state management library made for React. It fixes the problems above without introducing the complexity of Redux.

Why Recoil feels so good:

It updates only the components that need the state.
You don’t need multiple providers — everything sits under one RecoilRoot.
It’s extremely intuitive because it feels like working with React’s useState.
Recoil introduces atoms, which are simply pieces of global state.

4. Getting started with Recoil

Step 1: Wrap your app in a RecoilRoot

// index.jsx
import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App";
import { RecoilRoot } from "recoil";

ReactDOM.createRoot(document.getElementById("root")).render(
    <RecoilRoot>
    <App />
  </RecoilRoot>
);

Step 2:Creating an atom

Atoms store global state. We usually create them in a separate folder and export them from there and then we can use them globally.

// atoms/userAtom.jsx
import { atom } from "recoil";

export const userAtom = atom({
    key: "userAtom",
  default: "Nikhil",
});

Step 3:Using the globally declared states in Components

For this we use majorly three functions

useRecoilState → like useState but global

import { useRecoilState } from "recoil";
import { userAtom } from "./atoms/userAtom";

function UserUpdater() {
  const [user, setUser] = useRecoilState(userAtom);

  return (
    <button onClick={() => setUser("Ayu")}>
      Change User
    </button>
  );
}

useRecoilValue → read-only access- so it basically just gives us the variable and not the function to change its value.

import { useRecoilValue } from "recoil";
import { userAtom } from "./atoms/userAtom";

function UserDisplay() {
  const user = useRecoilValue(userAtom);
  return <h2>Hello, {user}!</h2>;
}

useSetRecoilState → write-only access

import { useSetRecoilState } from "recoil";
import { userAtom } from "./atoms/userAtom";

function LogoutButton() {
  const setUser = useSetRecoilState(userAtom);

  return <button onClick={() => setUser(null)}>Logout</button>;
}

Selectors -

Selectors let you derive data from atoms, say computed values. This is how we'd create one.

import { selector } from "recoil";
import { userAtom } from "./userAtom";

export const capitalisedUserSelector = selector({
  key: "capitalisedUserSelector",
  get: ({ get }) => {
    const user = get(userAtom);
    return user.toUpperCase();
  }
});

And to use it we do this-

import { useRecoilValue } from "recoil";
import { capitalisedUserSelector } from "./atoms/selectors";

function Display() {
  const name = useRecoilValue(capitalisedUserSelector);
  return <h3>{name}</h3>;
}

5. Should we ditch useState now?

Not at all.
If a state variable is only needed by 1–2 components, using Recoil is unnecessary.

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <>
      <p>{count}</p>
      <button onClick={() => setCount(count + 1)}>+</button>
    </>
  );
}

No reason to make count global here. React’s local state is still perfect for component-specific logic.
We use Recoil only when:

Many components need the same state
Passing props becomes painful
Context starts slowing down your UI ## Things I found interesting this week
Seeing how Recoil prevents unnecessary re-renders felt magical. The component isolation makes the app feel snappier.
Atoms being global state and also visually being "global state" made the learning curve super smooth for me. ## Wrapping up🔄 Interesting week.

Note: While learning Recoil this week, I actually didn’t know that the library had been archived. Since I had already started, I went ahead and completed it anyway — the concepts are super useful to understand. I’ll be moving to Jotai soon since it’s lightweight, actively maintained, and follows a similar mental model to Recoil, so the transition should feel smooth.

If you have any questions or feedback, make sure to comment and let me know!

I'll be back next week with more. Until then, stay consistent!

Vacation week!

Nikhil Sharma — Mon, 17 Nov 2025 16:39:25 +0000

This week wasn’t about new concepts or heavy learning.
Exams are around the corner, I’ve been traveling back and forth between home and college, and it was also the birthday of someone very close to me. So life was a little full in the best ways.

So this became a vacation week. A breather I honestly needed.

I'll be back with more next week! Till then, stay consistent.