Can ISR and dynamic rendering coexist for the same dynamic route pattern?

[X-Zero-L]

Summary

I have a dynamic route post/[id] where some IDs should use ISR for static generation, while others require authentication checks and should remain dynamic. Is it possible to have mixed rendering strategies within the same route pattern?

Additional information

No response

Example

No response

[ahuaiqom]

Hi @X-Zero-L 👋

Yes they can coexist. In the App Router you can make the default for a route ISR, and opt-out per request to dynamic when the id requires auth.

How to wire it
`// app/post/[id]/page.tsx
import { cookies } from "next/headers";
import { unstable_noStore as noStore } from "next/cache";
import { redirect } from "next/navigation";

export const revalidate = 300; // ISR by default
export const dynamicParams = true; // allow ids not prebuilt

export async function generateStaticParams() {
// prebuild only the public ids
const publicIds = await getPublicIds();
return publicIds.map(id => ({ id }));
}

export default async function Page({ params }: { params: { id: string } }) {
const { id } = params;

// Look up metadata to decide if this id is private
const meta = await fetch(${API}/posts/${id}/meta, { next: { revalidate: 300 } }).then(r => r.json());

if (meta.private) {
// 🔒 Make THIS request fully dynamic (no caching/ISR)
noStore();
const session = await getSessionFrom(cookies());
if (!session) redirect("/login");
const data = await fetch(${API}/posts/${id}, { cache: "no-store" }).then(r => r.json());
return ;
}

// Public: stays on ISR (cached & revalidated)
const data = await fetch(${API}/posts/${id}, { next: { revalidate: 300 } }).then(r => r.json());
return ;
}
`
Why this works

revalidate makes the route ISR by default.

Calling noStore() (or using fetch(..., { cache: 'no-store' })) opts out per request, turning that render fully dynamic and uncacheable.

generateStaticParams + dynamicParams: true lets you prebuild a subset and serve the rest on demand.

When to use Middleware? Only if you need to rewrite/redirect (e.g., send private IDs to /login) based on the path/headers. It’s not required for the mixed caching strategy above.

Important: ensure private branches always call noStore() (or only cache: 'no-store' fetches) so authenticated content never leaks into the ISR cache.

[icyJoseph]

I think the recommendation is to use connection from next/server - have you tested this setup?