What’s the optimal caching strategy for data that uses params without generateStaticParams?

[dninomiya]

I have a question about the sample code in the documentation.

import { Suspense } from 'react'
import { connection } from 'next/server'
import { cookies } from 'next/headers'
import { cacheLife, cacheTag } from 'next/cache'
 
// Static product data - prerendered at build time
async function getProduct(id: string) {
  'use cache'
  cacheTag(`product-${id}`)
 
  // This is cached at build time and shared across all users
  return db.products.find({ where: { id } })
}
 
// Shared pricing data - cached at runtime in remote handler
async function getProductPrice(id: string) {
  'use cache: remote'
  cacheTag(`product-price-${id}`)
  cacheLife({ expire: 300 }) // 5 minutes
 
  // This is cached at runtime and shared across all users
  return db.products.getPrice({ where: { id } })
}
 
// User-specific recommendations - private cache per user
async function getRecommendations(productId: string) {
  'use cache: private'
  cacheLife({ expire: 60 }) // 1 minute
 
  const sessionId = (await cookies()).get('session-id')?.value
 
  // This is cached per-user and never shared
  return db.recommendations.findMany({
    where: { productId, sessionId },
  })
}
 
export default async function ProductPage({ params }) {
  const { id } = await params
 
  // Static product data
  const product = await getProduct(id)
 
  return (
    <div>
      <ProductDetails product={product} />
 
      {/* Dynamic shared price */}
      <Suspense fallback={<PriceSkeleton />}>
        <ProductPriceComponent productId={id} />
      </Suspense>
 
      {/* Dynamic personalized recommendations */}
      <Suspense fallback={<RecommendationsSkeleton />}>
        <ProductRecommendations productId={id} />
      </Suspense>
    </div>
  )
}
 
function ProductDetails({ product }) {
  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
    </div>
  )
}
 
async function ProductPriceComponent({ productId }) {
  // Make this component dynamic
  await connection()
 
  const price = await getProductPrice(productId)
  return <div>Price: ${price}</div>
}
 
async function ProductRecommendations({ productId }) {
  const recommendations = await getRecommendations(productId)
  return <RecommendationsList items={recommendations} />
}
 
function PriceSkeleton() {
  return <div>Loading price...</div>
}
 
function RecommendationsSkeleton() {
  return <div>Loading recommendations...</div>
}
 
function RecommendationsList({ items }) {
  return (
    <ul>
      {items.map((item) => (
        <li key={item.id}>{item.name}</li>
      ))}
    </ul>
  )
}

In the sample, generateStaticParams isn’t used. Therefore, my understanding is that getProduct cannot be evaluated at build time, making the route dynamic — which means "use cache" wouldn’t take effect. Is that correct?

When I tested this locally, caching seemed to work, but after deploying to Vercel, the cache was not applied.

Additionally, since the sample code doesn’t use generateStaticParams, params behaves as runtime data. Because of this, I don’t see why a connection would be required — yet it’s explicitly specified in the example. Could you explain the reasoning behind that choice?

To summarize my understanding:

1. When params are used without being pre-resolved by generateStaticParams, they behave as runtime data, making static caching impossible.
2. If you want to cache the result of a function that uses such params, you should use "use cache: remote".
3. In case (1), since the route is already runtime-generated, there’s no need to mark it with connection.

Demo

• use cache: remote: https://next-16-guide.vercel.app/dynamic-params
  • cached ✅.
• use cahce: https://next-16-guide.vercel.app/dynamic-params-not-remote-cache
  • loading per accesss. 🤔

Reference:
https://nextjs.org/docs/app/api-reference/directives/use-cache-remote#mixed-caching-strategies

Thank you for your suppoort!

[icyJoseph]

I think the problem here is that a serverless deploy doesn't typically have an in-memory API across instances, so use cache by itself won't persist, you might just hit a different instance. (I am adding this to the docs, waiting for reviews right now)

[dninomiya]

@icyJoseph

Thanks again for the clarification about caching on serverless environments — that was very helpful!

I still have one question regarding the connection() call in the official sample code.

Since the example doesn’t use generateStaticParams, the route is already treated as dynamic because params is resolved at runtime.
In that case, I don’t quite see why explicitly calling await connection() is necessary to mark it as dynamic.

Is it included just as a demonstration of a dynamic data source, or is there a functional reason it must be called even though the route is already dynamic?

I’d appreciate a bit more clarification on the intention behind using connection() in that example. Thanks again! 🙏

[magictalent]

If you need persistent or shared caching across deployments, you can consider one of these approaches:
Use an external cache layer (e.g., Redis, Upstash, or Cloudflare KV) to store computed results or fetched data.
Leverage Next.js fetch caching with revalidate or revalidateTag — this persists across deployments when using platforms like Vercel that support the data cache.
For per-request caching, you can wrap logic with an LRU cache if you only need short-lived, instance-local optimization.