Doesn't the browser respect Cache-Control headers by default?

[sdandois]

I thought that the browser respected Cache-Control headers by default. If that is the case, ¿why do we need this library?

I would appreciate if you could clarify my question.

[arthurfiorette]

Hey @sdandois.

For non browser environments, cache is not done by default. So using a library is the only solution.

The problem with browser default cache-control implementation is that it behaves differently for each browser: Chromium/safari/etc. Also it just respects basic cache, which is what cache-control/etag/etc helps you with. If you backend does not returns these headers, if you need to cache in a different behavior than what the server says, or any possibility that is not what the server told you explicitly (most of the time it doesn't even send them) to do, a library is necessary. Using the same cache library everywhere, working for everyone seems a better alternative. However, if you are ONLY consuming resources that strictly respects Cache-Control/Etag and you do not need caching, just using the default's browser behavior is be a better solution.

Remember: The server may sent cache headers to you to help him reduce server load and network bandwidth. The client uses cache to improve page (as this case is a frontend) speed and responsivity. I'd recommend you to add a capable cache system on your clients every time cache is not needed and is only being done to reduce server load and network bandwidth.

[sdandois]

Thanks for the detailed answer! I've been looking at some configuration options and it looks more powerful than the standard http cache mechanism.

In my use case is only browser and self-managed http api backend.

[arthurfiorette]

No problem. Happy to help! Your use case seems perfect for axios-cache-interceptor. Would you mind on marking my answer as the accepted one? Thanks!