Forem: Athashri Keny

Next.js SSR vs CSR vs SSG which is best to use and when to use?

Athashri Keny — Wed, 21 Jan 2026 03:37:54 +0000

These names feels confusing first, but when you understood it deeply its much easier than you think!

SSR (Server-Side Rendering) ,CSR(client Side Rendering) , SSG(Static Side Generation). These all are web page rendering methods

Let's first dive in
SSR: In SSR(Server-Side rendering) server renders the full html for every request and sends it to the browser. because it is rendered on server not in the client side ie in Brower the page loads quickly.

pros: SSR is great when you want a good SEO rating on your webpage. For eg news websites , landing pages . but there is a catch you need to have a good server which is capable of handling a ton of requests.

Cons: Due to heavy load on server these can can cost you a good amount of server bills.

CSR: (client side rendering) In CSR, the server sends a minimal HTML shell to the browser. JavaScript then runs in the browser to fetch data and render the content dynamically.
After the page has been loaded for the first time, navigating to other pages is typically faster because it doesn't require a full page reload - only the necessary data is fetched via API calls, and JavaScript updates the DOM dynamically.

pros: CSR is great if your data changes consistently on a page. and you don't care about SEO at all. CSR can be used in fetching user data , a live score match etc. and server load is less.

Cons: Slow initial load. your app takes a noticeable amount of time to load user can feel this.

SSG: In SSG (Static Site Generation), HTML pages are pre-built at build time (during deployment), not at runtime. These pre-rendered HTML files are served to users on every request, without needing to generate them again.

pros: SSG offers a fast-performance , excellent seo, reduces server load (this can be lead to lower server bills).

Cons: All pages are built at the time of the build so this can cause a longer built time, and the content is only updated when site is build again.

Final Thoughts
Choose based on your needs:
Need SEO + real-time data? → SSR
Building an interactive app? → CSR
Content rarely changes? → SSG

Thanks for reading i hoped it helped you!

Why useSession() Is undefined on First Load in Next.js When Deployed to Production (and how i fixed it)

Athashri Keny — Wed, 14 Jan 2026 21:03:49 +0000

When I deployed my SaaS (Next.js app) to production, I noticed something strange. On the first load, my console showed session undefined, but when I refreshed the page (for example /dashboard), everything worked perfectly. Even more confusing, this never happened on localhost—it only happened in production. At first, I thought my auth token was broken, but it turned out it wasn’t. This blog explains what was actually happening, why this bug appears only in production, and how to fix it properly.

The setup I was using was very common: Next.js (App Router), NextAuth, useSession() on the client, and a protected dashboard page.

he problem appeared on the initial page load. I had the following code:
const { data: session } = useSession(); console.log(session);

The output was undefined. However, after refreshing the page, the output became { user: {...}, expires: "..." }. This raised the main question: why is the session undefined on first load but works after refresh?

The real reason is that useSession() is asynchronous. This was the key thing I misunderstood at first. When the page renders, React renders components immediately, and at the same time useSession() starts fetching the session. At that moment, the session is not available yet, so console.log(session) prints session = undefined with status = "loading". This is expected behavior.

This issue does not usually appear on localhost because of speed differences. On localhost, the app is slower, so the session often resolves early before you notice the problem. In production, the app loads much faster, so the render happens before the session is ready, which exposes the issue.

The correct fix on the client side starts with always checking the session status:

const { data: session, status } = useSession();

if (status === "loading") {
  return null;
}

if (!session) {
  redirect("/login");
}

The second important fix is guarding your useEffect so it does not run before the session exists:

useEffect(() => {
  if (!session) return;

  fetchBills(session.user.id);
}, [session]);

The big lesson I learned from this is that rendering happens before async data is ready, so you should always assume undefined at least once. This does not apply only to useSession(), but also to API calls, database fetches, React Query, and any asynchronous data in React.

Production bugs don’t mean you’re bad—they mean you’re learning real-world development.

Thanks for reading. If this helped you, feel free to share or connect with me.
Athashri Keny

Deploying Full-Stack Next.js Apps: Vercel vs Render Comparison

Athashri Keny — Sun, 11 Jan 2026 10:20:50 +0000

Hello I am Athashri Keny a full stack web developer , i have created and deployed many full stack projects

In my Journey and there is my personal opinion which is better

Choosing the right deployment platform can make or break your portfolio project. After deploying dozens of Next.js apps, here's what you need to know about Vercel vs Render.

Vercel:

I am using vercel since long time for deploying and its best platform as specially if you are student or working professional Want College Projects to be deployed At free of cost. Vercel free tier is for you ie vercel hobby plan and trust me that’s enough for you unless you have a bigger projects with such as video streaming platform or such heavy projects. In my opinion pick vercel when you have modern frontend (react , Vue) etc And you prioritize speed.

Render:

I tried render when i was in early stage of my learning full stack development in fact my first project i deployed was on render only. Render gives all over the control of the backend. The best part of render i think i that the Always on web-services (no cold starts) But there is a catch Render free tier Always on web-services can shutdown due to inactivity leading to cold starts when opening. This is the worst part of render i think cause if you are student and the recruiter opens the your projects and its inactive for longer period of time leading to slow starts of opening that’s the bad impression to recruiter

Conclusion
If you are building a modern frontend-heavy Next.js app and want fast deployments with minimal setup, Vercel is the best choice.
If you need more backend control and always-on services for APIs, Render can be a good option, but the free tier has limitations.
For students and portfolio projects, I personally prefer Vercel because of speed, simplicity, and reliability.