Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Holy shit the amount of overcomplications to serve simple HTML and CSS.

If you read the overview, Tudum has to support content update events that target individual users and need to be templated.

How do you plan on generating said HTML and CSS?

If you answer something involving a background job, congratulations you're designing Tudum all over again. Now wait for opinionated drive-by critics to criticize your work as overcomplicated and resume-driven development.



Don’t forget the part where people not even a little exposed to the massive tech infrastructure at hand and local skill pool make WAGs about what us and isn’t cheap.

Kafka might seem like extra work compared with not Kafka, but if it’s already setup and running and the entire team is using it elsewhere suddenly it’s free.


>How do you plan on...

This isn't an engineering problem. It's a PM+Eng Lead failing to talk to each other problem.

If you need 20 engineers and exotic text for what should be a simple static site or Wordpress site, you're doing it wrong.


I hear "content update events that target individual users and need to be templated" and immediately rule out any approach involving a background job.

- Reddit doesn't use background jobs to render a new home page for every user after every update.

- Facebook doesn't use background jobs to render a new feed for every user after every update.

- Hacker News doesn't use background jobs to render a new feed for every user after every update.

Why? Because we have no guarantee a user will access the site on a particular day, or after a particular content update, so rendering every content update for every user is immediately the wrong approach. It guarantees a lot of work will be thrown away. The sensible way to do this is to render the page on demand, when (and IF) a user requests it.

Doing N*M work where N=<# of users> and M=<# of page updates> sure seems like the wrong approach when just doing N work where N=<# of times a user requests a page> is an option.

There's lots of less exotic approaches that work great for this basic problem:

- Traditional Server-Side Rendering. This approach is so common that basically every language has a framework for this.

- Single-Page Applications. If you have a lot of content that only needs updated sometimes, why not do the templating in the users browser?

- Maybe just use wordpress? It already supports user accounts and customization.


I read the overview, and it is blindly obvious that the issue is cache invalidation and someone overengineered it.

This is not a spectacular problem. This is a "building a web service 101 problem", which was solved about the time CGI scripts came out.

Also why would anyone involve background jobs? You can do high-performance templating real-time, especially on 2025 hardware.


> How do you plan on generating said HTML and CSS?

Is this not what SSR html - via any backend language/framework - has been doing since forever?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: