[⚡ Feature]: Why does Cloudflare Pages still not support OnDemandRevalidate, even after Next.js 13 introduced a new revalidate function that runs on the edge?

[2820402]

Description

Next.js 13 introduced revalidatePath, a feature that will run on the edge and revalidate the page on demand.

import { NextRequest, NextResponse } from 'next/server';
import { revalidatePath } from 'next/cache';

export const runtime = 'edge';

export async function GET(request: NextRequest) {
  const path = request.nextUrl.searchParams.get('path') || '/';
  revalidatePath(path);
  return NextResponse.json({ revalidated: true, now: Date.now() });
}

Please support this feature. It will help Next.js developers use Cloudflare Pages instead of Vercel.

Additional Information

No response

Would you like to help?

• Would you like to help implement this feature?

[bluebeel]

To support revalidatePath , next-on-pages need to support next/cache.
To support next/cache, next-on-pages need to support the patched globalThis.fetch of nextjs.
next-on-pages cannot support it because the fetch is inherited from cloudflare workers platform and I don't think they want to patch the fetch to please nextjs
So to support next/cache, we need to have a custom nextFetch to replicate the internal next/cache and then only you'll have your revalidatePath functionality 😃
Or not because then we need to implement the new internal cache system of nextjs that is really vercel centric if i can say that 🙃

TL;DR: it'll take some times

[james-elicx]

Hey there, I'm afraid that at the moment there are limitations around how revalidation works. I'll try and explain this in a decent amount of detail for you. Apologies in advance for the long text.

In @cloudflare/next-on-pages, we depend on the build output from Vercel and then transform that into a form that can be deployed to Cloudflare. One of the limitations that we are faced with is the inability to deploy Prerender functions. You see, there are two ways that a prerender function can be generated; to be revalidated after x seconds, or not.

When you opt for a route to be revalidated on an interval (export const revalidate = 10;), or a fetch request to revalidate every x seconds (fetch('...', { next: { revalidate: 10 } });), this is known as Incremental Static Revalidation (ISR). These pages will generate a Prerender function with an expiration of the revalidation period, e.g. 10 seconds: "expiration": 10.

When a route does not opt into revalidation and is statically generated, it has no revalidation value, and the Prerender function has no value for its expiration, as it will not expire after x requests: "expiration": false.

Edge runtime routes generate Edge functions instead of Prerender functions.

Now that I've given some background, I'll discuss why this is a problem for us. Cloudflare cannot deploy these Prerender functions. So, instead, we take the fallback static assets for the prerender functions that were generated at build time and use those instead. When you deploy to Vercel, they deploy the Node.js Prerender functions to AWS Lambda.

Calling revalidatePath on Vercel from an edge function actually sends a request to an API endpoint so that Vercel can trigger a revalidation and run the Prerender function again. The result of running the Prerender function again will then be served on your next request and updated in their cache.

So to specifically talk about the main point of this issue, on-demand revalidation of a path is not possible as we are unable to deploy the Prerender functions that path revalidation uses.

revalidateTag, which you didn't mention, is a little different since that uses tags on a patched fetch that interfaces with the incremental cache handler.

The correct way to provide custom behaviour for the incremental cache and revalidateTag/revalidatePath is to use a custom incremental cache handler. However, as Lee from Vercel mentioned in #289 (comment), there is no specification for defining a cache output when using the Vercel build output at the moment, so we are limited again in that case. This means we can't really alter the behaviour of the incremental cache handler yet. There may be some ways for us to introduce cache support for the default fetch incremental cache, but I haven't explored that avenue yet personally.

[cfar0059]

Hi,

Any updates on this?

CF have suggesting alternatives such as:

• Implementing SSR with Cloudflare Pages: https://developers.cloudflare.com/pages/platform/functions/get-started/
• Serving pages from cache with Cloudflare Workers: https://developers.cloudflare.com/workers/runtime-apis/cache/

It's not as straightforward as importing a NextJS project, and we're uncertain if it's worth the hassle to incorporate.

Cloudflare also offers build caching capabilities, detailed here: https://blog.cloudflare.com/race-ahead-with-build-caching/

We're unsure if it would serve the same purposes as ISR.

Does anyone have experience with the above as an alternative solution to ISR?

Thank you !