Why is enableCacheInterception dangerous?

[vicb]

ref:

// open-next.config.ts

const config = {
  // ...
  dangerous: {
    enableCacheInterception: true,
  },
};

I was wondering why enableCacheInterception is on dangerous and why it is disabled by default?

Would it make sense to change that?

/cc @conico974

[conico974]

Well the main reason is that it is not as well tested and that it bypass NextServer totally in some cases. It could behave differently than next start. For example at the moment a route revalidated with revalidateTag would require 2 Incremental Cache get as well as checking the cache tags twice (because it fallback to normal NextServer if not found ) It has 3 main benefits :

• It's usually a lot faster (No need to load the js for an SSG route)
• It allows ISR/SSG route to be served directly from the routing layer (especially interesting with an external middleware)
• That's what's necessary to make PPR work in the same way as in vercel

I don't think that it is something that we want to enable by default, but with more thorough testing we could move it outside of dangerous

[vicb]

Thanks for the clarification @conico974

Would it make sense to add the details to https://opennext.js.org/aws/inner_workings/cache_interception ?

(and for the context I was looking at what we should recommend to our users)

[conico974]

Yeah we can add some more info in the docs.

As for if it should be recommended on cloudflare, this is probably the place where it is the least interesting. The only benefits as of now in cloudflare would be that it may be a bit faster in some cases (but that's mostly true for cold start)

[vicb]

The only benefits as of now in cloudflare would be that it may be a bit faster in some cases

I think it could really help when the external middleware is actually external (i.e. in a separate worker)