Scaling React Server Side Rendering

Post by pmontra » Mon, Dec 30, 2019, 11:17 PM UTC

a13n wrote: post #58

tannhaeuser wrote: post #44

Earlier quoted context omitted.

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.

Post by dvt » Mon, Dec 30, 2019, 11:25 PM UTC

a13n wrote: post #59

dvt wrote: post #39

Earlier quoted context omitted.

> 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?

      /**
       * We have to force the bundling of @elastic/eui and react-ace
       * as Gatsby, then all loaders below will match and avoid HTMLElement issues
       */
      config.externals = config.externals.map(fn => {
        return (context, request, callback) => {
          if (request.indexOf('@elastic/eui') > -1 || request.indexOf('react-ace') > -1) {
            return callback();
          }

          return fn(context, request, callback);
        };
      });

      config.module.rules.push(
        {
          test: /react-ace/,
          use: 'null-loader',
        },
      );

Post by mr__y » Mon, Dec 30, 2019, 11:43 PM UTC

frandroid wrote: post #55

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 eff…

Post by rhizome » Mon, Dec 30, 2019, 11:47 PM UTC

pmontra wrote: post #60

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 by chii » Tue, Dec 31, 2019, 12:25 AM UTC

mr__y wrote: post #65

frandroid wrote: post #55

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 eff…

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…