For quite some time, client-server architecture was one of the most widespread patterns in large-scale software development. Even systems that run purely on one computer are often designed this way. This allows us to clearly separate concerns: the server takes care of heavy business logic, persistent storage, accessing data from third-party services, and so on, and the client is responsible solely for presentation to end users.

This architecture also allows us to have multiple clients connected to one backend: mobile apps, IoT devices, third-party REST API consumers (for example, external developers), and the web, for example.

In the early days of web development, it was not that way though. Servers were responsible for everything. Usually, it was a combination of DB, app itself, template engine, a bunch of static assets (images, CSS, and so on) all baked together into a monolithic app. Later on, it became obvious that this kind of architecture does not scale well.

Nowadays, the modern web is moving back to client-server architecture with a clean separation of concerns and concrete responsibilities for each component. Server-side apps deal with data and client-side apps deal with presentation of that data.

We will cover the following topics in this chapter:

• What is a single-page app?
• Introduction to React
• Single-page app performance issues
• Server-side rendering with React

A single-page app implements this architecture for web clients: the JavaScript app launches from a web page and then runs entirely in the browser. All visual changes on the website happen as a reaction to user actions and the data received from the remote APIs.

It is called single-page because the server does not render pages for the client; it always delivers the same minimalistic markup required to bootstrap the JS app. All page rendering and navigation happens purely on the client, using JavaScript, which utilizes History APIs to dynamically swap page contents and URLs in the location bar.

The advantages that this approach gives are that the client can run something in the background between page transitions, and the client does not have to re-download and re-render the entire page in order to swap only the main content. Unfortunately, it also brings drawbacks, because now the client is responsible for all state changes. For the synchronization of such changes across the entire interface, it must know when to load the data and what particular data. In other words, a server-generated app is conceptually a way simpler thing, thanks to the REST service + JS client.

Separation of concerns is one of the key principles in software design, and since each entity in the code has to be isolated from others, it makes sense to put them into separate files to simplify the navigation and ensure isolation.

Modern JS applications consist of modules that can have exports and imports. JS modules export some entities and may consume exported entities from other modules.

In this book, we will use the latest JS syntax with classes, arrow functions, spread operators, and so on. If you are not familiar with this syntax, you can always refer to it here: http://exploringjs.com.

The simplest JS module looks like this:

// A.js:
export const noop = () => {};

This file now has a named export, noop, which is an arrow function that does nothing.

Now in B.js, we can import a function from the A.js file:

//B.js:
import {noop} from "./A.js";
noop();

In the real world, dependencies are much more complex and modules can export dozens of entities and import dozens of other modules, including those from NPM. The module system in JS allows us to statically trace all dependencies and figure out ways to optimize them.

If the client downloads all JS in a straightforward way (for example, initially downloading one JS file, parsing its dependencies, and recursively downloading them and their deps), then load time will be dramatic, first of all because network interaction takes time. Secondly, because parsing also takes time. Simultaneous connections are often limited by browser (the amount of HTTP threads) and HTTP 2.0, which allows us to transfer many files through one connection, is not yet available everywhere, so it makes sense to bundle all assets into one big bundle and deliver them all at once.

In order to do this, we can use a bundler like Webpack or Rollup. These bundlers are capable of tracing all dependencies starting from the initial module up to leaf ones and packing those modules together in a single bundle. Also, if configured, they allow us to minify the bundle using UglifyJS or any other compressor; this reduces the bundle size dramatically. Minification is a process where all unnecessary things are stripped out of the bundle, such as whitespaces and comments, all variables are named a, b, and so on, and all syntax constructions are simplified. After minification, we can also gzip the output if the server and client allow this.

But the bundle approach also have caveats. A bundle may contain things that are not required to render a particular requested page. Basically, the client can download a huge initial bundle but in fact need only 30-40% of it.

Modern bundlers allow us to split the app into smaller chunks and progressively load them on demand. In order to create a code split point, we can use the dynamic import syntax:

//B.js:
import('./A.js').then(({noop}) => {
 noop();
});

Now, the build tool can see that certain modules should not be included in the initial chunk and can be loaded on demand. But on the other hand, if those chunks are too granular, we will return to the starting point with tons of small files.

Unfortunately, if chunks are less granular, then most likely they will have some modules included in more than one chunk. Those common modules (primarily the ones installed from NPM) could be moved to so-called common chunks. The goal is to find an optimal balance between initial bundle size, common chunk size, and the size of code-split chunks. Webpack (or other bundlers such as Parcel or Rollup) can optimize it a bit, but a certain amount of manual tuning is required for best results.

In this section, we will create a simple React-based project and will learn how this library works and what its core concepts are.

Let's create an empty project folder and initialize NPM:

$ mkdir learn-react
$ cd learn-react
$ npm init
$ npm install react react-dom --save

The quickest way to get started with React is to use the react-scripts package:

$ npm install react-scripts --save-dev

Now, let's add a start script to package.json:

{
  "scripts": {
    "start": "react-scripts start"
  }
}

NPM auto-binds CLI scripts installed in the node_modules/.bin directory along with the packages, so we can use them in package.json scripts directly.

The smallest possible setup for a React app is the following: we need a landing HTML page and one script with the app.

Let's start with the bedrock HTML:

<!--public/index.html-->
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Learn React</title>
</head>
<body>
  <div id="app"></div>
</body>
</html>

And here is the main JS file:

//src/index.js:
import React from "react";
import {render} from "react-dom";
render(
  <h1>It works!</h1>,
  document.getElementById('app')
);

This is it. Now, we can run the command to start the development server:

$ npm start

It will open port 3000 on the localhost. Open the URL http://localhost:3000 in your browser; the index.js script will be run and the render function will render an HTML page with "It works!" in it.

The simplest React component is just a function that takes props as an argument and returns JSX:

const Cmp = ({children, ...props}) => (<div {...props}>{children}</div>);

JSX is HTML with the ability to insert and execute JS in it. In this example, we inject variables into a tag as properties and as content.

A more complicated component may have state:

class Cmp extends React.Component {
  state = {value: 'init'};
  onClick = (event) => { this.setState({value: 'clicked'}); };
  render() {
    return (
      <button onClick={this.onClick}>{this.state.value}</button>
     );
  }
}

Components may have static properties:

class Cmp extends React.Component {
  static foo = 'foo';
}

or

Cmp.foo = 'foo';

These static properties are often used to describe some meta-information about the components:

import PropTypes from "prop-types";
Cmp.propTypes = {
  propName: PropTypes.string
};

Next.js utilizes static properties heavily and we will show you how later.

The simplest way to achieve code splitting in a React application is to store the entire progressively-loaded component in the state:

class Cmp extends React.Component {
  state = {Sub: null};
  onClick = async (event) => {
    const Sub = (await import('./path/to/Sub.js')).default;
    this.setState({Sub});
  };
  render() {
    const {Sub} = this.state;
    return (
      <div>
        <button onClick={this.onClick}>Load</button>
        <Sub/>
      </div>
    );
  }
}

Another way to achieve code splitting is to use the React Router.

All React components have life cycle hooks that can be utilized, for example, to load the data from a remote server:

class Cmp extends React.Component {
  state = {data: null};
  async componentWillMount() {
    const data = await (await fetch('https://example.com')).json();
    this.setState({data});
  }
  render() {
    const {data} = this.state;
    return (
      <pre>
        {JSON.stringify(data)}
      </pre>
    );
  }
 }

The React API is of course much bigger than what was covered here, so please refer to the official documentation for more info. The things mentioned here are absolutely essential for Next.js, which is why we mentioned them.

In order to start, single-page apps (SPA) have to download lots of assets to the client: JS files with the app itself, CSS files with styles, images, media, and so on. It is impossible to develop a large-scale JS app without any kind of modularization, so most JS apps consist of numerous small JS files (the modules mentioned before). CSS files are also usually separated by some criteria: per component, per page, and so on.

The nature of SPAs forces them to have heavy API traffic. Basically, any user action that has to be persisted requires an API call. Pulling data from persistent storage also requires API calls. By persistent storage, here I mean the database or any other similar service that can be accessed from many different devices/browsers and will store this data for long periods of time.

Both of these aspects bring us to the most terrible SPA performance issue: large initial load time. There have been studies that clearly show the correlation between the load time and page views, conversion, and other vital metrics. On average, customers leave the page if it fails to load within 2-3 seconds.

Another big issue is search engine optimization (SEO). Search engines tend to give higher ranks to pages that load quicker. Plus, only recently have crawlers learned how to parse and crawl SPAs properly.

How do we deal with this?

Assume we have found a good balance between initial chunk and on-demand chunks. We have applied compression and good cache strategies, but still there is an API layer that also has to be optimized for initial load.

Potentially, we can combine all API requests in one huge request and load it. But different pages need different data, so we can't create a request that will fit all. Also, some of the data requires client-side processing before we can make a subsequent request for more data. Modern API techniques such as GraphQL allow us to solve the problem in one way, and we will talk about this later in the book, but this still does not address the issue with not-so-smart search engine crawlers.

Sad? Yes. There is a solution for that though. It is called server-side rendering.

Back in the old days, web pages were served as is by static servers. All navigation and interaction were based on those pages; you had to transition from one page to another, nothing was dynamic, and you could not show or hide a block of text, or do something similar.

Later, servers started to use templates to deliver HTML to the client. Languages such as Java, PHP, Python, ASP, VBScript, Perl, and Ruby were suitable for such tasks. Those pages were called server-generated. The interaction though was still the same: page transitions.

Then JavaScript and VBScript came into play for very simple client-side user interaction, just some hover effects and simple scripts here and there to show or hide server-generated content. Some time later, more complicated scenarios were introduced and the bias shifted towards the client side. Servers started to generate not only full templates, but also replaceable fragments to reflect more in-place changes, such as when the client sends a form via AJAX and receives from the server the HTML of this form with validation errors, client only swapped HTML pieces, it was not responsible for templating.

Later on, due to the shift towards REST APIs, a cleaner separation of concerns brought the industry away from server-generated approaches to fully JS-driven apps, which were capable of rendering the pure data into HTML by using client-side templates.

But in order to more efficiently load the initial data for a JS app, we can utilize the server-generated approach a little bit. We can render the initial markup on the server and then let the JS app take it over later. The main assumption here is the fact that the server-side renderer is usually much closer to the API server, ideally in the same data center, and thus it has much better connection and way more bandwidth than remote clients (browsers in our case). It also can utilize all benefits of HTTP2 or any other protocol to maintain fast data exchange.

The server can optimize rendering time by caching the results from rendering individual components or entire pages, indexed on a serialization of the parameters that affect the output - that are used by the component. This is particularly true of components or entire pages that will be viewed repeatedly in the same state, either just by one user or potentially by many different users. Where appropriate, this strategy may even allow the server-side renderer to reduce load on the API server, if cached component renders are given a TTL.

The server-side renderer is capable of doing all those chained requests much faster than clients, and all the codebase can be pre-loaded and pre-parsed. It can also use more aggressive data caching strategies, since invalidation can also be centrally maintained.

To decrease code duplication, we would like to use the same technology and the same templates both on the client and on the server. Such an app is called universal or isomorphic.

The general approach is as follows: we take the Node.js server, install a web framework, and start listening to incoming requests. On every request that matches a certain URL, we take the client scripts and use them to bootstrap the initial state of the app for the given page. Then, we serialize the resulting HTML and data, bake it together, and send it to the client.

The client immediately shows the markup and then bootstraps the app on the client, applying initial data and state, and hence taking control.

The next page transition will happen completely on the client; it will load data from regular API endpoints just like before. One of the trickiest parts of this approach is to make sure that the same page with the same HTML will be rendered both on the client and on the server, which means we need to make sure the client app will be bootstrapped in a certain state that will result in the same HTML.

This brings us to the choice of framework. Not all client-side frameworks are capable of server-side rendering; for instance, it would be quite challenging to write a jQuery app that will pick up state and render itself correctly on top of existing HTML.

Luckily, React is built with two main concepts in mind: it's state driven and it is capable of rendering to plain HTML. React is often used with React Router, so let's take this and explain how to render your React app on a server.

Nowadays, there are few competitors in the React-based server-side rendering market. We can divide them into the following categories:

• Drop-in dynamic solutions (Next.js, Electrode, After)
• Drop-in static solutions (Gatsby, React Static)
• Custom solutions

The main difference between first two approaches is the way the app is built and served.

A static solution makes a static HTML build (with all possible router pages), and then this build can be served by a static server such as Nginx, Apache, or any other. All HTML is pre-baked, as well as the initial state. This is very suitable for websites with incremental content updates that happen infrequently, for example, for a blog.

The dynamic solution generates HTML on the fly every time the client requests it. This means we can put in any dynamic logic, or any dynamic HTML blocks such as per-request ads and so on. But the drawback is that it requires a long-running server.
This server has to be monitored and ideally should become a cluster of servers for redundancy to make sure it's highly available.

We will make the main focus of this book dynamic solutions, as they are more flexible and more complex but also require deeper understanding.

Lets dive deeper into a custom solution using only React and React Router.

Let's install the router and special package to configure routes statically (it's impossible to generate purely dynamic routes on a server):

npm i --save react-router-dom react-router-config

Now, let's configure the routes:

// routes.js
const routes = [
  {
    path: '/',
    exact: true,
    component: Index
  },
  {
    path: '/list',
    component: List
  }
];
export default routes;

The main app entry point should look like this:

// index.js
import React from 'react';
import {render} from 'react-dom';
import BrowserRouter from 'react-router-dom/BrowserRouter';
import {renderRoutes} from 'react-router-config';
import routes from './routes';

const Router = () => {
  return (
    <BrowserRouter>
      {renderRoutes(routes)}
    </BrowserRouter>
  )
};

render(<Router />, document.getElementById('app'));

On the server, we will have the following:

import express from 'express';
import React from 'react';
import { renderToString } from 'react-dom/server';
import StaticRouter from 'react-router-dom/StaticRouter';
import { renderRoutes } from 'react-router-config';
import routes from './src/routes';

const app = express();

app.get('*', (req, res) => {
  let context = {}; // pre-fill somehow
  const content = renderToString(
    <StaticRouter location={req.url} context={context}>
      {renderRoutes(routes)}
    </StaticRouter>
  );
  res.render('index', {title: 'SSR', content });
}); 

But, this will simply render the page with no data. In order to prepopulate data into the page, we need to do the following, both in the component and in the server:

1. Each data-enabled component must expose a method that the server should call during route resolution
2. The server iterates over all matched components and utilizes exposed methods
3. The server collects the data and puts it into storage
4. The server renders the HTML using routes and data from storage
5. The server sends to the client the resulting HTML, along with data
6. The client initializes using the HTML and prepopulates the state using data

We intentionally won't show steps 3 and onward, because there is no generic way for pure React and React Router. For storage, most solutions will use Redux and this is a whole another topic. So, here we just show the basic principle:

// list.js
import React from "react";

const getText = async () => (await (await fetch('https://api.github.com/users/octocat')).text());

export default class List extends React.Component {

  state = {text: ''};

  static async getInitialProps(context) {
    context.text = await getText();
  }

  async componentWillMount() {
    const text = await getText();
    this.setState({text})
  }
  
  render() {
    const {staticContext} = this.props;
    let {text} = this.state;
    if (staticContext && !text) text = staticContext.text;
    return (
      <pre>Text: {text}</pre>
    );
  }

}

// server.js
// all from above
app.get('*', (req, res) => {
  const {url} = req;
  const matches = matchRoutes(routes, url);
  const context = {};
  const promises = matches.map(({route}) => {
    const getInitialProps = route.component.getInitialProps;
    return getInitialProps ? getInitialProps(context) : Promise.resolve(null)
  });
  return Promise.all(promises).then(() => {
    console.log('Context', context);
    const content = renderToString(
      <StaticRouter location={url} context={context}>
        {renderRoutes(routes)}
      </StaticRouter>
    );
    res.render('index', {title: 'SSR', content});
  });
});

The reason why we are not covering those aspects is because even after heavy development, it becomes obvious that the custom solution still has quirks and glitches, primarily because React Router was not meant to be used on a server, so every custom solution always has some hacks. Even the authors of React Router say that they decided not to use server-side rendering in their projects. So, it would be much better to take a stable/standard solution that was built with server-side rendering in mind from day one.

Among other competitors, Next.js stands out as one of the pioneers of this approach; this framework is currently the most popular. It offers a very convenient API, easy installation, zero configuration, and a huge community. Electrode may be more flexible and powerful than Next.js, but it has extremely complicated configuration. After this is a Next.js-alike framework, which is built on top of React Router, Helmet and other familiar libraries, but the community is still relatively small so far, although it definitely worth to mention.

A full comparison is available in my article here: https://medium.com/disdj/solutions-for-react-app-development-f9fcaeba504.

In this chapter, we learned how web apps evolved over time from simple server-generated pages to single-page apps, and then back to server-generated pages with SPAs on top. We learned what React JS is and how to do server-rendering of a React application.

In the next chapter, we will use this knowledge to build a more advanced application that still follows these core principles.