Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Server Side Rendering at scale

engineeringblog.yelp.com

Post reply on HN
Print view View original

31–40 of 67 posts

Re: Server Side Rendering at scale

#31

Post by dewey »

Cthulhu_ wrote: post #29
dewey wrote: post #24

Earlier quoted context omitted.

Do you think you have full insights into what's going on there from the outside? This sounds like a "can't they just use a static site generator" kinda-comments without knowing about the whole scope of the company.

Do you? You sound like you're making apologies without bringing compelling arguments to the contrary of the person you're replying to.

I do not, but from working in companies I know that a lot of things are not as simple as they look from the outside. Most times decisions are taken with a bunch of constraints factored in (can we attract talent to work on that stack?) that aren't necessarily just about "how can we build this in the simplest way possible".

Thinking that they haven't thought about this one simple way of doing it is a bit naive.

Re: Server Side Rendering at scale

#32

Post by mahesh-hegde »

manigandham wrote: post #21
rtpg wrote: post #18

Earlier quoted context omitted.

It's actually not how things worked just a few years ago. How things worked a few years ago: you wrote SSR pages with one set of tools (like Django Template Language), then hooked into it with another set of tools. If your pages are complex enough, you end up with weird brittleness because the "initial page load" is not handled the same way as modifications of that page. Now it's much closer to using the same set for…

Why do you need all that client-side interactivity in the first place? Most interactions can easily be handled with a full refresh, as proven by the very site you're reading this on (hackernews). Server-side web frameworks even have modern component-based UI templating now, and features like maps can be layered on top as progressive enhancement without this bloated frontend mess.

Something like a collaborative document editor or forms with non-trivial logic.

Also, the interface of HN works because of its demographic.

Re: Server Side Rendering at scale

#33

Post by whazor »

anentropic wrote: post #10
oefrha wrote: post #6

Earlier quoted context omitted.

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

I see a lot of React hate which I can understand, but don't forget that React allows you to release faster as a big company.

React is a defacto standard that product people know and understand. They can ship complicated features faster across platforms (for example React Native), while the more technical engineers get to solve these more generic problems (dependency hells, integrations, CI/CD, performance).

Alternative solutions would potentially require more technical engineers to build features and thus slow down product development for a big company.

Re: Server Side Rendering at scale

#34

Post by jaywalk »

rtpg wrote: post #18
diek wrote: post #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 the…

It's actually not how things worked just a few years ago. How things worked a few years ago: you wrote SSR pages with one set of tools (like Django Template Language), then hooked into it with another set of tools. If your pages are complex enough, you end up with weird brittleness because the "initial page load" is not handled the same way as modifications of that page. Now it's much closer to using the same set for…

More than a few years ago, but ASP.NET WebForms with the AJAX Control Toolkit did this. It was terrible for many reasons, but it did allow you to use one set of tools for everything.

Re: Server Side Rendering at scale

#35

Post by a_c »

diek wrote: post #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 the…

Dev nowadays talk about SSR like a new found panacea. Yea if we look close enough it is different from a Java spring or python Django apps, but only by a slight amount imo.

I think it is because a lot of tutorials nowadays talk about how to do X with tool Y, without telling the historical context as to why Y is in use in the first place. Usually the tool is to solve a specific problem in mind. When people discover that the tool doesn't solve their very own problem, workarounds based on the very same tool is devised.

Other common examples are kubernetes and microservices. I have seen startup jumped onto the bandwagon before having real customers where the tool in question is meant for scalability purpose

Re: Server Side Rendering at scale

#36

Post by [deleted] »

a_c wrote: post #35
diek wrote: post #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 the…

Dev nowadays talk about SSR like a new found panacea. Yea if we look close enough it is different from a Java spring or python Django apps, but only by a slight amount imo. I think it is because a lot of tutorials nowadays talk about how to do X with tool Y, without telling the historical context as to why Y is in use in the first place. Usually the tool is to solve a specific problem in mind. When people discover th…

[deleted]

Re: Server Side Rendering at scale

#37

Post by the_gastropod »

mahesh-hegde wrote: post #32
manigandham wrote: post #21

Earlier quoted context omitted.

Why do you need all that client-side interactivity in the first place? Most interactions can easily be handled with a full refresh, as proven by the very site you're reading this on (hackernews). Server-side web frameworks even have modern component-based UI templating now, and features like maps can be layered on top as progressive enhancement without this bloated frontend mess.

Something like a collaborative document editor or forms with non-trivial logic. Also, the interface of HN works because of its demographic.

Yep. I think these examples are probably fine for the SPA style approach. What gets me is the other 98% of web apps out there, that are not collaborative document editors, calendars, or the handful of other use-cases where this approach can make some sense. It feels like a lot of complexity that has been cargo-culted into the mainstream.

Much of the "progress" in web development in the past decade feels like it's just fixing problems that only exist because we're building web applications this way. React, Redux, Typescript, Server Side Rendering.. these are solutions to problems we created for ourselves by using an architecture with a dubious value proposition in most of our use-cases.

Re: Server Side Rendering at scale

#38

Post by DerArzt »

mahesh-hegde wrote: post #32
manigandham wrote: post #21

Earlier quoted context omitted.

Why do you need all that client-side interactivity in the first place? Most interactions can easily be handled with a full refresh, as proven by the very site you're reading this on (hackernews). Server-side web frameworks even have modern component-based UI templating now, and features like maps can be layered on top as progressive enhancement without this bloated frontend mess.

Something like a collaborative document editor or forms with non-trivial logic. Also, the interface of HN works because of its demographic.

Yeah, anything like what you described are going to be web apps and need all that logic. That being said for the majority of the web (news sites, simple message boards, shopping sites, etc) couldn't they all be rendered on the server?

I have to wonder how much of the client-side rendering framework use is mainly from people forming a cargo-cult around "it's what Facebook does" when at the end of the day what Facebook does is way different from your use case.

By strictly numbers, most engineers don't work at one of those tech giants, but at small firms making CRUD apps that don't really need all that responsiveness.

Re: Server Side Rendering at scale

#39

Post by 0des »

a_c wrote: post #35
diek wrote: post #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 the…

Dev nowadays talk about SSR like a new found panacea. Yea if we look close enough it is different from a Java spring or python Django apps, but only by a slight amount imo. I think it is because a lot of tutorials nowadays talk about how to do X with tool Y, without telling the historical context as to why Y is in use in the first place. Usually the tool is to solve a specific problem in mind. When people discover th…

Soon they will be where we are, shaking their canes as the youngsters of tomorrow discover cgi-bin. Live and let live, appreciate them for their journey, the lessons learned and skills gained.

Re: Server Side Rendering at scale

#40

Post by ec109685 »

trinovantes wrote: post #2

I 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

You can get unlucky and have multiple slow page requests land on the same NodeJS worker and interfere with each other, so as a result have to massively over scale to reduce chances.

With their new model, they distribute requests explicitly to workers so they can’t interfere with each other and drop server side rendering if they don’t have capacity.

Post reply on HN