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

121–130 of 137 posts

Re: Scaling React Server Side Rendering

#121

Post by ehnto »

lewisjoe wrote: post #94

This looks like a great piece of article. Kudos to the people who wrote it because the most sure-shot problem in SSR is running to scaling issues and this is a much needed one. But here's an unpopular opinion: Server side rendering shouldn't even be a thing. Running a language as dynamic as Javascript on servers, is at best - a problem that can be dealt with, but not necessarily the solution. I'm saying this as a ful…

I thought the selling point of React SSR was caching and pre-rendering into static HTML? How is it being used that causes it to become a performance bottleneck?

Re: Scaling React Server Side Rendering

#122

Post by beaker52 »

rimliu wrote: post #111
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…

> Your developers only need to know one language/codebase As one wise man said: make it easier for the users, harder for a database. The same applies to developers. We tend to forget who we make products for.

This holds true until about a year into the project and everything is complicated beyond the desire of your developers and productivity has tanked.

Re: Scaling React Server Side Rendering

#124

Post by rmetzler »

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…

I also want to compliment the mobile view. These days I almost always use the mobile safari reader view which unifies the design on websites and increased readability. This doesn’t work on your site, but it doesn’t have to, because the design is actually pretty similar and easily readable.

So thanks for this great article.

Re: Scaling React Server Side Rendering

#125

Post by hnbreak »

mhd wrote: post #118
hnbreak wrote: post #110

People debate SPA vs SSR without any context. Both have their use case: Everything before a login => SSR, everything after => SPA. Why? SSR is proven to be much better at SEO. But SPAs offer best UIs. Nobody wants to click through stuttery SSR dashboards in 2019, wait for page loads, submits, etc. People prefer slick UIs, that was one of the reasons DigitalOcean got big (because of their then stunning dashboard or af…

> But SPAs offer best UIs I don't consider this a settled conclusion. Mostly because it's a false dichotomy. There are alternatives to both SSR of component sites and SPAs, and every solution has its inherent advantages and disadvantages. UI isn't even the primary feature of an SPA, that would be offline usage. Having more interactive elements without page loads is a feature of "DHTML", and that can be had from anyth…

Good point and I agree that the borders between SPA and SSR are blurry. However, I just wanted to stress that a debate without having requirements is useless, it's like saying a racing car is better than a truck. But for what? Building websites is not like building websites 20 years ago. There are many uses cases and saying one is better than the other rather shows that you never experienced the other side. I mean, there are still people out who never touched react, how should they fully grok what mighty system and ecosystem react has created and choosing another stack comes with much smaller or dying ecosystems.

To your points, I still think a proper SPA without any quirks such as DHTML, React Suspense, etc. gives the best UI for dashboard and logged-in kind of uses cases. However, having mixed environments is from a production and dev perspective subpar and hence you end up with setups like Next (SSR) with some Next pages having a stronger SPA notion (SPA within SSR).

Re: Scaling React Server Side Rendering

#126

Post by pferde »

chii wrote: post #69
mr__y wrote: post #65

Earlier quoted context omitted.

Depending on the code and the dependencies it might not be that free if you run on some unexpected problems after those upgrades due to some incompatibilities or even reliance on now-fixed bug. While I understand that the latter should not be the case given the code is written properly but with sufficiently large projects this is not as uncommon as we would like it to be. Also there is a more common scenario where up…

> easiest path for improving the performance. upgrading should not be seen as an alternative to performance engineering though. Even if upgrading _does_ bring in some performance improvements. Upgrading should be because of reasons such as security updates, and bug-fixes, and to continue to reap the improvements/features in the next version.

No, not an alternative, but I'd argue that considering new versions should be a part of performance engineering. If one of the "improvements/features in the next version" is more optimized and performant code, you want to "reap" it (after of course considering and testing the upgrade from other points of view.

Re: Scaling React Server Side Rendering

#127

Post by andrewingram »

minitech wrote: post #90
eliseumds wrote: post #70

I developed the JS architecture of https://www.productreview.com.au and we have faced tons of issues getting SSR right, but it was worth it. We're getting more than 10M pageviews a month and I'd like to share our experience: * Upgrading NodeJS indeed gives us massive performance boosts, but apply with caution. Ideally have a set of visual regression tests just to be safe * Profile your NodeJS code just like you do wi…

> * Properly serialize your JSON strings. That's what we use: https://gist.github.com/eliseumds/6192135660267e2c64180a8a9c... . That doesn’t look like “properly”. The double escaping is overcomplicated and no safer compared to a direct window.__productreview_data = ${escapedReduxStateJsonString}; (and forgets about \v, maybe others), the transformation doesn’t preserve “ Closer to correct: JSON.stringify(data) .repla…

I've been recommended this library rather than figuring it for myself:

https://github.com/yahoo/serialize-javascript

You can use it in JSON mode like this: `serialize(obj, {isJSON: true});`

Re: Scaling React Server Side Rendering

#128

Post by vorpalhex »

simonw wrote: post #10
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…

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…

Hopefully your site renders just fine without needing to throw servers at it. Unless you're getting into fancy webapp territory, just drop your page complexity.

Re: Scaling React Server Side Rendering

#130

Post by mhd »

hnbreak wrote: post #125
mhd wrote: post #118

Earlier quoted context omitted.

> But SPAs offer best UIs I don't consider this a settled conclusion. Mostly because it's a false dichotomy. There are alternatives to both SSR of component sites and SPAs, and every solution has its inherent advantages and disadvantages. UI isn't even the primary feature of an SPA, that would be offline usage. Having more interactive elements without page loads is a feature of "DHTML", and that can be had from anyth…

Good point and I agree that the borders between SPA and SSR are blurry. However, I just wanted to stress that a debate without having requirements is useless, it's like saying a racing car is better than a truck. But for what? Building websites is not like building websites 20 years ago. There are many uses cases and saying one is better than the other rather shows that you never experienced the other side. I mean, t…

Yeah, I never quite liked the currenly en vogue mixed approaches, where it's harder to draw a line, you often have to serve two masters and you feel it's mostly done that way because React developers don't want to learn anything else, despite cases where a complete server-side approach with an old-school template language might be a better fit, despite how hip functional reactive component based development is.

But about the smaller stacks other environments have: That's quite often because you either don't need additional parts (e.g. there's no desire for a huge Django template "community") and/or because other stacks are more full-fledged and thus the horizontal size is a lot smaller, with no need for umpteen state management solutions, state management solution helpers and state management solution application templates.

Dashboards could probably serve as a whole different topic. It was easy to beat the old school ones, where Perl CGIs roamed the prehistoric landscape. More modern CSS, and JS graphs alone beat the old rrdtool setups you often saw.

Post reply on HN