Forem: M Saad Ahmad

Day 61 of #100DaysOfCode — Python Refresher Part 1

M Saad Ahmad — Sat, 04 Apr 2026 08:39:59 +0000

When I started my #100DaysOfCode journey, I began with frontend development using React, then moved into backend development with Node.js and Express. After that, I explored databases to understand how data is stored and managed, followed by building full-stack applications with Next.js. It is now time to start learning Python, not from scratch, but as a refresher to strengthen my fundamentals and expand my backend skillset.

Learning Python strengthens my core programming skills and offers a new perspective beyond JavaScript. It aligns with backend development, data handling, and automation, allowing me to build on my existing knowledge and become a more versatile developer.

Today, for Day 61, I focused on revisiting the core building blocks of Python.

Core Syntax

Variables & Data Types

Variables are used to store data, and Python automatically assigns the data type based on the value.

name = "Ali"      # string
age = 22          # integer
price = 99.99     # float
is_active = True  # boolean

You don’t need to declare types explicitly like in some other languages; Python handles it dynamically.

Conditionals (`if/elif/else`)

Conditionals let your program make decisions.

age = 20

if age >= 18:
    print("Adult")
elif age > 12:
    print("Teen")
else:
    print("Child")

This is fundamental for controlling program flow, especially in backend logic (auth checks, validations, etc.).

Loops (`for`, `while`)

Loops allow you to repeat actions.

for i in range(3):
    print(i)

count = 0
while count < 3:
    print(count)
    count += 1

for is used more often in Python, especially when working with collections.

Functions

Functions group logic into reusable blocks.

def add(a, b):
    return a + b

print(add(2, 3))

They help keep your code clean and modular.

Data Structures

Lists

Lists store multiple items in order.

numbers = [1, 2, 3, 4]
print(numbers[0])  # 1

Dictionaries

Dictionaries store data in key-value pairs, similar to objects in JavaScript.

user = {
    "name": "Ali",
    "age": 22
}

print(user["name"])

Must Know:

Looping through dicts

for key, value in user.items():
    print(key, value)

Nested data handling

data = {
    "user": {
        "name": "Ali"
    }
}

print(data["user"]["name"])

👉 This directly maps to:

JSON (backend APIs)
Database data

Sets

Sets store unique values.

nums = {1, 2, 2, 3}
print(nums)  # {1, 2, 3}

Tuples

Tuples are like lists, but immutable (cannot be changed).

point = (10, 20)

Loops & Iteration

Looping through collections:

numbers = [1, 2, 3]

for num in numbers:
    print(num)

Using range():

for i in range(5):
    print(i)

Nested loops (useful for complex data):

matrix = [[1, 2], [3, 4]]

for row in matrix:
    for item in row:
        print(item)

Functions

Functions are where your code becomes structured and reusable:

Functions make your code reusable and structured.

def greet(name="User"):
    return f"Hello, {name}"

print(greet())
print(greet("Ali"))

👉 Think:

“How do I structure logic cleanly?”

Good function design = cleaner code + easier debugging + better scalability.

Working with JSON (IMPORTANT FOR BACKEND)

import json

data = json.loads(json_string)
json_string = json.dumps(data)

JSON is how data is exchanged between frontend and backend.

Example:

import json

json_string = '{"name": "Ali"}'
data = json.loads(json_string)

print(data["name"])

👉 This is directly used in:

APIs
Django / Flask

Basic File Handling

Working with files is a fundamental skill in backend:

Reading files
Writing files

with open("file.txt", "r") as f:
    data = f.read()

👉 Useful for:

Logs
Data processing
Simple storage tasks

List Comprehension (VERY USEFUL)

squares = [x*x for x in range(10)]

A shorter and cleaner way to write loops.

Equivalent version:

squares = []
for x in range(10):
    squares.append(x*x)

👉 Cleaner + faster code

Final Thoughts

Today wasn’t about learning something completely new; it was about reinforcing the fundamentals. Python feels simple on the surface, but mastering these basics is what makes you effective when building real-world applications.

Thanks for reading. Feel free to share your thoughts!

Day 60 of #100DaysOfCode — Deploying the Task App

M Saad Ahmad — Thu, 02 Apr 2026 21:01:12 +0000

Over the past two days, I built and styled a Task Manager app with Next.js, MongoDB, and Shadcn UI. Today was the final step: getting it live on Vercel.

Why Vercel?

Vercel is made by the same team behind Next.js, so deployment is essentially zero-config. No server setup, no CI/CD pipeline to configure, just connect your repo and push.

Steps Followed

1. Push code to GitHub
Make sure your project is in a GitHub repo before anything else.

2. Import the project on Vercel
Go to vercel.com → New Project → Import your GitHub repo. Vercel auto-detects it's a Next.js app.

3. Add Environment Variables
This is the most important step. Your .env.local file doesn't get pushed to GitHub, so you need to add your variables manually in Vercel:

MONGODB_URI=your_mongodb_connection_string

Go to: Project Settings → Environment Variables → add them there.

4. Deploy
Hit deploy. That's it. Vercel builds and hosts it automatically.

Every git push to your main branch triggers a new deployment going forward.

Gotcha: MongoDB Atlas Network Access

If your app connected fine locally but throws errors in production, check MongoDB Atlas → Network Access. You need to allow connections from anywhere (0.0.0.0/0) since Vercel uses dynamic IPs.

What I Learned

Environment variables must be added manually on Vercel — don't assume they carry over
Vercel's build logs are really useful for debugging deployment errors
Going from local to live took less than 5 minutes with Next.js + Vercel

Live App

The Task Management App is live on this link

That's Day 60 done. The app is live! 60 days down, 40 to go.

Day 59 of #100DayOfCode — Styling the Task Management App

M Saad Ahmad — Thu, 02 Apr 2026 17:18:50 +0000

Yesterday on Day 58, I built a Task Manager app with Next.js, MongoDB, and Server Actions. The app worked, but it looked rough. Today was all about making it actually nice to use.

What I Used

Tailwind CSS — for layout and spacing utilities
Shadcn UI — for pre-built, accessible components I can own and customize

Setting Up Shadcn

npx shadcn@latest init
npx shadcn@latest add button card badge input textarea select label

This drops the component source directly into your project under /components/ui. No black-box library — you own the code.

What I Styled

Layout — A clean navbar with a centered max-w-4xl main container across all pages.

Task List — A responsive 2-column grid on larger screens, with a friendly empty state when no tasks exist yet.

Task Cards — Each task is wrapped in a Card with the title, a colored status badge, description, timestamps, and Edit/Delete actions.

Task Form — Proper Label + Input/Textarea/Select combinations with placeholders, and a dynamic submit button that says "Create Task" or "Update Task" depending on the context.

A Gotcha with Shadcn Badge

Shadcn's Badge only ships with 4 variants: default, secondary, destructive, outline. There's no built-in success or warning.

Instead of extending the component, I used a simple helper with Tailwind classes directly:

const statusStyles = (status) => {
  if (status === "completed") return "bg-green-100 text-green-700 hover:bg-green-100";
  if (status === "in-progress") return "bg-yellow-100 text-yellow-700 hover:bg-yellow-100";
  return "bg-gray-100 text-gray-600 hover:bg-gray-100";
};

<Badge className={statusStyles(task.status)}>{task.status}</Badge>

Clean enough, and no need to touch the component internals.

Using `Button` with `asChild`

Shadcn's Button has an asChild prop that lets you pass a Link inside it and get all the button styles applied to the anchor — no wrapper divs needed:

<Button asChild variant="outline" size="sm">
  <Link href={`/tasks/${task._id}`}>Edit</Link>
</Button>

This is one of those small things that makes Shadcn feel really well thought out.

Key Takeaway

Shadcn isn't a traditional component library. You install only what you need, and the code lives in your project. That means full control — no fighting with overrides or !important hacks.

Tomorrow, for Day 60, I'll be deploying the app on Vercel.

Day 58 of #100DayOfCode — Building Task Management CRUD App with Next.js

M Saad Ahmad — Wed, 01 Apr 2026 18:06:20 +0000

For Day 58 of my #100DaysOfCode journey, my goal was to build a basic but fully functional Task Management App using Next.js. Up until this point, I had been learning individual Next.js concepts: server and client components, routing with the App Router, data fetching and caching, API routing, server actions, and connecting to a MongoDB database. I felt confident with each concept in isolation, but I hadn't yet put them all together in a single project.

So today's goal was simple: build something real, something CRUD-based, that forces me to use everything I've learned so far in one place.

What I Built

The app is a simple Task Manager where you can create, view, edit, and delete tasks. Each task has a title, description, and a status (pending, in-progress, or completed). The app has three pages and three components:

Pages:

/tasks — displays all tasks stored in the database
/tasks/new — a form to create a new task
/tasks/[id] — a pre-filled form to edit an existing task

Components:

TaskList — receives all tasks and maps over them
TaskCard — displays an individual task with Edit and Delete options
TaskForm — a reusable form used on both the create and edit pages

🛠 Concepts Used

App Router — folder-based routing with dynamic segments like [id]
Server Components — pages that fetch data directly from MongoDB without any client-side fetching
Client Components — components like TaskForm and TaskCard that handle user interaction and form inputs
Server Actions — functions that run on the server, connected directly to forms via the action prop
MongoDB — storing and querying tasks using clientPromise without Mongoose
revalidatePath — to refresh the page cache after every mutation so the UI always reflects the latest database state
redirect — to send the user back to /tasks after creating or updating a task

Folder Structure

next-crud-app/
├── app/
│   ├── page.js               --> Landing page
│   └── tasks/
│       ├── page.js           --> Lists all tasks (Server Component)
│       ├── new/
│       │   └── page.js       --> Create task form page (Server Component)
│       └── [id]/
│           └── page.js       --> Edit task form page (Server Component)
├── actions/
│   └── tasks.js              --> All server actions (CRUD)
│
├── db/
│   └── mongodb.js            --> MongoDB connection
│
│
├── components/
│   ├── TaskCard.jsx          --> Single task display (Client Component)
│   ├── TaskForm.jsx          --> Reusable form (Client Component)
│   └── TaskList.jsx          --> Maps over tasks (Server Component)

db/mongodb.js — sets up and exports the MongoDB client connection used across all server actions
actions/tasks.js — the heart of the app; contains all five CRUD functions that interact with MongoDB
tasks/page.js — an async server component that fetches all tasks and passes them down to TaskList
tasks/[id]/page.js — receives the dynamic id from params, fetches that specific task, and passes it to TaskForm for pre-filling

The Interesting Part — `actions/tasks.js`

The most interesting and challenging file to write was actions/tasks.js. This is where all the CRUD logic lives and where everything connects together.

What made it challenging was that I initially wrote it based on how I thought it would work, similar to how I had written a contact form previously. I passed plain objects to functions and queried MongoDB by id as a plain string. But I quickly ran into several issues I wasn't aware of:

Server actions receive FormData, not plain objects.

When a server action is connected to a form via the action prop, Next.js automatically passes FormData to it. You have to use formData.get("fieldName") to extract values — you can't just pass a plain object.
MongoDB _id is an ObjectId, not a string.

When querying, updating, or deleting by _id, you need to wrap the id with new ObjectId(id) from the mongodb package. A plain string won't match anything in the database.
revalidatePath and redirect are required.

Without revalidatePath, the page cache doesn't update after a mutation, so the UI won't reflect changes. Without redirect, the user just stays on the form page after submitting.
Serialization is needed when returning data.

MongoDB returns special document objects that can't be passed directly as props to client components. Wrapping the result in JSON.parse(JSON.stringify(data)) converts it to a plain JavaScript object that Next.js can safely pass across the server-client boundary.

"use server";
import clientPromise from "../db/mongo";
import { ObjectId } from "mongodb";
import { revalidatePath } from "next/cache";
import { redirect } from "next/navigation";

export async function createTask(formData) {
  const client = await clientPromise;
  const db = client.db("taskapp");
  await db.collection("tasks").insertOne({
    title: formData.get("title"),
    description: formData.get("description"),
    status: formData.get("status"),
    createdAt: new Date(),
  });
  revalidatePath("/tasks");
  redirect("/tasks");
}

What I Struggled With

Two things genuinely confused me during this build:

1. Understanding which file uses which component and why.
With multiple pages and components, I kept getting confused about who imports what and why. For example, I wasn't sure if TaskList should also import TaskForm, or whether TaskForm belonged on the page directly. Mapping out the dependency chain clearly helped a lot:

tasks/page.js → TaskList → TaskCard
tasks/new/page.js → TaskForm
tasks/[id]/page.js → TaskForm
actions/tasks.js → used by TaskCard and TaskForm

2. Understanding how actions/tasks.js actually works.
I initially wrote the file by instinct based on my contact form experience. But server actions in a CRUD context behave differently; they receive FormData, need ObjectId for queries, and require revalidatePath to keep the UI in sync. Once I understood these gaps, the file made complete sense.

Conclusion

What made this project unique as part of my #100DaysOfCode journey is that it wasn't about learning something new; it was about connecting everything I already knew into one working app. It's one thing to understand server actions in isolation, and another thing entirely to wire them up to a form, pass the right data, hit the database, and have the UI update automatically.

This project gave me that full picture for the first time. It also revealed the gaps in my understanding that I wouldn't have found without actually building something.

What's Next

The app is fully functional but completely unstyled. The next step is to add Tailwind CSS to style the UI and then deploy it on Vercel.

Stay tuned for Day 59!

Day 57 of #100DayOfCode — Understanding Server Actions vs API Routes & MongoDB in Next.js

M Saad Ahmad — Tue, 31 Mar 2026 05:36:25 +0000

API routing in Next.js enables developers to create backend endpoints directly within their applications, allowing for request handling, data processing, and API exposure. However, as apps become more complex, especially with UI interactions like form submissions, API routes can become repetitive and cluttered.

That's where Server Actions offer a streamlined solution by enabling server-side logic execution directly from components, removing the need for a separate API layer. This keeps your code simpler and easier to maintain by placing logic closer to its usage.

Today, for Day 57, the goal was to understand what server actions is and how we can connect to MongoDB using both API routing and server actions

What Are Server Actions in Next.js?

Server Actions are a new feature in Next.js that allow you to run server-side code directly from your components without creating a separate API endpoint.

They are defined using the "use server" directive and are typically used inside React Server Components or triggered via forms.

Key Idea:

Instead of calling an API route, you call a server function directly.

Example: Simple Server Action

// app/actions.js
"use server";

export async function createUser(formData) {
  const name = formData.get("name");

  // Simulate saving to database
  console.log("User created:", name);

  return { success: true };
}

// app/page.js
import { createUser } from "./actions";

export default function Page() {
  return (
    <form action={createUser}>
      <input type="text" name="name" placeholder="Enter name" />
      <button type="submit">Submit</button>
    </form>
  );
}

No API route. No fetch. Just direct server execution.

Server Actions vs API Routes in Next.js

Here’s how they compare:

Feature	Server Actions	API Routes
Setup	Inline in components	Separate endpoint files
Network Request	Not required	Required (fetch/axios)
Use Case	UI-driven mutations	Public or external APIs
Performance	Faster (no HTTP overhead)	Slightly slower (HTTP roundtrip)
Reusability	Limited to app	Can be used anywhere (frontend/backend)
Security	Runs on server by default	Needs manual handling

When to Use What?

Use Server Actions When:

Handling form submissions
Performing simple mutations (create/update/delete)
Working tightly with UI components
You don’t need a public API

Example: Submitting a contact form or saving user preferences.

Use API Routes When:

Building a public API
Integrating with third-party services
Handling complex backend logic
You need endpoints accessible from mobile apps or external clients

Example: Payment processing, webhook handling, or external integrations.

Connecting MongoDB with Next.js

Connecting MongoDB with Next.js allows you to build full-stack applications where your frontend and database work seamlessly together. Whether you use Server Actions or API Routes, Next.js makes it straightforward to establish a database connection, perform CRUD operations, and manage data efficiently—all within the same project structure.

MongoDB with Server Actions

You can directly connect to MongoDB inside a Server Action since it runs on the server.

💻 Example:

// lib/mongodb.js
import mongoose from "mongoose";

export async function connectDB() {
  if (mongoose.connections[0].readyState) return;

  await mongoose.connect(process.env.MONGODB_URI);
}

// app/actions.js
"use server";

import { connectDB } from "../lib/mongodb";
import User from "../models/User";

export async function createUser(formData) {
  await connectDB();

  const name = formData.get("name");

  await User.create({ name });

  return { success: true };
}

This is clean and avoids unnecessary API layers.

MongoDB with API Routes

Here, you define a traditional API endpoint and connect to MongoDB inside it.

💻 Example:

// pages/api/users.js
import { connectDB } from "../../lib/mongodb";
import User from "../../models/User";

export default async function handler(req, res) {
  await connectDB();

  if (req.method === "POST") {
    const { name } = req.body;

    const user = await User.create({ name });

    return res.status(201).json(user);
  }

  res.status(405).json({ message: "Method not allowed" });
}

// frontend usage
async function createUser() {
  await fetch("/api/users", {
    method: "POST",
    body: JSON.stringify({ name: "Ali" }),
    headers: {
      "Content-Type": "application/json",
    },
  });
}

This approach is more flexible and reusable across platforms.

Conclusion

Server Actions and API Routes both solve similar problems but in different ways.

Server Actions simplify development by eliminating the need for API endpoints in many cases, making your code more direct and efficient.
API Routes remain essential when you need flexibility, external access, or more complex backend logic.

When working with MongoDB:

Use Server Actions for tight UI + database interactions.
Use API Routes when building scalable, reusable backend services.

Understanding and mastering both approaches gives us the flexibility to build modern, performant full-stack apps with Next.js

Thanks for reading. Feel free to share your thoughts!

Day 56 of #100DayOfCode — Next.js API routes

M Saad Ahmad — Mon, 30 Mar 2026 04:34:55 +0000

When building full-stack applications, one of the biggest challenges is managing separate frontend and backend codebases. This is where Next.js API routes come in. With the App Router, Next.js allows you to build backend endpoints directly inside your project, no need for a separate Express server.

Today, for day 56, the goal was to understand the API routing in Next.js

React.js + Node.js vs Next.js

In MERN:

Frontend → React
Backend → Express (separate server)

In Next.js:

Same project = Frontend + Backend

You don’t need a separate backend anymore.
API routes live inside your app.

📁 Folder Structure (App Router Way)

We create APIs like this:

app/api/users/route.js

This automatically maps to:

/api/users

No extra routing setup needed.

HTTP Methods in Next.js API Routes

Inside route.js, you export functions like:

export async function GET() {}
export async function POST() {}
export async function PUT() {}
export async function DELETE() {}

Each function handles a specific HTTP method.

💡 Important correction:

These are Web standard Request/Response handlers, not Express handlers.
They run in server environments (Node.js or Edge Runtime).

Request & Response Handling

Basic Example:

export async function GET() {
  return Response.json({ message: "Hello World" });
}

Access Request Data:

export async function POST(request) {
  const body = await request.json();
  return Response.json({ received: body });
}

This replaces:

Express req.body
Express res.json()

Better understanding:

request = Web API Request
Response.json() = built-in helper (Next.js sugar over standard Response)

Connecting Frontend to API

From your component:

const res = await fetch("/api/users");
const data = await res.json();

No need for:

Express server
Axios (optional)
CORS setup (in most cases)

Dynamic API Routes

Create dynamic endpoints like this:

app/api/users/[id]/route.js

Access params:

export async function GET(request, { params }) {
  return Response.json({ id: params.id });
}

Same concept as dynamic pages.

💡 Correction:
You don’t access params.id directly, you must destructure it from the second argument.

🛡️ Basic Validation & Error Handling

export async function POST(request) {
  const body = await request.json();

  if (!body.name) {
    return Response.json(
      { error: "Name required" },
      { status: 400 }
    );
  }

  return Response.json({ success: true });
}

You control:

Status codes
Errors
Responses

Database Integration

You can connect databases directly inside API routes:

MongoDB (e.g., with Mongoose)
PostgreSQL (e.g., with Prisma)

API routes act like your backend layer.

Best practice:

Reuse DB connections (avoid reconnecting on every request in dev)

🔥 Why This Is Powerful

No separate backend setup
Full-stack in one project
Faster development
Cleaner architecture

Key Takeaways

Next.js API routes replace Express in many cases
File-based routing makes APIs super simple
Uses Web standard Request & Response
Works seamlessly with frontend via fetch()
Supports dynamic routes and full backend logic

Final Thoughts

Coming from React + Node.js, this felt weird at first…
But once it clicks, it’s actually simpler and more powerful.
We're basically writing backend logic inside the frontend project.

Thanks for reading. Feel free to share your thoughts!

Day 55 of #100DayOfCode — Data Fetching and Caching in NextJS

M Saad Ahmad — Sat, 28 Mar 2026 20:24:31 +0000

Data fetching with React follows the same well-known drill: useEffect, useState, loading spinners, and API keys being dangerously exposed on the frontend. Next.js changes all of that. With its built-in server-side data fetching and automatic caching system, Next.js makes it possible to build fast, secure, full-stack applications without reaching for a dozen extra libraries.

For day 55, the goal was to understand how data fetching works in Next.js, how it compares to the React way, and how to use the different caching strategies to make the app as fast and efficient as possible.

Data Fetching: React vs Next.js

How React Fetches Data

In React, data fetching happens entirely in the browser. When a user visits a page, the browser first downloads the HTML (which is mostly empty), then runs your JavaScript bundle, and only then fires off an API request to fetch the data. This means the user always sees a loading state before the actual content appears.

Here is what that typically looks like:

import { useState, useEffect } from 'react'

function Posts() {
  const [posts, setPosts] = useState([])
  const [loading, setLoading] = useState(true)

  useEffect(() => {
    fetch('https://api.example.com/posts')
      .then(res => res.json())
      .then(data => {
        setPosts(data)
        setLoading(false)
      })
  }, [])

  if (loading) return <p>Loading...</p>

  return (
    <div>
      {posts.map(post => (
        <div key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.body}</p>
        </div>
      ))}
    </div>
  )
}

This works, but it comes with real problems:

Loading spinners everywhere —> users see an empty page or spinner before any content appears.
Multiple round trips —> the browser loads the page, then makes a separate API request, adding latency.
Exposed API keys —> any secret keys used in fetch calls are visible in the browser's DevTools Network tab.
No built-in caching —> every render triggers a fresh API call unless you manually set up something like React Query or SWR.
SEO suffers —> search engines crawl the empty HTML before JavaScript runs, so they may not see your content at all.

How Next.js Fetches Data

Next.js introduces Server Components; components that run on the server before the HTML is ever sent to the browser. Because they run on the server, you can make them async and await your data at the top level. No useEffect, no useState, no loading spinner.

async function Posts() {
  const res = await fetch('https://api.example.com/posts')
  const posts = await res.json()

  return (
    <div>
      {posts.map(post => (
        <div key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.body}</p>
        </div>
      ))}
    </div>
  )
}

That is the entire component. The server fetches the data, builds the HTML with the data already inside it, and sends the finished page to the browser. The user never sees a loading state because by the time the page arrives, the data is already there.

This approach is better for several reasons:

No loading spinners —> data arrives with the page, not after it.
Better performance —> one round trip instead of two.
API keys stay hidden —> the fetch call never reaches the browser, so secrets stay on the server.
Better SEO —> search engines receive fully rendered HTML with real content.
Built-in caching —> Next.js automatically caches fetch responses on the server (more on this below).

The fetch syntax is the same as in React or plain JavaScript. The only difference is where it executes, on the server, and the automatic handling by Next.js.

Comparison of Data Fetching between React/JS vs Next.js

What is Caching in Next.js?

Caching means storing the result of an API call so that the next time the same data is needed, it can be served instantly from the stored copy instead of making another network request. Without caching, every user visiting your page triggers a fresh API call, which is slow and expensive, especially if thousands of users are hitting the same endpoint.

Next.js extends the native fetch API with its own caching layer baked in. You control the caching behavior by passing options to your fetch call.

Important version note: In Next.js 13 and 14, caching was ON by default and you had to opt out. In Next.js 15, the default was flipped, caching is now OFF by default, and you have to opt in. Always check your version before assuming the default behavior.

Types of Caching in Next.js

1. Cache Forever (force-cache)

const res = await fetch('https://api.example.com/posts', {
  cache: 'force-cache'
})

This fetches the data once and caches it indefinitely. Subsequent requests for the same data are served instantly from the cache without hitting the API again. This is the most aggressive caching strategy and gives you the fastest possible response times.

2. No Cache (no-store)

const res = await fetch('https://api.example.com/posts', {
  cache: 'no-store'
})

This completely disables caching. Every request hits the API fresh and gets the latest data. This is the slowest option but guarantees you always have up-to-date information.

3. Revalidate Every N Seconds (ISR)

const res = await fetch('https://api.example.com/posts', {
  next: { revalidate: 60 }
})

This is the sweet spot for most applications. It caches the response but automatically refreshes it every 60 seconds in the background. Users always get a fast cached response, but the data does not go stale forever. This is called Incremental Static Regeneration (ISR) and it uses a stale-while-revalidate strategy, serve the cached version immediately, then quietly fetch a fresh copy in the background for the next request.

4. Revalidate On Demand

import { revalidatePath } from 'next/cache'

// Call this function whenever your data changes
export async function updatePost() {
  // ... update logic

  revalidatePath('/posts') // tells Next.js to rebuild this page
}

Instead of refreshing on a time interval, you manually tell Next.js when the cached data is stale. This is useful when you know exactly when data changes — for example, when a user submits a form, a CMS editor publishes new content, or a webhook fires from an external service. The page is rebuilt on the next request after revalidatePath is called.

Which Caching Strategy Should Be Used?

Choosing the right caching strategy depends entirely on how often the fetched data in the app changes and how critical it is that users see the latest version. Here is a practical breakdown:

Use `force-cache` for content that rarely changes

Think documentation pages, marketing landing pages, legal pages, blog posts that are rarely edited, or any content that was written once and stays the same. Since this data does not change, there is no reason to ever hit the API again after the first fetch. force-cache gives you maximum speed with zero cost.

const res = await fetch('https://api.example.com/docs', {
  cache: 'force-cache'
})

Use `revalidate` (ISR) for content that changes occasionally

This is the right choice for the majority of real-world pages: e-commerce product listings where prices update periodically, news articles, blog indexes, weather data for a specific city, or sports standings. The data changes, but not so frequently that a slightly stale version causes real problems. A revalidation interval of 60 seconds to an hour is usually appropriate, depending on how time-sensitive the data is.

// Refresh every 10 minutes — good for product listings
const res = await fetch('https://api.example.com/products', {
  next: { revalidate: 600 }
})

Use `revalidatePath` for content driven by user actions or a CMS

When you are building a blog or CMS-backed site and an editor publishes a new post, you want that page to update immediately, not in 10 minutes. revalidatePath lets you trigger a rebuild the moment the content changes. The same applies to e-commerce admin panels, user-generated content, or any situation where a specific action is the trigger for stale data.

import { revalidatePath } from 'next/cache'

async function publishPost(id) {
  await db.post.update({ where: { id }, data: { published: true } })
  revalidatePath('/blog') // immediately mark the blog listing as stale
}

Use `no-store` for data that must always be live

User-specific data like dashboards, account settings, or notification counts must never be cached; each user needs their own fresh data. The same goes for live stock prices, real-time sports scores, or anything where a stale response would cause real user confusion or financial consequences.

const res = await fetch(`https://api.example.com/user/${userId}/dashboard`, {
  cache: 'no-store'
})

Quick Reference

Data type	Strategy	Example
Static content, never changes	`force-cache`	Docs, legal pages, about page
Changes occasionally	`revalidate: 3600`	Blog posts, product listings
Changes frequently	`revalidate: 60`	News feed, prices, scores
Changes unpredictably	`revalidatePath` on demand	CMS content, user-published posts
Must always be live	`no-store`	User dashboard, live data, notifications

Final Thoughts

Data fetching and caching in Next.js simplify web application development. Instead of complex client-side fetching with useEffect, Next.js manages loading states, API key security, and caching out of the box.

With Server Components, you can use async/await data fetching directly in your components with minimal boilerplate. The built-in caching system allows for fine-grained control over data freshness in your fetch calls. These features enable you to build fast, secure, and SEO-friendly full-stack applications in Next.js while maintaining a great developer experience.

Thanks for reading. Feel free to share your thoughts!

Day 54 of #100DaysOfCode — Creating Blog App

M Saad Ahmad — Sat, 28 Mar 2026 05:52:15 +0000

On day 54, my goal was to create a basic blog app using Next.js, applying the concepts I had learned so far. I focused on the fundamentals of Next.js, including how it operates, the differences between server and client components, the Link component, and App Router routing. This blog app served as a practical way to integrate all these concepts into a single real project, rather than working through isolated examples.

What I Built

A simple blog app using Next.js App Router. It has a home page that lists all posts, a dedicated blog section for reading individual posts, and separate pages for About and Contact, all wrapped in a shared Header and Footer layout.

🛠️ Concepts Used

Next.js App Router & file-based routing
Root layout with shared Header & Footer
Server-side vs client-side components
Link component for navigation
Dynamic routing with [slug]

Folder Structure

app/
├── layout.jsx              --> Root layout (with Header and Footer)
├── page.jsx                --> Home page — lists all posts
├── about/
│   └── page.jsx            --> About me page
├── contact/
│   └── page.jsx            --> Contact page
├── blog/
│   ├── page.jsx            --> All posts listing
│   └── [slug]/
│       ├── not-found.jsx
│       └── page.jsx        --> Individual post (dynamic route)
│
├── data/
│    └── posts.js           --> Post data
│
│
├── components/
│       ├── Header.jsx      --> Header component
│       └── Footer.jsx      --> Footer component

The root layout.jsx wraps the entire app with a shared Header and Footer from the components/ directory. The home page (app/page.jsx) lists all posts, while dedicated routes exist for /about and /contact. The /blog route has its own listing page, and dynamic post pages are handled via the [slug] segment, where each post is rendered based on its URL slug, with a not-found.jsx as a fallback for invalid slugs.

The Interesting Part: `[slug]` Dynamic Routing

The thing that actually made sense to me through building this was how Next.js handles dynamic routes. Instead of creating a separate page file for every blog post, you create a single folder named [slug] and Next.js does the rest.

blog/
└── [slug]/
    ├── page.jsx        --> renders the individual post
    └── not-found.jsx   --> handles invalid slugs

Define all the posts inside the posts.js file and import it in page.jsx file. Inside page.jsx, you get the slug from params and use it to fetch or find the right post:

export default function BlogPost({ params }) {
  const { slug } = params;
  // use slug to find and display the correct post
}

And if someone visits a slug that doesn't exist, not-found.jsx kicks in automatically. Clean and simple.

What I Struggled With

Understanding when the not-found.jsx file gets triggered took me some time. I initially thought I needed to handle redirects manually, but Next.js takes care of it for you as long as the file is correctly placed within the [slug] folder.

Link

GitHub Repo Link

Final Thoughts

Building this blog app was a solid checkpoint in my 100 Days of Code journey. It's one thing to understand routing or layouts in theory, but actually wiring them together into a real project makes everything stick differently.

Thanks for reading. Feel free to share your thoughts!

Day 53 of #100DaysOfCode — Routing (App Router)

M Saad Ahmad — Fri, 27 Mar 2026 06:13:19 +0000

Routing is one of the most fundamental concepts in any web application. It determines how users move between different pages and how those pages are structured. In Next.js, routing has evolved significantly with the introduction of the App Router, which uses a file-based system to make navigation more intuitive, scalable, and powerful, all without needing external libraries.

Today, for day 53, the goal was to understand routing in Next.js

App Router Mental Model

In Next.js App Router:

Folders = Routes
Files = UI + Behavior

👉 Your project structure defines your entire routing system.

No need for separate route configuration like in traditional React apps.

Core File Conventions (Built-in Superpowers)

Next.js gives you powerful features just by naming files correctly.

`page.js`

Defines a route
Required to make a route accessible

Example:

app/about/page.js → /about

`layout.js`

Shared UI (Navbar, Footer, Sidebar)
Wraps all child routes automatically

👉 Layouts can be nested, which is extremely powerful for dashboards and apps.

`loading.js`

Shows loading UI while data is being fetched
Works with React Suspense under the hood

`error.js`

Handles runtime errors in that route segment
Must be a Client Component ("use client" required)

`not-found.js`

Custom 404 UI for that route segment
Triggered using notFound() from Next.js

👉 Key Insight:
All of this comes without installing any extra libraries.

Nested Routing (Zero Config)

Routing is automatically created from folders.

Example:

app/
  dashboard/
    page.js        → /dashboard
    settings/
      page.js      → /dashboard/settings

👉 No need for route definitions like in React Router.

Dynamic Routes

Dynamic routing is super clean in App Router using square brackets.

Create a dynamic route:

app/blog/[slug]/page.js

Access params:

export default function Page({ params }) {
  return <h1>{params.slug}</h1>;
}

👉 This replaces React Router params.

⚠️ Important Update (Accuracy Fix)

In Server Components → use params (as shown above)
In Client Components → use:

import { useParams } from "next/navigation";

Route Groups

Route groups help organize your code without affecting URLs.

Example:

app/
  (auth)/
    login/page.js
    register/page.js

👉 URLs will still be:

/login
/register

Navigation Hooks

These hooks come from:

import { useRouter, usePathname } from "next/navigation";

`useRouter()`

Used for programmatic navigation

router.push("/dashboard");

`usePathname()`

Returns the current route path

⚠️ Important

👉 These hooks only work in Client Components ("use client" required)

Layout Nesting

App Router allows multiple layout levels:

Root Layout → app/layout.js
Section Layout → app/dashboard/layout.js
Nested Layouts → deeper levels

Example:

/dashboard → has its own layout
/dashboard/settings → inherits dashboard layout automatically

👉 This is perfect for:

Dashboards
Admin panels
Complex apps

Key Takeaways (Quick Recap)

File system = routing system
page.js creates routes
layout.js enables shared UI
Nested routing works automatically
Dynamic routes use [param]
Route groups organize without changing URLs
Navigation hooks require Client Components

Final Thoughts

The Next.js App Router simplifies routing by turning your folder structure into a powerful system. Once you understand the core conventions, building scalable and well-structured applications becomes much easier.

“Folders = Routes, Files = Behavior”

Thanks for reading. Feel free to share your thoughts!

Day 52 of #100DayOfCode — Script, Link & Image components in Next.js

M Saad Ahmad — Thu, 26 Mar 2026 04:59:30 +0000

If you're building modern web applications with Next.js, you've probably come across three powerful built-in components: Link, Script, and Image. These components are designed to improve performance, optimize user experience, and simplify common tasks like navigation, third-party script loading, and image optimization. Unlike traditional HTML elements, these components are deeply integrated with Next.js features such as routing, lazy loading, and performance optimization, making them essential tools for any developer working in the Next.js ecosystem.

The goal for day 52 was to understand the Link, Script, and Image components in Next.js and their use.

🔗 The Link Component in Next.js

The Link component in Next.js is used for client-side navigation between pages. Instead of using traditional <a> tags, Next.js encourages developers to use <Link> because it enables faster page transitions, prefetching, and avoids full page reloads.

Why use `<Link>` instead of `<a>`?

Client-side routing for faster navigation
No full page reloads
Automatic prefetching of linked pages
Improved performance and UX

💻 Example:

import Link from 'next/link';

export default function Home() {
  return (
    <div>
      <h1>Welcome to My App</h1>
      <Link href="/about">
        Go to About Page
      </Link>
    </div>
  );
}

👉 Using <Link> ensures your app feels like a single-page application (SPA) while still benefiting from server-side rendering.

📜 The Script Component in Next.js

The Script component in Next.js allows you to load and manage third-party scripts efficiently. It gives you fine-grained control over when and how scripts are loaded, improving performance and avoiding render-blocking issues.

⚠️ Note: Unlike <script> in HTML, Next.js <Script> optimizes loading strategies.

Why use `<Script>` instead of traditional script tags?

Control loading strategies (beforeInteractive, afterInteractive, lazyOnload)
Prevent render-blocking
Optimize performance and Core Web Vitals
Better handling of third-party scripts

💻 Example:

import Script from 'next/script';

export default function Analytics() {
  return (
    <>
      <Script
        src="https://example.com/analytics.js"
        strategy="afterInteractive"
      />
    </>
  );
}

👉 This ensures scripts load only when needed, improving your app’s speed and performance.

🖼️ The Image Component in Next.js

The Image component is one of the most powerful features of Next.js. It provides automatic image optimization, including resizing, lazy loading, and modern format delivery (like WebP).

What makes `<Image>` special?

Automatic image optimization
Lazy loading by default
Responsive images
Supports modern formats

💻 Example:

import Image from 'next/image';

export default function Profile() {
  return (
    <div>
      <h2>My Profile</h2>
      <Image
        src="/profile.jpg"
        alt="Profile Picture"
        width={300}
        height={300}
      />
    </div>
  );
}

👉 Using <Image> helps improve Core Web Vitals, especially Largest Contentful Paint (LCP).

🎯 Conclusion

Understanding and using Link, Script, and Image components in Next.js is crucial for building high-performance, SEO-friendly web applications. The <Link> component enhances navigation speed, <Script> optimizes third-party script loading, and <Image> ensures efficient image delivery. Together, they help developers create fast, scalable, and user-friendly applications.

Thanks for reading. Feel free to share your thoughts!

Day 51 0f #100DaysOfCode — Server Components vs Client Components

M Saad Ahmad — Wed, 25 Mar 2026 05:04:23 +0000

Modern web applications require both performance and interactivity, with users expecting fast page loads and dynamic experiences. Traditionally, developers faced a trade-off between server-side rendering (SSR) for speed and client-side rendering (CSR) for interactivity, leading to complexity.
Next.js addresses this by introducing Server Components and Client Components, enabling a smart division of responsibilities between the server and the browser. This approach is the reason Next.js offers both server and client components.

For today, day 51, the goal was to understand what server and client components are in Next.js, what the difference is between them, and why they even exist.

What is a Server Component?

A Server Component in Next.js is a React component that runs only on the server. It never gets shipped to the browser, meaning:

Smaller JavaScript bundle
Better performance
Direct access to backend resources (databases, APIs, secrets)

Example of a Server Component

// app/page.jsx

async function getData() {
  const res = await fetch('https://api.example.com/data');
  return res.json();
}

export default async function Page() {
  const data = await getData();

  return (
    <div>
      <h1>Server Component</h1>
      <p>{data.message}</p>
    </div>
  );
}

👉 This is how you normally write Next.js code, and this, by default, is a server component.

⚙️ Why are Components Server Components by Default?

Next.js defaults to Server Components because:

Performance-first approach: Less JavaScript sent to the client
Security: Sensitive logic stays on the server
Smaller bundles: Faster load times
Better SEO: Content is pre-rendered on the server

By making server components the default, Next.js encourages developers to build faster and more efficient applications without extra effort.

💻 What is a Client Component?

A Client Component is a component that runs in the browser. It is required when you need:

State (useState)
Effects (useEffect)
Event handlers (onClick, onChange)
Browser APIs (like localStorage)

To define a Client Component, you must explicitly add:

"use client";

Example of a Client Component

"use client";

import { useState } from "react";

export default function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <h1>Client Component</h1>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>
        Increment
      </button>
    </div>
  );
}

By adding "use client" above the codes, the default server component now becomes a client component

🤔 Why Do Client Components Exist?

If Server Components are so powerful, why do we even need Client Components?

Because not everything can happen on the server.

Client Components exist for:

User Interactions (clicks, typing, animations)
Real-time updates
Dynamic UI behavior
Browser-only APIs

Without Client Components, your app would be fast—but static and non-interactive.

Server vs Client Components (Side-by-Side Comparison)

Feature	Server Component 🖥️	Client Component 🌐
Runs on	Server	Browser
Default in Next.js	✅ Yes	❌ No
JavaScript sent	❌ Minimal	✅ Included
Interactivity	❌ No	✅ Yes
Access to DB/API	✅ Direct	❌ Via API calls
useState/useEffect	❌ Not allowed	✅ Allowed
SEO Friendly	✅ Excellent	⚠️ Depends
Performance	🚀 Faster	⚠️ Heavier

When to Use Server vs Client Components

Use Server Components when:

Fetching data from a database or API
Rendering static or semi-static content
SEO is important
You want better performance and smaller bundles

Use Client Components when:

You need interactivity (buttons, forms, UI events)
You use React hooks (useState, useEffect)
You rely on browser APIs
You’re building dynamic UI (modals, dropdowns, animations)

💡 Pro Tip:
Keep components as Server Components by default, and only convert to Client Components when absolutely necessary.

Final Thoughts

The introduction of Server and Client Components in Next.js is a game-changer for modern web development. It allows developers to build applications that are both highly performant and interactive, without compromising one for the other.

By understanding when to use each type, you can:

Optimize performance
Improve SEO
Deliver better user experiences

Thanks for reading. Feel free to share your thoughts!

Day 50 #100DaysOfCode — Introduction to Next.js

M Saad Ahmad — Tue, 24 Mar 2026 06:05:40 +0000

Over the past days of my 100 Days of Code challenge, I learned how to build UI components with React, manage state, and handle user interactions on the frontend. On the backend side, I worked with Node.js and Express.js to build APIs, connected them to databases, and understood how data flows between the client and the server. But as I kept building, one thing became obvious — maintaining a separate frontend and backend project, manually setting up routing with React Router, and figuring out how to make pages SEO-friendly was adding a lot of overhead to every project.

This is where Next.js changes the game.

What is Next.js

Next.js is a React framework that helps you build:

Faster apps
SEO-friendly apps
Full-stack applications

Key features Next.js adds to React:

Feature	What it means
File-based routing	Your folder structure is your routing
Server-Side Rendering (SSR)	Pages are rendered on the server per request
Static Site Generation (SSG)	Pages are pre-built at deploy time
API Routes	Write backend endpoints inside your frontend project

Why Next.js Exists

Plain React is a UI library. It's great at building interfaces, but it doesn't tell you:

How to structure your project
How to handle routing
How to render things on the server
How to write backend logic alongside your frontend

That's where frameworks exist — and Next.js fills all those gaps for React.
Next.js solves these problems by giving you a full-stack framework on top of React.

React SPA vs Next.js

React SPA vs Next.js: What's the Real Difference?

A plain React app is a Single Page Application (SPA). The browser downloads one HTML file, then JavaScript takes over and renders everything client-side.

Next.js changes this model:

	React SPA	Next.js
Rendering	Client-side only	Server + Client
SEO	Poor (JS-heavy)	Better (HTML sent from server)
Routing	Manual (React Router)	Built-in (file-based)
Backend	Separate project	API routes built-in
Performance	Depends on bundle size	Optimized by default

This is a mindset shift, not just a syntax change.

Pages Router vs App Router

Next.js has two routing systems. You'll likely encounter both, but the App Router is the modern, recommended approach.

	Pages Router (`pages/`)	App Router (`app/`)
Introduced	Original Next.js	Next.js 13+
Status	Still supported	Recommended going forward
Default component type	Client Components	Server Components

👉 Use App Router for any new project. The Pages Router still works and is still widely used in older codebases, so it's worth knowing it exists.

Project Structure

When you create a new Next.js app, here's what the key files and folders mean:

my-app/
├── app/
│   ├── layout.js       ← Wraps all pages (like a shell/template)
│   ├── page.js         ← The "/" homepage route
│   └── globals.css     ← Global styles
├── public/             ← Static assets (images, fonts)
├── next.config.js      ← Next.js configuration
└── package.json

The app/ folder is the App Router. Everything inside it is a route, a layout, or a component.

File-Based Routing: One of the Biggest Shifts

This is one of the most satisfying things about Next.js.

You don't configure routes. You create folders.

app/
  page.js              → "/"
  about/
    page.js            → "/about"
  blog/
    page.js            → "/blog"
    [slug]/
      page.js          → "/blog/any-post-name"

Nested routes

Just nest folders. app/dashboard/settings/page.js gives you /dashboard/settings. That's it.

Dynamic routes

Wrap a folder name in square brackets:

app/blog/[slug]/page.js

Now /blog/hello-world, /blog/my-first-post — all route to the same component. The slug is passed as a prop.

If you've used React Router before, this replaces:

// Old React Router way
<Route path="/blog/:slug" element={<BlogPost />} />

With just... a folder.

Server Components vs Client Components

This is the most important concept in Next.js.

Server Components (Default)

Run on the server
Faster performance
Smaller bundle size
Can directly fetch data

Client Components

Use this at the top:

"use client"

Needed when you use:

State (useState)
Effects (useEffect)
Event handlers (onClick, etc.)

👉 Rule of thumb:

Default = Server Component
Add "use client" only when needed

Styling in Next.js

Next.js supports multiple styling approaches out of the box:

Global CSS — globals.css, applied app-wide via layout.js
CSS Modules — Button.module.css, scoped to a single component (no class name conflicts)
Tailwind CSS — Works great with Next.js, can be set up during project creation

If you already know Tailwind basics, it integrates seamlessly.

🛠 Running & Building

Basic commands:

npm run dev     → development
npm run build   → production build
npm run start   → run production server

Important understanding:

dev = fast, for development

build + start = optimized, for production

🌍 Why Next.js is Used in Real-World Projects

Because it gives:

SEO-ready: Server rendering means search engines can read your content
Performance: Automatic code splitting, image optimization, caching
Full-stack in one project: No need for a separate Express/Node backend for basic APIs
Vercel deployment: One-click deploy, zero config (Next.js is made by the Vercel team)
Scales well: Used by large companies like Vercel, TikTok, Twitch, and many others

👉 Companies don’t want to configure everything manually; they want a production-ready system.

Quick Recap

Concept	One-Line Summary
Next.js	React + routing + SSR + API routes
App Router	Modern file-based routing in `app/`
Server Component	Renders on server, default in App Router
Client Component	Runs in browser, needs `"use client"`
File-based routing	Folder = Route
`npm run build`	Creates production-ready app

Final Thoughts

So to summarize, today was about understanding:

Why frameworks exist
Why React alone isn’t always enough
How Next.js changes the way we think about frontend

👉 Biggest takeaway:

Next.js is not just a tool, it’s a different way of building web apps.

Thanks for reading. Feel free to share your thoughts!

Forem: M Saad Ahmad

Day 61 of #100DaysOfCode — Python Refresher Part 1

Core Syntax

Variables & Data Types

Conditionals (if/elif/else)

Loops (for, while)

Functions

Data Structures

Lists

Dictionaries

Must Know:

Looping through dicts

Nested data handling

Sets

Tuples

Loops & Iteration

Functions

Working with JSON (IMPORTANT FOR BACKEND)

Basic File Handling

List Comprehension (VERY USEFUL)

Final Thoughts

Day 60 of #100DaysOfCode — Deploying the Task App

Why Vercel?

Steps Followed

Gotcha: MongoDB Atlas Network Access

What I Learned

Live App

Day 59 of #100DayOfCode — Styling the Task Management App

What I Used

Setting Up Shadcn

What I Styled

Using Button with asChild

Key Takeaway

Day 58 of #100DayOfCode — Building Task Management CRUD App with Next.js

What I Built

🛠 Concepts Used

Folder Structure

The Interesting Part — actions/tasks.js

Server actions receive FormData, not plain objects.

MongoDB _id is an ObjectId, not a string.

revalidatePath and redirect are required.

Serialization is needed when returning data.

What I Struggled With

Conclusion

What's Next

Day 57 of #100DayOfCode — Understanding Server Actions vs API Routes & MongoDB in Next.js

What Are Server Actions in Next.js?

Key Idea:

Example: Simple Server Action

Server Actions vs API Routes in Next.js

When to Use What?

Use Server Actions When:

Use API Routes When:

Connecting MongoDB with Next.js

MongoDB with Server Actions

💻 Example:

MongoDB with API Routes

💻 Example:

Conclusion

Day 56 of #100DayOfCode — Next.js API routes

React.js + Node.js vs Next.js

In MERN:

In Next.js:

📁 Folder Structure (App Router Way)

HTTP Methods in Next.js API Routes

Request & Response Handling

Basic Example:

Access Request Data:

Connecting Frontend to API

Dynamic API Routes

Access params:

🛡️ Basic Validation & Error Handling

Database Integration

🔥 Why This Is Powerful

Key Takeaways

Final Thoughts

Day 55 of #100DayOfCode — Data Fetching and Caching in NextJS

Data Fetching: React vs Next.js

How React Fetches Data

How Next.js Fetches Data

Conditionals (`if/elif/else`)

Loops (`for`, `while`)

Using `Button` with `asChild`

The Interesting Part — `actions/tasks.js`

Server actions receive `FormData`, not plain objects.

MongoDB `_id` is an `ObjectId`, not a string.

`revalidatePath` and `redirect` are required.

Use `force-cache` for content that rarely changes

Use `revalidate` (ISR) for content that changes occasionally

Use `revalidatePath` for content driven by user actions or a CMS

Use `no-store` for data that must always be live

The Interesting Part: `[slug]` Dynamic Routing

`page.js`

`layout.js`

`loading.js`

`error.js`

`not-found.js`

`useRouter()`

`usePathname()`

Why use `<Link>` instead of `<a>`?

Why use `<Script>` instead of traditional script tags?

What makes `<Image>` special?