Next.js 15 migration write-up flags async request APIs and flipped fetch caching defaults

A developer write-up on dev.to chronicling a monorepo move to Next.js 15 reports substantial iteration-speed gains alongside two migration hazards the author considers easy to underestimate: request-scoped APIs that now return Promises, and fetch caching defaults that have been inverted.

The upgrade pays off day to day

According to the dev.to post, enabling Turbopack in development made cold starts and incremental edits feel nearly instant. In the author's own runs, builds came in four to seven times faster and hot-module replacement latency fell below 100 milliseconds on large folders — figures the author says line up with public reports of roughly 70–76 percent faster starts on real projects. Next.js 15 also brings React 19 support and Partial Prerendering, which the team leaned on as part of a broader push into Server Components.

Request APIs are asynchronous now

The first breaking change covers APIs that read request-specific data: cookies(), headers(), draftMode, and the params and searchParams props. In Next.js 15 these return Promises, so older synchronous call sites can still compile and deploy, then fail at runtime with subtle errors. The failure mode the author singles out is middleware or auth logic that reads a session cookie synchronously and later throws because the returned Promise was never awaited.

The remedy is mechanical: make the calling function async and await the helper — awaiting cookies() yields the cookie store, and awaiting params yields the route parameters. In dynamic routes, server component signatures now type params as a Promise. The Next.js team ships a codemod (run via npx @next/codemod@canary next-async-request-api) that handles much of the conversion, but the author stresses that complex patterns still need manual inspection.

Fetch and GET handlers default to uncached

The second change inverts caching: fetch calls and GET route handlers now behave like no-store unless caching is opted into explicitly. Applications that leaned on the old implicit caching can see two unwelcome outcomes after upgrading — stale data where caching is misapplied, or sudden spikes in backend and API traffic as requests that used to be served from cache start hitting origin.

Opting back in is per call or per route. For individual fetches, the write-up points to cache: 'force-cache' for static or rarely changing data and next: { revalidate: seconds } for interval-based revalidation. Route handlers can export dynamic = 'force-static' or a revalidate value. The author's rule of thumb: keep truly user-specific data uncached and cache shared resources deliberately.

Secondary gains and a working checklist

The migration also served as an occasion to move more UI into Server Components and adopt Partial Prerendering, which serves a static shell immediately and streams dynamic pieces in; the author reports smaller client bundles and improved p99 LCP where it was applied.

The write-up's checklist: upgrade to next@15 with react@19 and react-dom@19; run the codemod; audit every request-scoped call, including generateMetadata; decide caching explicitly for every fetch and GET route; enable Turbopack in development; smoke-test auth, personalization and edge-runtime flows; and watch production backend traffic after release. In the author's own audit, a middleware file had compiled and shipped without complaint but produced rare runtime errors from un-awaited cookies() calls; after the fix, plus explicit cache flags on a few hotspot fetches, LCP improved and bundle budgets shrank.

Why it matters

The changed defaults read as deliberate design rather than accidents: they make caching an explicit decision and expose exactly where request data is read. That is healthier in the long run, but it turns an upgrade into a genuine audit. Teams on Next.js 14 should budget time for the codemod plus a pass over every cookies(), headers(), params and searchParams call site, and every fetch that previously relied on implicit caching — otherwise the costs surface as auth bugs at runtime and unexplained load on upstream services.