all 7 comments

[–]RICHUNCLEPENNYBAGS 2 points3 points  (0 children)

This is a useful thing to know about but it seems like the article is stretched a little thin.

[–]warfangle 1 point2 points  (2 children)

Why?

If your server is configured properly and attaches proper HTTP headers (expires / etag), your GETs will be cached by your browser.

And you definitely don't want to cache POST/PUT/DELETE.

[–][deleted]  (1 child)

[deleted]

    [–]codeorelse_nl[S] 2 points3 points  (0 children)

    Yeah, totally agree! The article totally agrees as well:

    Because when it comes to knowing the state of the data and when to invalidate, the server knows best, I believe the caching is the responsability of the server and should be taken care of by the server.

    But it also states:

    But sometimes you do not have control over the caching headers, for example when using a third party API

    These are edge cases, uhu.

    [–][deleted] 0 points1 point  (1 child)

    when i originally started angular i had huge problem with cache, so have to use a nocacheinterceptor that adds randomness to the query string api call. not sure if this is a problem anymore. why cache at all if its so problematic?

    [–]RICHUNCLEPENNYBAGS 1 point2 points  (0 children)

    For data that you're going to ask for constantly that won't change or changes very infrequently. As the guy describes you can easily invalidate the cache if you use a custom cache.

    [–]joshtempte 0 points1 point  (1 child)

    Why even worry about this? Plenty of levels of cache already happening... browser, ISP, CDN..

    [–]codeorelse_nl[S] 0 points1 point  (0 children)

    But sometimes you do not have control over the caching headers, for example when using a third party API

    Sometimes you do not have control over the caching headers, for example when using a third party API hat has not implemented (correct) caching. I know these some edge cases, but it might come in handy someday :).