Dedicated cache rules for vercel ISR and netlify Builders

[pi0]

Mapping built-in static and swr cache rules to platform special cache strategies currently introduced lots of confusion for users about how and where caching works with nitro. (should be everywhere, and consistent)

The current mapping strategy is not exactly the same behavior. Netlify swr and static are mapped to builders does not specifies ttl and vercel maps to a strategy that supports expiration but we do not provide stale time which can be different).

Apart from user confusion and not being able to map the strategies precisely, the built-in caching layer can be used universally, also for the vercel and netlify platforms. Allowing to cache in custom storage (could be useful particularly if we want to keep cache across deployments which is not possible currently by map)

I think we need to either introduce platform flags or a new cache flag that can be mapped to ISR/Builder which is not swr/static and next major version of nitro, avoid this mapping.

[pi0]

/cc @danielroe what do you think?

[danielroe]

I think they are more consistent with each other than it currently sounds. Netlify does support numeric ttl which is I think same behaviour as Vercel expiration. The main issue is documentation, I think. We need to clarify that data can be revalidated sooner (as it may refer to within each different location/datacentre, when it comes to Netlify, IIRC).

I would certainly be up for enabling built-in caching layer as well as the platform features.

I lean against adding platform-specific route rules at the nitro level though. It feels like it will bring in fragmentation. What about focusing instead on adding additional generic options or rules that we implement within platforms (for example cacheStorage)?

[pi0]

I agree that a generic option would be much better (if possible). Even when supporting expiration/ttl, neither of ISR/Builders are SWR at least.

My idea about having platform flags, was to make it sound more familiar to end-users coming from Vercel or Netlify. We can ultimately use it as an alias and map those to built-in (maybe static only?) option which maps to platforms with a compatible fallback behavior for non supported.

[danielroe]

Ah, so something like provider 'rule presets' or 'rule packs'? I worry only that it makes Nitro more opinionated and it becomes more difficult to have user provider add-ons, and removes some of the universality of how to implement. Feels like it might be better to document how each rule works with each provider, if different from default value. But may just be my innate conservativism.

It's worth noting that swr is already effectively a bit like this, and (while I think about it) we also need to think about improving DX in these cases, e.g. swr: true enables swr for a route tree, but swr: false, cache: false is needed to disable that for a subtree, which is possibly non-intuitive. Maybe this is an opportunity to pull out (or allow user/module configuration) of rule aliases?

[pi0]

Indeed nitro should be less opinionated and platform-independent. Mapping SWR to a different version for platforms made it confusing.

Do you think we can have a proper caching spec that complies with the exact behavior of both Vercel ISR and Netlify Builders and introduce it as static only? What would be it's characteristics? (TTL, invalidation method, deployment dependence,...)