DEV Community: Nikhil Sharma

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.

Week 8: Routing, Lazy Loading and more in React!🎨

Nikhil Sharma — Mon, 10 Nov 2025 18:00:04 +0000

This week I delved into an absolute essential for building a web application! Client-side routing and lazy loading. Let's get right into it!

Topics Covered✅

Client-side routing
Lazy-loading
Prop-drilling and its solutions

1. Routing📎

Routing is one of the first things that I'd do if I was in a hackathon and needed to get a project up and running quickly.

React enables us to build single-page applications (SPAs), where navigating between pages doesn’t trigger a full page reload. Instead of reloading the entire site and fetching a new HTML file each time, React uses client-side routing. This means the app dynamically updates the content and changes the URL without requesting a new page from the server.

This approach makes navigation faster and smoother, since the JavaScript bundle is loaded only once, and React handles rendering the appropriate components for each route.

This is how we'd change the route in a very superficial way

import React from "react";

function Home() {
  const goToAbout = () => {
    // This causes a full page reload instead of client-side routing
    window.location.href = "/about";
  };

  return (
    <div>
      <h1>Welcome to Home Page</h1>
      <button onClick={goToAbout}>Go to About</button>
    </div>
  );
}

export default Home;

But you'll notice that here too , the page hard reloads. To avoid this, we use a library that helps in routing — 'react-router-dom'. Here is how we'd use that to do the same routing as above

import React from "react";
import { useNavigate } from "react-router-dom";

function Home() {
  const navigate = useNavigate();

  const goToAbout = () => {
    // This changes route without reloading the page
    navigate("/about");
  };

  return (
    <div>
      <h1>Welcome to Home Page</h1>
      <button onClick={goToAbout}>Go to About</button>
    </div>
  );
}
export default Home;

But there's a little caveat that comes with the useNavigate()hook we use here. It can only be used inside components that are wrapped by a Router. This means that for the useNavigate hook to work, the component must be rendered within a Router context provided by react-router-dom.
This is how our App() function should look for the above to work-

import React from "react";
import { BrowserRouter, Routes, Route } from "react-router-dom";
import Home from "./Home";
import About from "./About";

function App() {
  return (
    //  useNavigate works only inside components wrapped by a Router
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/about" element={<About />} />
      </Routes>
    </BrowserRouter>
  );
}

export default App;

This stops the page from hard reloading and instead does client-side routing! This is crucial for building fast web applications.

2. Lazy loading 💤

Another thing we can do to optimise the user's experience is to add lazy-loading to our application. But that is truly useful only if our application has grown large enough.

But below is an example of how to do it.

import React, { Suspense } from "react";
import { BrowserRouter, Routes, Route } from "react-router-dom";

// Lazy load the About component
const About = React.lazy(() => import("./About"));
import Home from "./Home";

function App() {
  return (
    <BrowserRouter>
      {/* Suspense shows fallback while About is being loaded */}
      <Suspense fallback={<div>Loading...</div>}>
        <Routes>
          <Route path="/" element={<Home />} />
          <Route path="/about" element={<About />} />
        </Routes>
      </Suspense>
    </BrowserRouter>
  );
}

export default App;

Notice here that we have to use the Suspense API along with lazy loading else React throws us an error. What this API does is that it allows us to add a "fallback" in case the user's network is too slow and the component cannot load in time.

Another benefit for lazy loading is that it reduces the initial bundle size of our application, leading to faster load times and improved performance, especially for users with slower internet connections.

3. Prop Drilling

In one of the earlier blog posts, when we read about various app optimisation techniques and the need to lower our re-renders we studied how we should push down state to the lowest common ancestors of the nodes that need those state variables.

But this could still lead to scenarios where the state variable is being passed down through multiple components that don't need the variables for themselves but still have to pass it down. This leads to code that can look very unappealing and overtime become difficult to manage.

This visually and syntactically bad looking problem is what we call Prop Drilling. Note that prop drilling doesn't have much to do with performance issues as much as it is about the visual and structural complexity it causes.

Below is a small example of prop drilling-

import React from "react";

function App() {
  const user = "Nikhil";
  return <Parent user={user} />;
}

function Parent({ user }) {
  //Parent doesn't need 'user', but passes it down anyway
  return <Child user={user} />;
}

function Child({ user }) {
  return <GrandChild user={user} />;
}

function GrandChild({ user }) {
  return <h2>Hello, {user}!</h2>;
}

export default App;

Observe here how the user prop travels through multiple components (Parent, Child) that don’t actually need it — they just pass it along so GrandChild can use it. This is prop drilling.

The solution -

The solution, as we discussed earlier, is to somehow move all of the state logic outside the components, so that they exist globally. That way, any component that needs it can just call it and use it without it being needed to passed down.

We can do this using two things-

The Context API which is built into React but has its limitations like-
- It can lead to unnecessary re-renders if not used carefully.
- It is not a full-fledged state management solution and may not be suitable for very complex state management needs.
A state management library like RTK(redux tool kit), Recoil(now archived) or some lightweight library built on principles of Recoil, like Jotai or Zustand. These libraries provide more robust solutions for managing global state in larger applications.

We cover both of these topics in the next blog together!

Things I found interesting this week

Lazy loading was such a cool concept! Seeing the components load one-by-one in the networks tab was really interesting.
Client-side-routing really tickled a corner of my brain that I did not know wanted to be tickled. Taught me how the URL change in the search bar when we click on different links on a site.

Wrapping up🔄

Another week gone and some more fundamentals mastered. Really interested to do a state-management library next week. 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 7: React hooks and more!

Nikhil Sharma — Mon, 03 Nov 2025 18:25:04 +0000

This week was very light. I did not cover anything that was too new or too hard because I needed a break and also wanted to stay in touch! So let's get right into it.

Topics Covered✅

React returns- the need to return just one parent component
Re-Renders and minimising them
Keys in React
Wrapper components and children
Hooks
React.memo

Let's get into them in detail.

1. React Returns

If you notice that when we try to return sibling components out of a React component, React screams a huge NO. This is because React components must return a single root element. Returning multiple sibling elements isn’t allowed because each component needs one clear root in the virtual DOM tree. This structure enables React’s reconciliation process to work efficiently.

2. Re-Renders and minimising them

A re-render in React happens when a component’s output (its JSX) is recalculated, and React determines whether the DOM needs to be updated or not. Unnecessary or frequent re-renders can impact performance if not managed properly, thus, we need to minimise them.

If a parent component re-renders then all its child components re-render along with it. One way to optimise re-renders is to push down state into the lowest common ancestor of the nodes(or components) which need the state. We can also use something called React.memo which we will cover later in this blog.

Realistically, we would do this by pushing all state outside our core logic and using a state-management tool like Recoil(archived), RTK(Redux Toolkit) or something light like Jotai or Zustand.

3. Keys in React

Whenever we render something in react which is a list of items like we did in our last blog.

export function Todos({todos , setTodos}){
    return <div>
        {todos.map((todo)=>{
            return <div key={todo.id}>
               <h1>{todo.title}</h1>
               <h1>{todo.description}</h1>
               {todo.completed?<span>Completed</span>:<button onClick={()=>{
                handleCompleted(todo._id,todos ,setTodos);
               }}>Mark as done</button>}
                </div>
        })}
    </div>
}

Here, React gives a soft warning when in StrictMode which says -
"Warning: Each child in an array or iterator should have a unique "key" prop. Check the render method of TodoList. See fb.me/react-warning-keys for more information."

What this means is that React needs some sort of a key to recognise which item in the list is being manipulated, deleted, moved around or anything of the sorts.

We can do this by adding a key prop to each todo as follows

return <div key={todo._id}> // parent div

4. Wrapper Components and children

Wrapper components come in handy when we want uniformity across components written by different people working on a project. In such cases, one person can define a wrapper component that handles common structure, styling, or logic. Other developers can then pass their component content as children to this wrapper.

An example of this is as follows-

function Card({ children }) {
  return <div className="card">{children}</div>;
}

// Usage
<Card>
  <h2>Title</h2>
  <p>This is inside the card!</p>
</Card>

5. React.memo

React.memo is a higher-order component that helps optimize performance by preventing unnecessary re-renders of functional components.

When you wrap a component with React.memo, React will only re-render it if its props change. If the props remain the same between renders, React skips rendering that component and reuses the previous result.

const TodoItem = React.memo(function TodoItem({ title, description }) {
  console.log("Rendered:", title);
  return (
    <div>
      <h1>{title}</h1>
      <p>{description}</p>
    </div>
  );
});

If the parent component re-renders but the props (title, description) for a particular TodoItem stay the same, that TodoItem won’t re-render and this saves computation time.

This is especially useful when you have large lists or expensive UI components that don’t need to update unless their data actually changes. But again this will be handled even better when we use a state-management library.

6. Hooks

While we did use some hooks like useState and useEffect in last week's project, this was more of an official definition. Hooks are functions that allow us to hook into react state and lifecycle features from functional components. And while there are a lot of hooks, only a handful are used in most code bases.

Wrapping up🔚

While this week was more theoretical and very light, it does set up some paths that will be very interesting in the upcoming weeks. Especially the state-management part is quite interesting. Some very intriguing stuff coming in the next weeks. 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!