Forem: Nikhil Sharma

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!

Week 6: Understanding React through a project🎨

Nikhil Sharma — Mon, 27 Oct 2025 18:30:34 +0000

This week I decided to go deeper into React with a small project. The knowledge required to do this was not vast by any means, but it was nice to move away from snippets and theory to do something more practical. While the project was technically full stack, in this post I'll be delving primarily into the frontend. For the backend, you can see the full code on my GitHub here. Let's get right into it.

The Project - a very basic todo application✅

The project was a simple todo application that consisted of both a backend and a frontend.

The backend 🌐

The backend had the following endpoints-

POST /todos - allows the user to add a todo. The zod schema for this was

const createTodo = z.object({
  title: z.string(),
  description: z.string()
});

GET /todos - allows the user to get all their existing todos.
PUT /completed - allows the user to update an existing todo and mark it as done. The zod schema for this was -

const updateTodo = z.object({
  id: z.string(),
});

As I already said, the backend is quite simple and we've already covered these topics in our previous blogs, but you can get the full code at my GitHub. Let's get into the frontend now!

The frontend 💡

Now this bit is interesting(gotten a little bored with the backend:). I initialised an empty vite project, cleared the boilerplate code and setup the App.jsx to have only a couple of things — the rest of the stuff would be structured away neatly for modularity and readability.
In the App.jsx I declared my todos as a state variable which would be updated everytime the site re-renders(when a new todo is added or an existing todo is marked as done). For the first render, we would use the useEffect hook to update todos.

The useEffect hook🪝 -

Let's see the syntax first.

  useEffect(() => {
    fetch("http://localhost:3000/todos")
      .then(async (res) => {
        const json = await res.json();
        setTodos(json.todos);
      });
  }, []);

This makes it so that what's written in the function executes only when the React app mounts(or on specified conditions — we'll see that soon). This gives us great control over how many fetch requests we send out and on which re-renders the request runs.

This is controlled through the second argument in the useEffect hook which is called the dependency array. This array is where we pass in the dependencies which decide when the function in the first argument runs.

For eg. say I add a state variable 'a' to this dependency array. Then whenever 'a' updates, the first function runs. If we leave the dependency array empty then it gives the desired result in our case, which is the fetch request going out only on the app mount.

A couple of things to note here🚨-

We can't make the function in the first argument async. This is because useEffect hook expects the first argument to be a function that returns either nothing or a cleanup function. But an async function always returns a promise.
We should not put a state variable in the dependency array that is being updated in the function in the first argument as this would trigger an infinite loop.

The next part in the App.jsx was that it would return a div which would have two components as follows -

return (
<div>
  <CreateTodo setTodos={setTodos} />
  <Todos todos={todos} setTodos={setTodos} />
</div>
)

Let's delve into the components-

1. CreateTodo

I created the file 'CreateTodo.jsx' in the components folder in the src folder.
This was a relatively simple component which just returned a div with the input fields necessary to add a new todo.

import { useState } from "react";
export function CreateTodo({setTodos}) {
    const [title, setTitle] = useState("");
    const [description, setDescription] = useState("");
    return (<div>
        <input type="text" placeholder="Title" onChange={(e) => {
            const value = e.target.value;
            setTitle(value);
        }}></input><br />
        <input type="text" placeholder="Description" onChange={(e) => {
            const value = e.target.value;
            setDescription(value);
        }}></input><br />
        <button onClick={() => {
            fetch("http://localhost:3000/todos", {
                method: "POST",
                headers: {
                    "Content-Type": "application/json"
                },
                body: JSON.stringify({
                    title: title,
                    description: description
                })

            }).then(async (res) => {
                fetch("http://localhost:3000/todos")
                    .then(async (res) => {
                        const json = await res.json();
                        setTodos(json.todos);
                    });
            });
        }}>Add a todo</button>
    </div>);
}

Now this may seem jarring at first, but let's break it down.

We have two state variables for each of the input fields which update whenever the user types in them. These are used to send the backend calls necessary to add a new todo.
The button which has a pretty big onClick function which does two things. Firstly, it sends the POST request to add a new todo. You can see the syntax above to send the body with the request. After this, it asynchronously sends another request to GET the newly updated todos from the backend and updates the todos state variable. This causes a re-render in the <Todos> component and updates the displayed todos.

2. Todos

This is the component-

export function Todos({todos , setTodos}){
    return <div>
        {todos.map((todo)=>{
            return <div>
               <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>
}

This is pretty simple and a very good use-case of the map method. It simply maps all the todos in the variable to be displayed individually in divs on the screen.

The main magic here is in the handleCompleted function.

function handleCompleted(id,todos,setTodos){
    fetch("http://localhost:3000/completed",{
        method:"PUT",
        headers:{
            "Content-Type":"application/json"
        },
        body: JSON.stringify({
            id
        })
    })
    .then (async(res)=>{
        const modifiedTodo = await res.json();
        const newTodos = todos.map((t) =>
        t._id === modifiedTodo.updatedTodo._id ? modifiedTodo.updatedTodo : t
      );

      setTodos(newTodos);
    })
}

This sends the PUT request to the endpoint to update the todo to mark it as done. Then it updates the todos to include the new updated todo instead of the old one (very good use-case of the ternary operator).

Some new things I learned🧨

The useEffect hook - nature of its two arguments!
How these backend calls do not actually hit the backend unless we include "CORS" in the backend which enables the backend to be hit from any URL.
The syntax of sending these requests can seem a bit verbose and jarring but we simplify it by using the Axios library which we will study soon!

Wrapping up🔚

The practicality of this week's assignment kept me hooked. Now that we have some more understanding of React, we dive deeper into React next week. Some more hooks and smaller topics. 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 5: Dipping into React🎨

Nikhil Sharma — Mon, 20 Oct 2025 17:06:33 +0000

This week, I took my first steps towards learning React! For now it was all about learning about state, hooks and most importantly, getting familiar with the syntax. Let's get right into it!

Topics Covered✅

The volume of topics I covered this week was modest, and the individual topics were pretty simple once I had dedicated some time to them. Here's a list of the topics I covered:

Basic File structure in the vite repository
useState hook
Components and props
Hooks vs side-effects

As usual, these topics were discovered slowly through assignments (and also with some help from the React docs).

Creating my first React app and learning about useState🚀

I used Vite to create my React app. For that, all I had to do was run

npm create vite@latest

in the terminal and then follow the steps on screen.

Everything I have to deal with for now is in the src folder.
I emptied out the two default css files and went straight to mess with the App.jsx file.

I then replaced the boilerplate code there with this-

import { useState } from 'react'

function App() {
  const [count,setCount] = useState(0);
  function onClickHandler(){
    // count++; not the right way to set state variables
    setCount(count+1);
  }

  return (
      <div>
        <button onClick={onClickHandler}>Counter {count}</button>
      </div>    
  )
}

export default App

And that, was my first React app.
Now I'm aware that this is as simple as it gets, but we all start somewhere right? This helped me learn about the useState hook.

This hook returns us a variable which is a state variable and a function that updates the state variable. We can give it a default value by specifying it in the brackets.

Something that was a bit strange to me here was how the App function returns a div. Initially, I thought I was returning plain HTML here, but it was actually JSX — a JavaScript syntax extension that looks like HTML but lets you embed JS expressions inside curly braces leading to some very interesting use-cases.

Components and props💡

Then I learned how it was better to have all the different parts of my React App as separate components.

A component is basically just a function that you declare with a capital first letter. We can use this name as a tag and pass in whatever parameters the function requires as props.

import { useState } from 'react'

function App() {

  const [count,setCount] = useState(0);
  return (
      <div>
        <CustomButton count={count} setCount={setCount}/>
      </div>    
  )
}
//component
function CustomButton(props){
  function onClickHandler(){
    props.setCount(props.count+1);
  }
  return <button onClick={onClickHandler}>Counter {props.count}</button>
}

export default App

Here is the exact same app as before, but this has the button as a separate component in the same file named as CustomButton. We pass down both count and setCount to the component with the shown syntax. We can then access all passed parameters which we get as an object called props. Thus we change the onClickHandler to use 'props.count' and 'props.setCount()'.

Structuring our app as a bunch of separate components just helps in code readability and modularity.

New things I learnt this week🔄

Structure of a React app
Hooks - just inbuilt React functions with special purposes
Using the useState hook
Object Destructuring - This is one I found very interesting.

When we pass down props to a component, we don't necessarily need to use the 'props.' syntax. Instead, we can destructure the props object to individually use all props. The syntax is as follows -

  function CustomButton({ count , setCount }){
  function onClickHandler(){
    setCount(count+1);
  }
  return 
  <button onClick={onClickHandler}>Counter {count}</button>
  }

This feels a bit cleaner to me. And we can destructure any object – not just the props object.

Wrapping up🔚

This week felt very fresh. A change of topics can do a lot to re-ignite interest. I'll cover some leftover topics I studied later on. Next week, we dive deeper into React with a project. 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 4: The Why and How of React 💡

Nikhil Sharma — Mon, 13 Oct 2025 18:25:13 +0000

Now to freshen myself up, I have decided to delve into some frontend for the next few weeks. Hence, this week I understood the Why and How of React. Let's get right into it!

Topics Covered✅

This week I covered a few things, some small individual topics but majorly I wanted to cover some React to change my flow up a little. But for that, I first had to know why do we need React at all? And secondly, how does React do what it does?

The things that I learned about this week were as follows-

Connecting a frontend to a backend
Debouncing & Throttling
The need for React

1. Connecting a frontend to a backend📎

I was surprised that I hadn't thought about this thus far. But once I learned about it, it felt so intuitive. The way you connect a back-end to a front-end is rather simple.

You just put different fetch calls in you front-end code to the different endpoints in your back-end code. To test this locally, I would just host the back-end on a terminal with Express.js and open my index.html file.

It was such a simple concept, yet surprisingly fascinating.

2. Debouncing & Throttling

These are two important performance optimization techniques. Both are ways to control how often a function runs, especially when triggered by continuous user actions like typing, scrolling, or resizing.

Debouncing ensures that a function executes only after a certain period of inactivity. For example, when a user types in a search bar, the API call will fire only after they stop typing for a moment instead of on every keystroke.

This is how I coded a very raw debouncing function-

    let timeout;
        function debounced(){
            clearTimeout(timeout);
             timeout = setTimeout(() => {
                calcSum();
            }, 1000);            
        }

I found this very interesting. What I am doing here is that, I declared a timeout variable which is supposed to hold the ID of the setTimeout that we use to measure the time between two requests.

If we get a request, setTimeout is used and the timeout variable gets its ID. If we do not get any more requests for the next 1 second, then the calcSum() function is called and the program continues. However, if we do get another request in 1 second, then the clearTimeout function is called and the fetch request(or the function call in this case) is not sent.

Throttling, on the other hand, ensures that a function runs at most once in a specified time interval, no matter how many times the event is triggered.

I found this interesting because, unlike debouncing, throttling doesn’t wait for inactivity — it ensures regular execution at a controlled pace. This is super useful for things like scroll listeners, mouse movements, or window resize events, where you want frequent updates but don’t want your function to fire hundreds of times per second.

3. The need for React

To realise the importance of React, let's consider a small project.

Say we have a simple todo project. The user can add todos which update on the screen and they can also mark todos as done. Say we just store the todos in a simple local variable for now, which we call the state variable. Every time the user adds a new todo, we add it to the state variable and then update the state variable on the DOM.

A more optimal way to do this would be to calculate the diff between the current state variable and the previous state variable and then just changing that on the DOM.

 <div id="todo-list"></div>
<input type="text" id="todo-input" placeholder="Add todo"/>
<button id="add-btn">Add</button>

<script>
let state = [];
let prevState = [];

const todoList = document.getElementById('todo-list');
const input = document.getElementById('todo-input');
const addBtn = document.getElementById('add-btn');

function renderDiff() {
  // Simple diff: find new todos
  const newTodos = state.filter(todo => !prevState.includes(todo));

  newTodos.forEach(todo => {
    const li = document.createElement('div');
    li.textContent = todo;
    todoList.appendChild(li);
  });

  // Update prevState
  prevState = [...state];
}

addBtn.addEventListener('click', () => {
  const todo = input.value.trim();
  if (todo) {
    state.push(todo);
    renderDiff(); // only adds new items to the DOM
    input.value = '';
  }
});
</script>

Imagine scaling this up, where we have tens of such state variables for different DOM elements.
Then this diff calculation gets quite DSA heavy and can get very complicated. That is where React comes in. React basically calculates that diff for us under the hood very easily by maintaining a virtual DOM and thus, the code is simplified as follows.

 import React, { useState } from 'react';

function TodoApp() {
  const [todos, setTodos] = useState([]);
  const [input, setInput] = useState('');

  const addTodo = () => {
    if (input.trim()) {
      setTodos([...todos, input]);
      setInput('');
    }
  };

  return (
    <div>
      <input
        value={input}
        onChange={(e) => setInput(e.target.value)}
        placeholder="Add todo"
      />
      <button onClick={addTodo}>Add</button>

      <div>
        {todos.map((todo, index) => (
          <div key={index}>{todo}</div>
        ))}
      </div>
    </div>
  );
}

export default TodoApp;

I will be getting more into the details of this code when I delve deeper into it next week! For now, this is where I decided to stop.

New things I learnt this week🔄

Debouncing and Throttling for performance optimisation.
What React does under the hood! ## Wrapping up! The volume of content I covered this week might have been lesser than the average week, but the topics I covered were very interesting to me, which is also important if we wish to stay consistent. 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 3: Mongoose and the Basics of JWT Authentication

Nikhil Sharma — Mon, 06 Oct 2025 17:12:00 +0000

Another week gone, and another set of basics covered. Let's get right into it!

Topics Covered✅

This week was all about further cementing down my fundamentals. So this week we covered the heart of any full-stack web application that is made to cater hundreds, if not hundreds of thousands of people – Databases and Authentication.

If our application intends to have multiple users, then it will need two things-

A database - that stores all the data pertaining to different users in a sorted manner.
Authentication - that helps you verify your users.

And as usual, I discovered these topics by the means of an assignment.

The assignment was pretty simple. It was to create a backend and connect it to a database and perform basic CRUD actions on different users.

Mongoose and JWT📎

For now, I went with MongoDB as my database, which is a noSQL database. I made a free instance, connected it with my backend.Then, I defined a User schema which was as follows.

const User = mongoose.model("User", {
  name: String,
  password: String,
  email : String
});

This is quite a primitive example of a schema. It can be made as simple or complex as required.
Then made a couple of endpoints.

POST '/signup' - which would allow a new user to sign up to the application. This first checks if the submitted username already exists in the database and depending upon that it adds the user to the database. This is what the code looks like-
```
if (existingUser) {
return res.status(400).send("user already exists");
}
const user = new User({
name: username,
email: emailofUser,
password: password,
});
user.save().then(() => res.json({ msg: "User added to database" }));
```
POST '/signin' - This would allow an existing user to sign in. By that I mean if the user does exist in the DB then it would return a signed JWT token back to the user which could be used for all future requests.
```
var token = jwt.sign({ username: username }, jwtPassword);
return res.json({
token,
});
```
Here jwt.sign() uses the password(which is usually top secret) to sign the username and returns the token to the user. We use jwt.sign() instead of jwt.encode() - encode just converts it into a string that can be openly decoded back to the original string whereas sign converts it into a string and also marks it with the password we give. The difference will be clearer once we cover the other endpoints.
GET '/users' - Verifies the signed in user through the earlier returned token and then returns a list of all other users.
```
const token = req.headers.authorization;
try {
const decoded = jwt.verify(token, jwtPassword);
const username = decoded.username;
// return a list of users other than this username from the database
const users = await User.find({ name: { $ne: username } });
res.json(users);
} catch (err) {
return res.status(403).json({
  msg: "Invalid token",
});
}
```
Couple of things to note here-
- We wrap this in a try-catch block because if jwt.verify() fails then it throws an error.
- We use jwt.verify() instead of jwt.decode(). The jwt token can be decoded by anyone, but verifying it requires the password with which it was signed. Thus, giving a secure authentication method.

DELETE '/delete' - the last endpoint to delete an entry from the database. This deletes the credentials of the signed in user from the DB.

const { name, password } = req.body;
const deletedUser = await User.findOneAndDelete({ name, password });
if (!deletedUser) {
return res.status(400).send("Wrong credentials");
}
res.send("User deleted successfully");

There are numerous methods one can use to delete an entry in Mongoose. I used the most appropriate one here.

New things I learnt this week🔄

While I did cover mongoose this week, the thing that intrigued me the most was the distinction between verify and decode in JWT. And such an important distinction it is too.

Wrapping up

Some more fundamentals covered. Another step in the right direction. 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 2 : Middlewares, Global Catches, and Zod Validation

Nikhil Sharma — Mon, 29 Sep 2025 16:02:21 +0000

This week was all about the tiny things. Minuscule in volume but HUGE in importance. Let's get right into it!

Topics Covered✅

Last week, I was able to create a couple of backends. However, that was very basic stuff, where simply hitting different endpoints with different body content would yield results. In reality, however, it would be a bit different. The user could send various types of input(valid and invalid), and we would face errors and need some way to manage them.

The way to do all this is through-

Global catches and middlewares
Input validation

Both of these topics, I learnt and discovered through small assignments.

1a. Middlewares and Global Catches📎

Say I have one endpoint that needs to check for the username and password sent in the body, and match it with the real username and password that is stored locally for now. The layman's way to do this would be something like this

  const username = req.headers.username;
  const password = req.headers.password;
  if (!(username === "nikhil" && password === "sharma")) {
    res.status(400).json({
      msg: "auth is wrong",
    });
  }

Now, say I have to replicate this for 5 more endpoints. I could simply copy-paste the code snippet into all endpoints, but then I'd be defying DRY- DON'T REPEAT YOURSELF, which is one of the most fundamental things in all of software development.

Then a better way to do this would be by using Middlewares. A middleware is just a function that you pass into an endpoint. A middleware for simplifying the above problem would look like this.

function userMiddleware(req,res,next){
    const {username , password }= req.headers;
     if (!(username === "nikhil" && password === "sharma")) {
     return res.status(400).json({
       msg: "auth is wrong",
  });
}
  else{
    next();
  }
}

This would then be passed into the endpoint like this

app.get("/health-checkup" , userMiddleware, (req,res)=>{
  res.send("Healthy kidneys");
})

The middlewares always have three parameters - (req,res,next). I was familiar with req and res, but "next" was something new. 'next()' is what passes control from one middelware to the next (in case of multiple middlewares) or simply back to the endpoint.

1b. A special type of middleware is error-handling global catches

When our code randomly throws an error, it's possible that a lot of important and confidential backend information could get displayed to the user, which is not something we want. This is exactly where global catches come in.

If we put this -

app.use((err,req,res,next)=>{
    console.log(err);
    return res.status(500).json({"msg":"sorry our server is bad"});
})

at the end of our backend code, after all endpoints, then anytime a random error gets thrown from any endpoint, it gets caught in this global catch, where we can display whatever we want to the user.

That way, we do two things

We don't leak any private information
We can log the error internally for the dev team to look at.

Here, the four parameters are what separate this particular middleware from the rest. The extra first parameter is what tells Express that this middleware is for handling errors.

The need for Input Validation

In real-life cases, it would be careless to trust the user to always send the exact type of input that you need. Various phishing attempts could be made by sending in malicious inputs. Thus, we need some means to "validate" the input that the user sends us before sending that into the database. One means to do this is using the ZOD library.

ZOD🚀

ZOD lets us define a schema, which is basically a blueprint of the kind of input we expect from our users.

A zod schema can be something simple like

const schema = zod.array(zod.number());

which means that my input must be an array of numbers, or it can be something as complicated like-

import { z } from "zod";

// Example: user registration form
const userSchema = z.object({
  username: z.string()
    .min(3, "Username must be at least 3 characters")
    .max(20, "Username can't exceed 20 characters"),

  password: z.string()
    .min(8, "Password must be at least 8 characters")
    .regex(/[A-Z]/, "Password must contain at least one uppercase letter")
    .regex(/[0-9]/, "Password must contain at least one number"),

  email: z.string().email("Invalid email format"),

  age: z.number().int().positive().optional(), // optional field

  role: z.enum(["user", "admin", "superadmin"]), // only these values allowed

  address: z.object({ // nested object
    street: z.string(),
    city: z.string(),
    postalCode: z.string().regex(/^\d{5}$/, "Must be 5 digits")
  }),

  hobbies: z.array(z.string().min(2)), // array of strings, each at least 2 chars

  metadata: z.record(z.string(), z.any()), // any extra info as key-value pairs

}).strict(); // ensures no extra fields are allowed

This may seem overwhelming at first, but in reality it is just a simple chaining structure of rules that we can modify to our advantage. For more details, you may refer to the Official Documentation.

After defining our schema, in our endpoint(or middleware) we simply call schema.safeParse() on our input body, which automatically checks the entire input according to the schema and — unlike parse() — returns a special result object that contains a success boolean property indicating the outcome, and either the successfully parsed data or a ZodError object. This makes it ideal for handling validation without using try-catch blocks.

A complete example of this would be as follows-

const schema = zod.object({
    userEmail:zod.email(),
    password:zod.string().min(8),
    country: zod.literal("IN").or(zod.literal("US"))
})
app.post("/", (req, res) => {
  const userObj = req.body.userObj;
  const response = schema.safeParse(userObj);
  res.send({
    response,
  });
});

New things I learnt this week🔄

Middlewares, global catches and how much their positioning in the code matters!
Global catches are like nets that catch all errors and also help in fixing the cause of those errors by extensive logging.
Middlewares shine when you need to enforce concerns like logging, authentication, rate-limiting, or parsing data—that would otherwise bloat every endpoint.

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!