DEV Community: Parth Bhovad

CSR SSR SSG and ISR Rendering Methods Explained

Parth Bhovad — Sun, 20 Sep 2026 10:21:03 +0000

Many developers still get confused about the different rendering methods available today. Let's understand how each method works and when you should choose it. (Especially if you are using NextJS).

Here's a simple and better explanation:

Let's first understand what rendering means.

Rendering is the process of converting your application code and data into the actual UI that users see in their browser.

CSR (Client-Side Rendering):

In CSR, rendering happens entirely in the browser. When a user visits a page, the browser sends a request to the server, and the server responds with a single html file which contains only an empty div element in it and a huge JS bundle. At the initial phase, the browser only has html file with all the rendering, routing, data fetching logic in a JS bundle. The browser executes the JS bundle and then does the entire rendering part. The JS bundle handles the DOM manipulations, client-side routing, data fetching each and everything inside browser. These applications are known as SPAs (Single Page Applications).

Advantages: Faster navigation between pages, client-side interactivity support.

Disadvantages: Search engines can execute JavaScript, but CSR applications often take longer to crawl and index, making SEO more challenging compared to SSR or SSG. So, SEO issues are there in CSR. Another disadvantage is that browser gets huge JS bundle in initial request which makes the first page load very slow for SPAs applications.

When to use: Internal dashboards or applications which not going to require SEO. Or if you are using NextJS and you need some client-side features, then you can embed a small client component inside a server component.

SSR (Server-Side Rendering):

In SSR the rendering part happens at server side. When a user visits a page, the browser sends request to the server, the server does the rendering part, fetch data from the API (if any), and sends complete html as a response to client. The initial HTML is rendered on the server and sent to the browser. After hydration, React adds client-side interactivity, allowing users to interact with the page normally.

Advantages: The server sends ready-to-render HTML with all content so google crawler can crawl and index pages. Good for SEO. Users see meaningful content sooner because the server sends pre-rendered HTML, improving perceived performance and SEO.

Disadvantages: No client side features. But you can embed a small client component into a server component (if you are using NextJS). For e.g. a button for click events.

When to use: When you need SEO, also cares about first loading time of your application.

SSG (Static Site Generation):

In SSG the rendering part of any web page happens at the build time, and the generated HTML is created during the build process and served as a static file for every request. Whenever user clicks on any SSG page the server directly returns the pre-build html page from cache without rendering it at every request.

Advantages: Pages are rendered once during the build process. Which saves cost and improves performance. Also, the pages are shown to user at higher speed.

Disadvantages: If any page content changed then it won't reflect on the page as it is rendered at build time. In such case you can use ISR via time-based revalidation or on-demand revalidation.
When to use: When your page data rarely changes.

ISR (Incremental Static Regeneration):

ISR allows static pages to be regenerated after deployment through either time-based revalidation or on-demand revalidation. This allows users to receive cached static pages while the content is automatically regenerated through time-based or on-demand revalidation.

Advantages: You can use revalidation techniques of NextJS to revalidate the cache and show the updated.

Disadvantages: If your data changes often and it is important to always show updated data then ISR may not work for you.

When to use: Pages or data which do not change often or stay same for a longer time. Best e.g. Blogs.

Conclusion

All these rendering methods are still very new, and many beginner developers find it difficult to understand and use it where it makes sense. The implementation of each of this rendering methods are different in different frameworks, but the overall concept is still the same.

Should you use your Own auth or use third party Auth Providers

Parth Bhovad — Sun, 06 Sep 2026 16:28:31 +0000

You may have confusion about what's the best approach for implementing Authentication in your application. There are lots of people who may say "you should build your own Auth" because it gives you control, third party tools can be expensive and it creates unnecessary dependencies.

But in reality, it depends. Both your own auth and third party auth solution is good, depending upon the use case.

Typically, the software can be divided into 3 phases. And what approach to choose depends on in which phase your software belongs to.

Phase 1: ~ 0–100 users

You have no idea whether even a single user is interested in your app or not. You are just starting out. We can consider here that only around 0–100 users will be there on your application.

In this phase your goal is to take a bet on yourself and do one experiment to validate your app. Your goal should be building the most core functionality as soon as possible. In such case investing your time in building your own Auth doesn't make sense at all. You don't have users yet, you don't know your idea will even work or not. So, it's better use any third party auth provider like Better Auth/Clerk. It will save your time.

Phase 2: ~ 101–10,000 users

Here you have validated your application. There are good number of users already using your app. Or you are scaling your app from phase 1 to phase 2. We can consider here that around 101 to 10,000 users are using your application.

Even in this case it's better to go with external Auth Providers. Because your focus should be in scaling the app. The user cares about features and experience of your application.

Complexity

Building an authentication system is not just about Login, Signup, forgot password. There is lot more than that. You need to build APIs, knowledge of encryption, security, scalability and there is the entire user management. Another reason to avoid creating an authentication system is that there are already great ones available. Just pick any one of them.

Phase 3: ~ 20,000 or more

Your application is very huge with lots of users, and it is a Giant Application. Your application is serving 50k+ users. At phase 3 it might make sense to implement your own auth.

I prefer to not talking much about phase 3 because it is out of the scope of my expertise.

Conclusion:

There are phases where you should implement your own auth. But if you are starting out or in the 2 phase you should be more concerned about building your software and monetizing it rather than wasting hours implementing your own auth, which again not going to give you anything special.

5 ways to improve your prompts to take less energy and tokens

Parth Bhovad — Mon, 31 Aug 2026 14:41:44 +0000

Most people (including I) do very silly mistakes while writing prompts, and we end up spending more tokens than actually needed. You don't have to put lot of efforts to optimize your prompts. Even with ensuring these basic things you can get a significant effect.

Be Specific: Clearly state what you want in your prompt (e. g. "Summarize in 3 bullet points" instead of just "Summarize"). This reduces back-and-forth and saves energy.
Set Boundaries: "In under 200 words" instead of keeping it vague.
Choose your verb carefully: Words like "explain" or "justify" tend to trigger longer responses and use more energy. When a short answer will do, try "summarize," "list," or "classify" instead.
Skip polite filters: Avoid words like please, kindly, or thank you as they add extra tokens.
Be specific about the output: "Python function for factorial" instead of "write me some code about factorials".

That's it. There are lots of information on the internet available about improving prompts to take less tokens. But most of them are not practical to implement. So, I thought to make a simpler compiled version of it that is easy and still have good effect.

React Keys and Lists - Explained!

Parth Bhovad — Sun, 02 Aug 2026 16:16:41 +0000

Whenever you worked with rendering lists of DOM elements in React.js you have encountered this error. And most probably you solve this error in wrong way. Let me explain what's the correct approach!

import { useState } from 'react'

type USER = {
  id: number,
  name: string
}

const usersData: USER[] = [
  {
    id: 1,
    name: "user 1"
  },
  {
    id: 2,
    name: "user 2"
  },
  {
    id: 3,
    name: "user 3"
  },
  {
    id: 4,
    name: "user 4"
  },
  {
    id: 5,
    name: "user 5"
  }
]

function ShowUsersList() {
  const [users, setUsers] = useState(usersData);

  return (
    users.map((user) => (
      <div>
        {user.name}
      </div>
    ))
  )
}

export default ShowUsersList

This is the code you wrote and got this error. The problem with this code is you haven't provided key prop to lists of divs. React needs to identify each list item uniquely. To do so it requires unique key prop.

To solve this error most people, use a quick but wrong solution to hide this error by writing code like this:

function ShowUsersList() {
  const [users, setUsers] = useState(usersData);

  return (
    users.map((user, idx) => (
      <div key={idx}>
        {user.name}
      </div>
    ))
  )
}

export default ShowUsersList

But here's a catch, by doing these you will face performance issues. Especially when your list items can move (e.g. due to sorting), update, insert, or get deleted. A uniquely chosen key helps React understand exactly which item in the list get updated and make the correct updates in DOM tree more efficiently.

This also mentioned in the React's Official documentation:

Let's check practically what happens when you add item’s index in the array as its key.

In case you are deleting list items:

function ShowUsersList() {
  const [users, setUsers] = useState(usersData);

  const handleDelete = (id: number) => {
    const filteredItems = users.filter((user) => user.id !== id);
    setUsers(filteredItems);
  }

  return (
    users.map((user, idx) => (
      <div key={idx} onClick={() => handleDelete(user.id)}>
        {user.name}
      </div>
    ))
  )
}

When you click any of the list items and see the change in Developer's tool Elements tab, every list item's get highlighted. Which means by deleting 0th list items only, each and all list items get re-rendered.

But when you assign consistent IDs to key prop:

function ShowUsersList() {
  const [users, setUsers] = useState(usersData);

  const handleDelete = (id: number) => {
    const filteredItems = users.filter((user) => user.id !== id);
    setUsers(filteredItems);
  }

  return (
    users.map((user) => (
      <div key={user.id} onClick={() => handleDelete(user.id)}>
        {user.name}
      </div>
    ))
  )
}

Only the deleted item gets removed and nothing else get re-rendered by React.

This is happening because when you use item’s index in the array as its key, the key value for every item gets changed at run-time. And for React its completely different list of items. So, React re-renders everything.

The better way is to use unique ID which is consistent (e.g ID you will get from DB).

The correct code is:

import { useState } from 'react'

type USER = {
  id: number,
  name: string
}

const usersData: USER[] = [
  {
    id: 0, //ID from DB 
    name: "user 0"
  },
  {
    id: 1,
    name: "user 1"
  },
  {
    id: 2,
    name: "user 2"
  },
  {
    id: 3,
    name: "user 3"
  },
  {
    id: 4,
    name: "user 4"
  }
]

function ShowUsersList() {
  const [users, setUsers] = useState(usersData);

  return (
    users.map((user) => (
      <div key={user.id}>
        {user.name}
      </div>
    ))
  )
}

export default ShowUsersList

Note: Even if you didn't provide any key prop to lists of items, React will automatically use item’s index in the array as its key. Which is wrong method.

That's all about using Keys and Lists in React. I would recommend you refer React's Official Documentation to know more details about Keys in React.
You can access the source code for the code used in this explanation. You check everything on your own and really grasp this concept of React because this is really the core fundamentals of React.

How to generate dynamic sitemap in NextJS?

Parth Bhovad — Fri, 24 Jul 2026 06:41:55 +0000

Earlier I used to manage sitemap manually in NextJS. And I end up forgetting to update the sitemap whenever I add/remove any pages from my website. But now I don't have to remember updating the sitemap. I write dynamic sitemap code once and no need to look at it afterwards.

Here's how you can do it:

There are 2 types of routes you have to add in NextJS sitemap.

Public routes paths
Dynamic routes paths

Both routes should be kept in NextJS route groups. This is not a rule. We are doing this because we are going to traverse your NextJS code directory to find all the pages you want to add in sitemap. So, the traverser will be easier if you keep all the public pages in one route groups. There are 2 benefits of using this approach. Firstly, it will be better for your project folder structure. All the public pages will be inside one directory only. Also, it will make the traversal logic easier to implement.

Divide private and public pages using NextJS route groups. Once you have your folder structure like the above image, use the following function to which returns array of paths of all public routes.

import fs from "fs";
import path from "path";

export function findPublicPagesPath() {
    const appDir = path.join(process.cwd(), "src", "app", "(public)"); //keep all of your pages you want to add in sitemap inside this directory
    const routes: string[] = [];

    function traverse(currentDir: string) {
        const entries = fs.readdirSync(currentDir, {
            withFileTypes: true,
        });

        for (const entry of entries) {
            const fullPath = path.join(currentDir, entry.name);

            if (entry.isDirectory()) {
                traverse(fullPath);
                continue;
            }

            if (entry.isFile() && entry.name === "page.tsx") {
                const relativePath = path.relative(appDir, fullPath);

                let route = relativePath
                    .replace(/\\/g, "/")
                    .replace(/\/page\.tsx$/, "")
                    .replace(/^page\.tsx$/, "");

                // remove route groups: (marketing), (auth), etc.
                route = route
                    .split("/")
                    .filter(segment => !/^\(.*\)$/.test(segment))
                    .join("/");

                // Exclude [id] dynamic routes
                if (route.includes("[") || route.includes("]")) {
                    continue;
                }

                routes.push(route ? `/${route}` : "/");
            }
        }
    }

    traverse(appDir);

    return routes;
}

Example output from this function:

[ '/about', '/contact', '/' ]

For dynamic routes you have to fetch all of the slugs/IDs from your DB and pass it to sitemap.

const posts: Post[] = await fetch(
        "https://jsonplaceholder.typicode.com/posts"
).then(res => res.json());

For the sake of simplicity, we are using dummy API to fetch all the dynamic routes slugs/IDs. The response from this API will look like this:

[
  {
    "userId": 1,
    "id": 1,
    "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
    "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
  },
  {
    "userId": 1,
    "id": 2,
    "title": "qui est esse",
    "body": "est rerum tempore vitae\nsequi sint nihil reprehenderit dolor beatae ea dolores neque\nfugiat blanditiis voluptate porro vel nihil molestiae ut reiciendis\nqui aperiam non debitis possimus qui neque nisi nulla"
  },
  {
    "userId": 1,
    "id": 3,
    "title": "ea molestias quasi exercitationem repellat qui ipsa sit aut",
    "body": "et iusto sed quo iure\nvoluptatem occaecati omnis eligendi aut ad\nvoluptatem doloribus vel accusantium quis pariatur\nmolestiae porro eius odio et labore et velit aut"
  },
  {
    "userId": 1,
    "id": 4,
    "title": "eum et est occaecati",
    "body": "ullam et saepe reiciendis voluptatem adipisci\nsit amet autem assumenda provident rerum culpa\nquis hic commodi nesciunt rem tenetur doloremque ipsam iure\nquis sunt voluptatem rerum illo velit"
  },
...
]

Once you have this 2 of arrays of routes you can use this code of dynamic sitemap:

import type { MetadataRoute } from 'next'
import { findPublicPagesPath } from './findPublicPagesPath';

type Post = {
    id: number;
};

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {

    // src/app/(public) public routes
    const paths = findPublicPagesPath();

    const publicPagePaths: MetadataRoute.Sitemap = paths.map((path: string) => ({
        url: `https://acme.com${path}`,
        lastModified: new Date()
    }))

    // src/app/blog/[id] dynamic routes
    const posts: Post[] = await fetch(
        "https://jsonplaceholder.typicode.com/posts"
    ).then(res => res.json());

    const dynamicRoutes: MetadataRoute.Sitemap = posts.map((post: { id: number }) => ({
        url: `https://acme.com/blog/${post.id}`,
        lastModified: new Date(),
    }));

    return [
        ...publicPagePaths,
        ...dynamicRoutes
    ]
}

This sitemap code will give you following output:

One thing to note is sitemap.js is a special Route Handler that is cached by default. So, you need to configure your caching according to it.

How you will implement caching depends upon whether you are using Caching and Revalidating (Previous Model) or Cache Components. Feel free to refer these docs and add caching as per your use cases.

Along with simply listing URLs in sitemap items, you can give additional metadata information like when was the page last modified, priority of page, changeFrequency and more. Here's a complete type definition for a sitemap item:

type Sitemap = Array<{
  url: string
  lastModified?: string | Date
  changeFrequency?:
    | 'always'
    | 'hourly'
    | 'daily'
    | 'weekly'
    | 'monthly'
    | 'yearly'
    | 'never'
  priority?: number
  alternates?: {
    languages?: Languages<string>
  }
}>

That's all what you have to do in a nutshell!

here's the source code

I tried using a colorful gradient background for screenshots in my posts. And here's why everyone should use it (hint: it increases the reach of posts)

Parth Bhovad — Sat, 02 May 2026 17:03:51 +0000

Firstly, I saw big creators use gradient background in their post's screenshots. I didn't understand why they were doing this.

Later I read somewhere that gradient colours are easy to capture attention and that's why creators were using it.

So, I also started doing the same. And it Also increased engagement rates, likes and impressions on my posts. And I recommend you all do the same.

Initially,

I was using Canva to create gradient background screenshots. But it was very time consuming to do it every time from Canva.

That's why I started searching for tools for this specific use only.

But all the tools I found have too many features, bad UIUX, and a watermark.

At the end, I built my own as per my needs. A minimalist screenshot beautifying tool which only has padding and radius adjustment options with some beautiful gradient background and images. You can add your custom background image too.

To conclude: I would say use any tool/method you want to create eye catching screenshots. You can use my tool or any other you find useful for yourself. But do it. It increases output you will get from your posts by just putting minimal extra effort.

Here you will find the tool BeautifulScreenshots you should give a try to it and then use what you will find good for yourself. But start using a gradient background. You will thank me later.

Indian rupee is getting weak. Is it good for developers?

Parth Bhovad — Sat, 21 Mar 2026 17:52:31 +0000

For a few days I've been hearing a lot about Indian currency vs Dollar. Some people say it is bad, some say it is good. But most of them are not giving genuine reasons for their claims.
In the context of Developers I think it is good news. Because a lot of developers I know are earning in dollars. So, by the end of the month they will earn the same dollar, but more in rupees.
I don't know how it will affect those who are in an Indian based company. I would like to dive more deep into this topic.
This is debatable.

I'm Trying No AI Assisted Coding...

Parth Bhovad — Sun, 15 Mar 2026 17:43:40 +0000

First of all, I started GitHub Copilot when I got enough confidence on my logic building. And it was a right decision. Autocompletions helping me to get my work done fast.

There is no problem in it. At all! Autocompletions helping me to focus on bigger problems and delegating small, repetitive logic to copilot.

But here's a catch. After few months of using this Autocompletions I forgot the syntax completely. There is no problem in not knowing the syntax (I was thinking this).

But when I started applying for Internships, in almost all interviews their basic requirements is knowing syntax. Interviewers give you a small task, and you have to write the code in normal online compiler. No autocompletions.

And in these situations, my mind gets blank. Since I'm not used to knowing how to write an Array.filter(), Array.reduce(). I know the working of them, but writing without autocompletions is something I can't be able to do.

I can build any application end to end. But with autocompletions handling easy, syntax heavy, repetitive tasks.

And the interviewer won't believe. Gives a bad impression. Like I can't even solve a basic problem just because I don't know the syntax.

So, I started spending some of time without using Autocompletions. And my muscle memory is coming back now.