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

61–67 of 67 posts

Re: Server Side Rendering at scale

#61

Post by manigandham »

LAC-Tech wrote: post #57
manigandham wrote: post #22

Earlier quoted context omitted.

Like what? Server-side frameworks have existed for decades. It's not difficult to run, and modern languages make concurrency very easy. JS doesn't have an advantage here, it's just limited to being single-threaded.

Are you genuinely telling me there are no issues with sharing memory between different threads? Node.js is 13 years old now. I get that a lot of people think it's some new thing that only dumb frontend programmers who only know JS use, back in my day, grumble grumble. But at this point it's established, mature technology, es6 is an expressive language (much, much more so than Go, C# or Java). The multi process concur…

> "Are you genuinely telling me there are no issues with sharing memory between different threads?"

Where did I say that?

I use C#, Go, Java, and lots of JS/Typescript. I like them all. I find C# far more expressive then ES6, but that's just subjective preference. The point is that the vast majority of web frameworks simplify everything to a URL route that runs some backend logic and returns some response (HTML/JSON/etc). Requests are already well isolated and you don't need to worry about threads and memory.

I can't even think of what shared memory issues a typical website like Yelp would have. Can you provide an example?

However if you do need to worry about complex multithreading, memory access and concurrency, then Node is a poor choice. The other language stacks are not only faster but have the proper data structures and ergonomics to handle it while Node/JS is single-threaded, requiring more work and creating more bugs.

Re: Server Side Rendering at scale

#62

Post by rtpg »

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

Earlier quoted context omitted.

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

Collaborative editors are the 1% of sites that are actually applications and need a SPA. But Yelp is nothing like that. What part of the interface is so advanced? It's just a few links and buttons to navigate to pages and submit reviews. A few JS event handlers can handle AJAX/partial updates without an entire React frontend. There's even stuff like https://alpinejs.dev/ and https://htmx.org/ to make this incredibly…

Personally I think htmx is an interesting strategy because it unifies the rendering tech on the server (you still gotta be careful to properly scope your incremental changes).

"Advanced forms" come up all the time, and are usually when you have even a bit of non-trivial business logic. For example "if people pick this set of options, show this other option" (but you want to avoid having a form wizard, cuz then you're having to track state across multiple page loads). There's also stuff like in business applications, previewing calculations and the like.

"A few JS event handlers" can handle a lot of tiny things, but many B2B SaaS have a handful of pages with a loooot of these things, and at the end of the day you could have your hacks, or you could try to be principled about loading it.

Though it's also about just finding the right mix, there are people who can architecture their stuff "correctly", completely SSR + some JS flavoring. But it requires having people who are really good at backend and frontend figuring out the right pieces and putting it together. That diligence is hard!

Re: Server Side Rendering at scale

#63

Post by rtpg »

DerArzt wrote: post #38
mahesh-hegde wrote: post #32

Earlier quoted context omitted.

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…

"Majority of the web" is _not_ news sites and message boards and shopping sites. It's bank websites, ERP software, various CRMs (granted, like news sites...), time tracking, logistics sofware....

And, importantly, a lot of those websites have complex admin-side backends to deal with a lot of things as well! Of course in those cases you might say that the UX requirements are lower (true), but when you are basically serving as a DB frontend, you want to be able to do things quickly, even on a really bad connection.

There's a lot of cool work into partials for SSR, but React and friends are also very nice because you can build out complex UIs that operate through an API, without having to figure out a bunch of workarounds for stateless HTTP/HTML (form wizards anyone?)

Re: Server Side Rendering at scale

#64

Post by norman784 »

manigandham wrote: post #23

This article is just embarrassing. How is a internet tech company so bad at producing basic static webpages? Nothing on the Yelp site needs React or a massive frontend framework. No real-time updates, no complex rendering, no serious in-depth application abilities. The only big JS feature is the maps which can be wired up with relatively little code.

If the case is as you described, then I think they could got away by just implement a few native web components, without the need to migrate to react.

Re: Server Side Rendering at scale

#65

Post by sod »

eyelidlessness wrote: post #55
sod wrote: post #43

I dabbled with worker threads in the past. It feels like you are orchestrating a bunch of node.js instances (workers) with one single threaded entry point, which is now your new bottleneck. It seems way easier and faster to instead start as many node.js instances as you need and distribute the load via nginx reverse proxy. It's unfortunate that ssr for client frameworks has to run in node.js, which is rather slow. Bu…

> I dabbled with worker threads in the past. It feels like you are orchestrating a bunch of node.js instances (workers) with one single threaded entry point, which is now your new bottleneck. Depending on use case/workload, the bottleneck is mostly startup time. Message passing is much faster than most people think, and the main thread ideally is primarily just doing that and getting out of the way. Spinning up new p…

> which would benefit from concurrency, worker threads are often the best solution for Node.

But is it really concurrent though? Each request in the end is still processed by a single node worker which is limited to a single cpu core. Except you manage to distribute parts of the renderer to different workers in parallel. I tried that once as well, render the header, footer and body in 3 different workers. But in the end this consumed 2x as much cpu thus needing 8 workers instead of just plain 4 node servers. And the threads stepped on each other feet due workers being itself single threaded, so the 99%tile got worse/unpredictable.

All of my knowledge is of course biased by using angular, and trying to parallelize angular comes with some overhead due to dependency injection and having to spin up most of the app even though you may only want the header. So I could see how react.js ssr could indeed be split up easier. Didn't had the pleasure to benchmark this yet though.

Re: Server Side Rendering at scale

#66

Post by 64bittechie »

throw_m239339 wrote: post #11

The browser still runs XML with XSLT stylesheets. What if devs would generate XML view models from the server and use XSL AKA functional programming to render HTML? and then just use Javascript to update the XML or XSL stylesheets and let the browser do its magics? Did anybody ever attempted to write SPA like that?

No post body was provided.

Re: Server Side Rendering at scale

#67

Post by eyelidlessness »

sod wrote: post #65
eyelidlessness wrote: post #55

Earlier quoted context omitted.

> I dabbled with worker threads in the past. It feels like you are orchestrating a bunch of node.js instances (workers) with one single threaded entry point, which is now your new bottleneck. Depending on use case/workload, the bottleneck is mostly startup time. Message passing is much faster than most people think, and the main thread ideally is primarily just doing that and getting out of the way. Spinning up new p…

> which would benefit from concurrency, worker threads are often the best solution for Node. But is it really concurrent though? Each request in the end is still processed by a single node worker which is limited to a single cpu core. Except you manage to distribute parts of the renderer to different workers in parallel. I tried that once as well, render the header, footer and body in 3 different workers. But in the…

> But is it really concurrent though?

Yes.

> Each request in the end is still processed by a single node worker which is limited to a single cpu core.

Even without worker threads it’s still concurrent, every async operation suspends and yields to the event loop. The difference is cooperative concurrency (the default Node concurrency model) and whatever concurrency you want with threads.

> Except you manage to distribute parts of the renderer to different workers in parallel. I tried that once as well, render the header, footer and body in 3 different workers. But in the end this consumed 2x as much cpu thus needing 8 workers instead of just plain 4 node servers. And the threads stepped on each other feet due workers being itself single threaded, so the 99%tile got worse/unpredictable.

Your workload very likely wasn’t CPU bound and probably benefited more from the traditional event loop. Most React use cases will be the same.

Post reply on HN