Are Amazon lawyers known to be litigious on things like that? The logo has a clear "unofficial" tag and the information is a stream of press releases. I don't see why anyone would care about it.
Very interesting. First thought is do you even need caching? How many users do you have? Why do you think aws rinvent will cause people to start using this site? First time hearing about aws-news.com.
I read this more as a "toy problem" - a demo on how to do caching well, than as "this data needs caching, today". i.e. a tutorial, because sooner or later you will benefit from caching.
As such I think it's a well written clear example. But you always need to bear in mind that a toy problem simple enough to demo a technique clearly, is seldom complex enough to need the technique.
The UX mitigations section is interesting. The shifting of the layout after the first render is mitigated by CSS animations. That works when you have a "sparse" design like what they currently have. For sites with high density such as Hacker News, too many CSS animations happening after the first render could be a bad user experience.
I'm also wondering how to deal with scenario where we introduce sorting by popularity. With the current design, User might see articles swap places after the first render.
> Separating them into different calls will introduce some additional complexity, but in the long run it will make your applications much more scalable and maintainable.
I agree with the scalability benefits, but not sure about maintainability. In fact introducing additional complexity usually leads to higher maintenance costs.
> Classifying data by cacheability ... Notice how we’re combining the three types of data in the first iteration?
This is the key insight. But I would phrase it more as "segregate data by mutability" as it's about more than caching. More than once I've seen pain caused by a design that failed to do this.
In case anyone is wondering, AWS News is not an AWS service but a third party news website about AWS (https://aws-news.com) run by the author.
These days you never know, just plop down any word after AWS and you’re likely to win AWS bingo.
Interesting that this remains. I'd expect Amazon lawyers to beat them over the head with C&Ds until they change the name.
Are Amazon lawyers known to be litigious on things like that? The logo has a clear "unofficial" tag and the information is a stream of press releases. I don't see why anyone would care about it.
Sad, would have loved a realtime news feed API distributed by AWS.
Isn’t this what Reuters and Associates Press offer?
Very interesting. First thought is do you even need caching? How many users do you have? Why do you think aws rinvent will cause people to start using this site? First time hearing about aws-news.com.
I read this more as a "toy problem" - a demo on how to do caching well, than as "this data needs caching, today". i.e. a tutorial, because sooner or later you will benefit from caching.
As such I think it's a well written clear example. But you always need to bear in mind that a toy problem simple enough to demo a technique clearly, is seldom complex enough to need the technique.
The UX mitigations section is interesting. The shifting of the layout after the first render is mitigated by CSS animations. That works when you have a "sparse" design like what they currently have. For sites with high density such as Hacker News, too many CSS animations happening after the first render could be a bad user experience.
I'm also wondering how to deal with scenario where we introduce sorting by popularity. With the current design, User might see articles swap places after the first render.
> Separating them into different calls will introduce some additional complexity, but in the long run it will make your applications much more scalable and maintainable.
I agree with the scalability benefits, but not sure about maintainability. In fact introducing additional complexity usually leads to higher maintenance costs.
See also: the `stale-while-revalidate` and `immutable` HTTP Cache-Control directives.
Stale-while-revalidate: see https://web.dev/articles/stale-while-revalidate & https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca...
Immutable: https://datatracker.ietf.org/doc/html/rfc8246 & https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca...
And if, like in the article, you’re using a CDN, `s-maxage` (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca...) is quite useful. Set it to a long time, and purge the CDN cache on deploy.
Very easy to read props to the author
> Classifying data by cacheability ... Notice how we’re combining the three types of data in the first iteration?
This is the key insight. But I would phrase it more as "segregate data by mutability" as it's about more than caching. More than once I've seen pain caused by a design that failed to do this.
I now wonder how the author didn't get a C&D and/or a UDPR take down because of the domain name.