DEV Community: Sheetal Sindhu

API Caching with Next.js

Sheetal Sindhu — Mon, 14 Apr 2025 06:36:11 +0000

🧠 Caching API Responses in Next.js: ISR, SSR, and Edge Cache Deep Dive

AKA how not to burn your server and your bandwidth bill.

1. ISR (Incremental Static Regeneration)

“Let’s pretend the page is static… until it’s not.”

🧐 What is it?

It’s like saying, “Build this page ahead of time, but if someone visits it and it’s stale, quietly build a new one in the background.”

Users get lightning-fast static pages, and you still serve semi-fresh data.

🧪 Use case:

Blog posts, product pages, anything that doesn’t change every second.
Need data to be updated every X seconds/minutes? Use ISR.

🧠 How you tell Next.js:

fetch('https://api.com/data', {
  next: { revalidate: 60 }  // “Yo Next.js, refresh this every 60 seconds.”
})

⚡ Magic:

First request gets old content.
In the background, it regenerates the page.
Second user gets the shiny new version.
You? You chill. No full rebuilds needed.

🧓 Wisdom:

“It’s static. But cooler. And lazier. Just like most devs on Fridays.”

2. SSR (Server-Side Rendering)

“I want the latest data. No excuses. Build it now.”

🧐 What is it?

Every request = fresh page from the server. No caching unless you manually cache.

Feels like 2005 with smarter tooling.

🧪 Use case:

Dashboards, admin panels, analytics.
Stuff where you’d be yelled at if stale data shows up.

🧠 How you tell Next.js:

fetch('https://api.com/live', {
  cache: 'no-store'  // “Don’t even *think* about caching this.”
})

export const dynamic = 'force-dynamic' // Force SSR even if you forget something

⚡ Magic:

User hits the page.
Server panics, builds everything fresh.
You serve up-to-date data at the cost of a few milliseconds and CPU tears.

🧓 Wisdom:

“If your data changes every second and you still use static... we need to talk.”

3. Edge Caching (aka CDN-fu)

“Let’s render stuff closer to the user... like psychic fast.”

🧐 What is it?

Next.js deploys your logic on the Edge runtime (yes, like on Cloudflare or Vercel’s Edge Network). You slap a Cache-Control header, and now your data is cached at 200+ locations globally.

🧪 Use case:

Geo-personalized pages
High-traffic, low-latency API responses
“We’re going viral and can’t afford latency!”

🧠 How you tell Next.js:

export const runtime = 'edge'

return Response.json(data, {
  headers: {
    'Cache-Control': 'public, max-age=120'  // Cache at edge for 2 mins
  }
})

Or use:

fetch('https://api.com/edge-stuff', {
  next: { revalidate: 120 }  // Same as ISR, but you’re doing it from the edge
})

⚡ Magic:

Requests go to the nearest edge server.
Responses get cached there.
Users around the globe say “wow”.
Your backend server sighs in relief.

🧓 Wisdom:

“Why fight latency when you can cache globally and sip your coffee in peace?”

🧾 TL;DR Table (Sticky Note Version)

Strategy	Use When	Freshness	Speed	Config
ISR	Static-ish data	Revalidates on interval	⚡ Fast	`revalidate: 60`
SSR	Real-time data	Always fresh	🐢 Slow-ish	`cache: 'no-store'` + `dynamic: 'force-dynamic'`
Edge	Global + fast data	Configurable	⚡⚡⚡ Ridiculously fast	`runtime: 'edge'` + `Cache-Control`

🚀 Pro Tips (a.k.a. “You’ll thank me later”)

API Route + ISR = amazing if you want to cache data responses instead of pages.
revalidateTag() = revalidate specific pages or APIs when something changes (Next.js 13.4+).
Dev mode lies – caching doesn’t behave exactly in dev. Always test in production/staging.
Avoid cache: 'force-cache' unless you know what you’re doing. It’ll aggressively cache everything like it’s hiding gold.

The Art of Writing Reusable React Components with TypeScript (2025 Edition)

Sheetal Sindhu — Tue, 08 Apr 2025 12:29:34 +0000

In 2025, React 19 and the latest TypeScript 5.x releases have refined how we craft applications — especially when it comes to building reusable, scalable components.

Reusable components aren't just about DRY (Don't Repeat Yourself); they're about architecture, type safety, performance, and developer experience. In this guide, we'll dive deep into how senior frontend engineers approach reusable React components today, leveraging the newest patterns.

Why Focus on Reusability?

Before we dive into code, here’s why reusable components are critical:

Scalability: Future teams can build faster without reinventing the wheel.
Consistency: Enforces design systems, UX patterns, and coding standards.
Maintainability: Easier to debug, enhance, and refactor across large codebases.
Performance: Reusable components tend to get more optimization love.

What's New in React 19 and TypeScript (2025)?

✨ React 19 Updates:

New <use> Hook (for resource loading like suspense + fetch)
React Compiler (formerly React Forget): Auto-memoizes components for free
Actions API (built-in server actions natively, cleaner forms)
Document Metadata API (first-class SEO/head management)

✨ TypeScript 5.x+ Updates:

Variadic Tuple Types (better prop typing for complex components)
Satisfies Operator (guaranteed type narrowing)
Const Type Parameters (preserve literal types without widening)
New using keyword (for scoped resource management)

How to Write Reusable Components

Let’s break this down practically:

⸻

1. Define Clear Component Boundaries

Before writing a reusable component, ask yourself: What is this component responsible for?

Keep it small and focused.
A component should do one thing and do it well.
Follow the principle: smart containers, dumb components.

Example: Don't mix a Button and an API call inside the same component.

⸻

2. Use Generics for Flexibility

In TypeScript 5.4+, generics are more powerful and easier to infer.

Make your components flexible using generics rather than hardcoding types.

type ListProps<T> = {
  items: T[];
  renderItem: (item: T) => React.ReactNode;
};

function List<T>({ items, renderItem }: ListProps<T>) {
  return <ul>{items.map(renderItem)}</ul>;
}

Now List can handle any data type safely!

⸻

3. Strong Prop Typing with `satisfies` (New!)

TypeScript’s satisfies operator (TS 5.x) allows extra type safety without losing flexibility.

const props = {
  label: "Submit",
  onClick: () => {},
} satisfies ButtonProps;

✅ Catches missing/invalid props at compile-time.

⸻

4. Prioritize Composition Over Configuration

Instead of 10+ props to control variations, compose components.

Good:

<Card>
  <CardHeader>Title</CardHeader>
  <CardBody>Content</CardBody>
  <CardFooter>Actions</CardFooter>
</Card>

Bad:

<Card title="Title" body="Content" footer="Actions" footerPosition="right" bordered shadow variant="primary" ... />

Small pieces > Big props explosion.

⸻

5. Default to Accessibility (a11y)

Make your component accessible by default.

Use semantic HTML (button, nav, section, etc.)
Provide aria-* attributes when necessary.
Label controls properly.
Support keyboard navigation.

Good UI = Good UX = Good a11y.

⸻

6. Use Modern Patterns (React 19 Era)

React 19 introduces new patterns:

useOptimistic hook for faster UI
actions and forms improvements
Server Components (RSC) are more stable

👉 Stay updated and leverage React 19 APIs where it makes sense.

Example:

Optimistic UI for a list without managing tons of local states manually.

⸻

7. Add Display Names for Better Debugging

Always set displayName for reusable components.

const Button = (props: ButtonProps) => { /* ... */ };
Button.displayName = "Button";

✅ Makes debugging easier in React DevTools, especially when components are deeply nested.

⸻

8. Optimize with Stable References

Unnecessary re-renders kill performance.

Use:

React.memo
useMemo
useCallback

for reusable components.

const MemoizedButton = React.memo(Button);

✅ Always think about referential stability when building for scale.

⸻

Bonus: Reusable Component Checklist ✅
• Is the typing clear and strict?
• Is it composable?
• Does it cover a11y basics?
• Can it be theme/styling agnostic?
• Is it ready for async/server side if needed?
• Does it avoid prop explosion?
• Does it leverage React 19 and TypeScript 5+ features?

⸻

Final Thoughts

Reusable components in 2025 are about clarity, composability, and confidence.

By harnessing React 19’s smarter compiler and TypeScript’s sharper type tools, you can build libraries that scale across teams, projects, and even products.

Good components are invisible — they just work.

Happy coding! 🚀

⸻

DEV Community: Sheetal Sindhu

API Caching with Next.js

🧠 Caching API Responses in Next.js: ISR, SSR, and Edge Cache Deep Dive

1. ISR (Incremental Static Regeneration)

🧐 What is it?

🧪 Use case:

🧠 How you tell Next.js:

⚡ Magic:

🧓 Wisdom:

2. SSR (Server-Side Rendering)

🧐 What is it?

🧪 Use case:

🧠 How you tell Next.js:

⚡ Magic:

🧓 Wisdom:

3. Edge Caching (aka CDN-fu)

🧐 What is it?

🧪 Use case:

🧠 How you tell Next.js:

⚡ Magic:

🧓 Wisdom:

🧾 TL;DR Table (Sticky Note Version)

🚀 Pro Tips (a.k.a. “You’ll thank me later”)

The Art of Writing Reusable React Components with TypeScript (2025 Edition)

Why Focus on Reusability?

What's New in React 19 and TypeScript (2025)?

How to Write Reusable Components

1. Define Clear Component Boundaries

2. Use Generics for Flexibility

3. Strong Prop Typing with satisfies (New!)

4. Prioritize Composition Over Configuration

5. Default to Accessibility (a11y)

6. Use Modern Patterns (React 19 Era)

7. Add Display Names for Better Debugging

8. Optimize with Stable References

3. Strong Prop Typing with `satisfies` (New!)