Building a Dynamic Blog with ISR: API-Driven Content and Fallback Strategies

In the world of web development, striking the perfect balance between dynamic content flexibility and static site performance can be a challenge. For blogs, this often means wanting the speed and SEO advantages of static generation without the hassle of rebuilding the entire site for every new post. This is where Incremental Static Regeneration (ISR) shines, especially when combined with API-driven content and thoughtful fallback strategies.

The Challenge: Dynamic Content, Static Demands

Traditional static site generators require a full rebuild whenever content changes. For a blog with frequent updates, this can become cumbersome and slow. On the other hand, purely server-rendered or client-rendered applications might sacrifice initial load performance and SEO benefits.

Modern frameworks like Next.js offer a powerful solution: ISR. ISR allows you to build and deploy a static site, but then update individual pages incrementally at runtime, without needing a full redeploy. This is particularly potent when your blog articles are stored in a headless CMS or a custom API.

What is Incremental Static Regeneration (ISR)?

ISR is a technique that enables you to update static content after your application has been built and deployed. Instead of regenerating the entire site, ISR allows you to define a revalidation period for individual pages. When a request comes in for an outdated page, the cached version is served immediately, and a regeneration process is initiated in the background to fetch the latest data and update the cache for subsequent requests.

Key Benefits of ISR:

• Performance: Pages are served instantly from a cache, offering static-like speed.
• SEO: Search engines prefer fast-loading pages, and ISR delivers pre-rendered HTML.
• Scalability: Reduces server load by serving cached content, regenerating only when necessary.
• Developer Experience: Deploy once, update content dynamically through your API without redeployments.

Loading Articles from an API

The core of a dynamic blog built with ISR is fetching your article content from an external API. This API could be a headless CMS (e.g., Strapi, Contentful, Sanity), a custom backend, or even a simple JSON file served over HTTP.

Let's consider a typical Next.js setup for fetching blog posts:

// pages/blog/[slug].js

import { useRouter } from 'next/router';
import ErrorPage from 'next/error';

export default function BlogPost({ post }) {
  const router = useRouter();

  // If the page is not yet generated, show a loading state
  if (router.isFallback) {
    return <div>Loading article...</div>;
  }

  // Handle 404 if post is not found
  if (!post) {
    return <ErrorPage statusCode={404} />;
  }

  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.date}</p>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );
}

export async function getStaticPaths() {
  // Fetch all possible article slugs from your API
  const res = await fetch('https://your-api.com/articles/slugs');
  const slugs = await res.json();

  const paths = slugs.map((slug) => ({
    params: { slug },
  }));

  return { paths, fallback: true }; // 'fallback: true' is crucial for ISR
}

export async function getStaticProps({ params }) {
  const res = await fetch(`https://your-api.com/articles/${params.slug}`);
  const post = await res.json();

  if (!post) {
    return { notFound: true };
  }

  return {
    props: { post },
    revalidate: 60, // Revalidate every 60 seconds (or adjust as needed)
  };
}

In this example:

• getStaticPaths fetches all known article slugs at build time. fallback: true tells Next.js that pages not generated at build time should be handled by ISR.
• getStaticProps fetches the data for a specific article using its slug. The revalidate: 60 property is the magic behind ISR, instructing Next.js to re-generate the page in the background if a request comes in more than 60 seconds after the last generation.

The Importance of Fallback Content

When fallback: true is set in getStaticPaths, Next.js behaves in a specific way for paths that weren't pre-rendered at build time:

1. First Request: If a user requests a page that hasn't been generated yet (e.g., a brand new article added after the last deployment), Next.js will immediately serve a