Making AWS News stupid fast with smart caching | Hacker News Reader

Making AWS News stupid fast with smart caching

lucvandonkersgoed.com

50 pointstatersolid17 comments

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.

Sad, would have loved a realtime news feed API distributed by AWS.

Isn’t this what Reuters and Associates Press offer?

Why would it need to be distributed by AWS?

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.

Don't know about Amazon lawyers per se, but my understanding is that this is what almost always happens when some complementary third-party software uses in its name the name of the software it complements, in particular when it makes the third-party product seem to be developed or endorsed by the owners of the complemented product. May or may not be trademark related.

> 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.

To see that you have to actually visit and pay attention. By name only, "AWS News" looks like an official Amazon/AWF too. The potential for confusion is real (any actual impact on the company, less so.)

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.

To me reading this, I wonder if you also tell programmers they must avoid cache hits in L1/L2 because they simply dont need the performance, and because they don't need it they aren't allowed to use it.

My comment was specifically about this news site. What you brought up is completely different use case. I never said use my comment and apply everywhere caching can help.

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.

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.

Very easy to read props to the author

I now wonder how the author didn't get a C&D and/or a UDPR take down because of the domain name.

Reply on news.ycombinator.com