[eddythompson80]

> Essentially, the whole point of the article is that despite being "open source" you cannot run next.js at scale yourself without a massive investment of your own.

I don't know about that. Asking a service provider to provide an implementation for a cache interface isn't a "massive investment". It's an investment sure, but it's the type of investment that seems should be customizable per provider depending on their needs, technologies they want to bet on, etc. It seems to me the problem with Netlify isn't comfortable putting in the investment to have a NextJS specific cache service. It's understandable considering they don't control the framework and to them it's just another option, so they don't want to invest in it too much.

[erozzy]

(disclaimer: Netlify employee) The big challenge with the cache interface atm is not using Redis (personally, I love Redis). It's that this interface is far from being a straightforward GET/SET/DELETE. Rather, you need to learn the default implementation and all its nuances (for different payload types), and duplicate/transform all the logic.

The division of labor between what the framework does and what the platform developers (or any other developer working on a high-scale/high-availability deployment) need to do, has to be fixed. If this happens - plus better docs - you should be able to "just use" Redis.