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

Scaling React Server Side Rendering

arkwright.github.io

Post reply on HN
Print view View original

51–60 of 137 posts

Re: Scaling React Server Side Rendering

#51

Post by dominotw »

wayneftw wrote: post #6

There was no mention of why server-side rendering was needed at all. Based on my companies research Google and Bing do just fine without it. > when the server is under high load, skip the server-side render, and force the browser to perform the initial render. With this type of contingency plan, I don't see any reason to use server-side rendering at all. We build all of our sites and apps with React and don't do it a…

what do you do with the intial "loading" screen? I would prefer if my app didn't need that.

Re: Scaling React Server Side Rendering

#52

Post by forrestthewoods »

arkwright wrote: post #35
yoz wrote: post #4

This is a fantastic article. I was daunted when I saw the length, but everything about it - the prose style, the mixture of drawings, the pace - led me through and out with a whole load of valuable lessons about load balancing, caching, isomorphic rendering and more. Thank you! One question for the author, if they're reading: how did you prep for writing this piece and gather the story details? It's quite a journey,…

Thanks for the kind words! You made my day. I didn't really do any preparation. I had recently been thinking that pretty much every website I had ever built was sadly no longer in existence, and so I wanted to start producing real, "tangible" artifacts from my work; something that might have a shelf life of more than a couple of years. I had those recent SSR adventures in mind, and wanted to write them down before th…

Great post! What tool(s) did you use for the drawings?

Re: Scaling React Server Side Rendering

#53

Post by izacus »

unlinked_dll wrote: post #28
simonw wrote: post #10

Earlier quoted context omitted.

Try using client-side rendered website on a cheap Android phone on a 3G connection sometime - or even a cheap Android phone on LTE. That's how most of the world's population will experience your site. I'm baffled that so many sites have invested in multiple megabytes of JavaScript to render their pages. It's like our entire industry has forgotten how to build sites that can be used by anyone who's not on an LTE iPhon…

>That's how most of the world's population will experience your site. Unless you're FAANG you probably don't care about most of the world's population, but the tiny slice that is most likely to see your site and generate revenue for you. It's not baffling that most developers don't make things for most people. That's just a waste of time and money.

> Unless you're FAANG you probably don't care about most of the world's population, but the tiny slice that is most likely to see your site and generate revenue for you.

That is simply not true for pretty much most companies in existence. Also those users will still be mostly using phones that are significantly slower than iPhone.

> It's not baffling that most developers don't make things for most people. That's just a waste of time and money.

Empirical proof shows that most web developers make things for other web developers (optimizing for 4000$ MacBooks and 1000$ iPhones while forgetting that poor LTE signal areas exist) instead of making it for targeting your actual companies user reach.

(Remember, people who don't return on your slow loading JS bloated web site do not appear on simple dumb Google Analytics.)

Re: Scaling React Server Side Rendering

#54

Post by e12e »

Isn't the first half of this: "use haproxy" (eg: see [1]) (or any other real load balancer)?

I'm not sure if the second half is "... And squid or another caching web proxy" - but I'm open to the ssr pipeline being far enough from REST (the architectural pattern) that caching is broken, and something more application level, like redis/memcache or a custom cache is needed.

[1] https://www.haproxy.com/blog/four-examples-of-haproxy-rate-l...

Re: Scaling React Server Side Rendering

#55

Post by frandroid »

An amusing tidbit about optimization, toward the end:

> Because we were seeking to improve performance, we became interested in benchmarking upgrades to major dependencies. While your mileage may vary, upgrading from Node 4 to Node 6 decreased our response times by about 20%. Upgrading from Node 6 to Node 8 brought a 30% improvement. Finally, upgrading from React 15 to 16 yielded a 25% improvement. The cumulative effect of these upgrades is to more than double our performance, and therefore our service capacity.

Free optimization, ripe for the taking!

Re: Scaling React Server Side Rendering

#56

Post by jborichevskiy »

forrestthewoods wrote: post #52
arkwright wrote: post #35

Earlier quoted context omitted.

Thanks for the kind words! You made my day. I didn't really do any preparation. I had recently been thinking that pretty much every website I had ever built was sadly no longer in existence, and so I wanted to start producing real, "tangible" artifacts from my work; something that might have a shelf life of more than a couple of years. I had those recent SSR adventures in mind, and wanted to write them down before th…

Great post! What tool(s) did you use for the drawings?

Curious to know this as well. The drawings, diagrams, and flow charts are an absolute delight!

Re: Scaling React Server Side Rendering

#57

Post by nothrabannosir »

mychael wrote: post #50

The Table of Contents should be first, then the content. I clicked Introduction expecting to link to something new, but it took me backwards.

Isn’t that a matter of style? It’s not uncommon for books to have the introduction preceding the table of contents. I’m literally looking at one right now that does this (publisher Wordsworth Classics).

Re: Scaling React Server Side Rendering

#58

Post by a13n »

tannhaeuser wrote: post #44
a13n wrote: post #30

Earlier quoted context omitted.

The reason React was made is because it's an easier way to reason about apps at scale, with many components and people working on them. As a result, there will be less errors and your team can move faster. It has nothing to do with offloading rendering to the client.

How is "reasoning" about apps at scale easier with React vs static or classic server-side HTML rendering where everything is addressed by a URL?

It isn't, but requirements rarely allow for static websites.

Re: Scaling React Server Side Rendering

#59

Post by a13n »

dvt wrote: post #39
a13n wrote: post #27

Earlier quoted context omitted.

This is probably the worst possible takeaway from this article. > not use javascript for everything Using JS for frontend + backend has significant advantages. Your developers only need to know one language/codebase. You don't need to hire/maintain separate frontend/backend teams who need to figure out how to coordinate with each other. > actually generate html That's what server-side rendering does. > expecting peop…

> Running your frontend code on the backend to generate HTML is an elegant solution and extremely easy to implement. These days it works out of the box. Not sure where you got the idea it was a "convoluted workaround". Oh boy, this must be the overstatement of the decade. I've done SSR with a few frameworks now, including Meteor, Nest, and Next. Saying that "it works out of the box" is so disingenuous, it borders on…

This hasn't been my experience. How does SSR not work out of the box with NextJS?

Re: Scaling React Server Side Rendering

#60

Post by pmontra »

wayneftw wrote: post #6

There was no mention of why server-side rendering was needed at all. Based on my companies research Google and Bing do just fine without it. > when the server is under high load, skip the server-side render, and force the browser to perform the initial render. With this type of contingency plan, I don't see any reason to use server-side rendering at all. We build all of our sites and apps with React and don't do it a…

SSR was eating up the RAM of our production server like 7.5 GB for Node and 0.5 for our Elixir backend. That was insane. We decided to shutdown SSR and check if anybody would notice. Apparently they didn't. However that webapp is a service that customers use from their computers in their office, not something mobile. We expect fast connections.
Post reply on HN