Server Side Rendering at scale
engineeringblog.yelp.com
Server Side Rendering at scale
1–10 of 67 posts
Re: Server Side Rendering at scale
#2I wonder why their old system couldn't scale more horizontally so that there's Although to be fair <50 req/s/instance is pretty bad performance so a rewrite is probably warranted
Re: Server Side Rendering at scale
#3> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded.
The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering.
They then go on to describe a convoluted rendering system with worker processes and IPC... I just don't know what to say. They could have built this in Java, .Net, Go, really any shared memory concurrency runtime and threading, and would not run into any of these issues.
Re: Server Side Rendering at scale
#4> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded. The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering. They the…
I dont want to name names, but do any tech company actually apologise after their high evangelism to the world and industry and walk back 70% of their decision five years later?
And for some strange reason this mostly happens to Web Development in general.
Re: Server Side Rendering at scale
#5> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded. The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering. They the…
I dont want to name names, but do any tech company actually apologise after their high evangelism to the world and industry and walk back 70% of their decision five years later? And for some strange reason this mostly happens to Web Development in general.
Why would they? They weren’t responsible. The people who championed these approaches have left for new jobs.
Re: Server Side Rendering at scale
#6> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded. The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering. They the…
They did acknowledge that, albeit subtly,
> After a string of production incidents in early 2021, we realized our existing SSR system was failing to scale as we migrated more pages from Python-based templates to React.
Apparently their old server-rendered Python app (not called SSR though for obvious reasons) was scaling just fine before the migration.
Re: Server Side Rendering at scale
#7> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded. The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering. They the…
I dont want to name names, but do any tech company actually apologise after their high evangelism to the world and industry and walk back 70% of their decision five years later? And for some strange reason this mostly happens to Web Development in general.
1. Create and evangelize over-engineered solution (React, Kubernetes...)
2. Watch potential competitors chase their tails & burn budgets adopting hot new thing
3. Quietly drop or sideline solution a few years later
Re: Server Side Rendering at scale
#8> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded. The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering. They the…
> They could have built this in Java, .Net, Go, really any shared memory concurrency runtime and threading, and would not run into any of these issues.
It is funny how you can get away with using the wrong tool for the job in Software in a professional environment. Like imagine if you were hired to build a house, and you decided to build the foundation out of modeling clay because that's what you're used to working with. And then you started to come up with novel methods of hardening modeling clay when it proved not to be fit for purpose.
I guess you can get away with it in software because these kinds of decisions normally only manifest as increased server costs, or moments of users' lives lost to performance issues, which are much less evident to the outside observer.
Re: Server Side Rendering at scale
#9> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded. The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering. They the…
Client side rendering is needed for apps that work offline.
SSR improves the user experience for first time use of those apps and enables SEO.
What you say is subjective but I somewhat agree with your opinion, but only for web sites, not web apps.
Overall I agree Yelp should have stuck with the existing system as their product functions as a site.
Re: Server Side Rendering at scale
#10> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded. The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering. They the…
They did acknowledge that, albeit subtly, > After a string of production incidents in early 2021, we realized our existing SSR system was failing to scale as we migrated more pages from Python-based templates to React. Apparently their old server-rendered Python app (not called SSR though for obvious reasons) was scaling just fine before the migration.
Yeah... and then this:
> We evaluated several languages when it came time to implement the SSR Service (SSRS), including Python and Rust. It would have been ideal from an internal ecosystem perspective to use Python, however, we found that the state of V8 bindings for Python were not production ready
Wow, that is some convoluted architecture
It seems like the problem here is React