Scaling React Server Side Rendering
arkwright.github.io
Scaling React Server Side Rendering
1–10 of 137 posts
Re: Scaling React Server Side Rendering
#2Incedibly nice writeup! I really like how the drawings help to better understand the concepts. A lot of time must have gone into crafting this article.
Re: Scaling React Server Side Rendering
#3This is from October 2017. It remains a fantastic explanation of load balancing and server-side React rendering performance techniques.
Re: Scaling React Server Side Rendering
#4This 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, and - if I was writing something like this - I would have a hard time keeping track of all the different twists, stats and lessons as they happen so they can be written up later. Do you keep a notebook, or did you rebuild the story from artifacts?
Re: Scaling React Server Side Rendering
#5The easiest way to do this is to not use javascript for everything in the first place and to actually generate html instead of expecting people to run your code, then having to do it yourself in a convoluted workaround when they won't or can't.
Re: Scaling React Server Side Rendering
#6There 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 at all, for any reason at this time.
Is there something we're missing?
Re: Scaling React Server Side Rendering
#7Great article, interesting read indeed.
> The cumulative effect of these upgrades is to more than double our performance, and therefore our service capacity.
That's a risky conclusion, in that it's likely over-generalised.
The upgrades may have improved the average performance, but they might introduce some performance impact on less well trodden paths, things that may strike at the least convenient time. There are performance gotchas that show their faces when load increases (system cache inefficiencies, etc. etc.) Some of the times I've been most hurt, operationally, have come when what looks great in generalised circumstances turns out to have a nastier under-load behaviour.
That said, always watch out for upgrades and make patching/upgrading a priority task. If there is a CVE attached to an upgrade, you want to be deploying that as fast as humanly possible. That means making sure there are as few human-involved steps as possible in your build/test/deployment chain.
Re: Scaling React Server Side Rendering
#8There 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…
In a previous job where we worked with extremely low margins and very un-invested users who would bounce if the load time was too low, we used react's server-side rendering without using any react in our pages just to get a faster page load.
Re: Scaling React Server Side Rendering
#9There 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…
You are not missing anything. This is a reheated anti-pattern that was (poorly) conceived in the 90's, and managed to crawl back. Was a great way to break a monolithic app back then, and it's still a great way to break a modular, scalable, cloud based web app now.
Re: Scaling React Server Side Rendering
#10There 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…
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 iPhone.