In chapter 4, we discussed how to create a single-page application (SPA) with Angular and then talked about accessing the Order Processing microservice from the SPA. SPA is already a popular architectural pattern for building applications against a set of APIs. In fact, the rise of API adoption had a great influence in moving developers to build SPAs. In this appendix, we discuss the basic principles behind the SPA architecture. If you are interested in learning the SPA architecture in depth, we recommend SPA Design and Architecture (Manning, 2015) by Emmit A. Scott, Jr.

C.1 What is single-page application architecture?

A single-page application (SPA) is an architectural pattern used to develop frontend, user-facing web applications. In a traditional multiple-page application (MPA) architecture, when a web browser makes a request to the web server, the web server first loads the data (content) required for the requested web page (by reading a database, talking to other external services, and so on), generates the HTML content, and provides it to the web browser for rendering.

Notice the word HTML in the preceding sentence. In this case, the server is responsible for generating multiple HTML pages for the browser to render, which is why these types of applications are known as multipage applications. As illustrated in figure C.1, when the web browser makes a request for a particular page, the web server requests data from a data source and generates the HTML content using that data. This HTML content is then sent back to the web browser.

Figure C.1 An MPA loads content to the browser with multiple page reloads.

A SPA, on the other hand, loads the initial HTML, Cascading Style Sheets (CSS), and JavaScript to the browser when loading the application for the first time. On requests to fetch further data, the SPA directly downloads the actual data--in JavaScript Object Notation (JSON) or whatever the data format is--from the web server. The generation of dynamic HTML content happens on the browser itself through the JavaScript that’s already loaded (and cached). Figure C.2 illustrates the flow of actions for a SPA.

Most of the modern websites you use today follow this pattern. If you’ve used Gmail, Google Maps, Facebook, Twitter, Airbnb, Netflix, PayPal, and the like, you’ve used a SPA. All these websites use this design to load content into your web browser.

A typical difference between an MPA and a SPA is that in an MPA, each request for new content reloads the web page. But in a SPA, after the application has been loaded into the browser, no page reloads happen. All new content is rendered on the browser itself without any requests to the web server. The SPA talks to different endpoints (APIs) to retrieve new content, but the rendering of that content happens in the browser.

The reason these are called single-page applications is that most of them have only one HTML file (a single page) for the entire application. The content of the website is rendered by dynamically changing the HTML of the file upon user actions.

Figure C.2 Any web application that follows this architectural pattern is known as a SPA. A SPA loads content to the browser with no page reloads.

C.2 Benefits of a SPA over an MPA

A SPA has several benefits compared to an MPA, some of which are specifically useful for microservices architectures:

• Beyond the initial loading of the application, page rendering is faster because the generation of HTML happens on the client side (browser) and the amount of data being downloaded is reduced (no HTML; mostly JSON content). The HTML, CSS, and JavaScript are loaded once throughout the lifespan of the application.

• The load on the web server is reduced because the server has been relieved of the responsibility to generate HTML content. This thereby reduces the need for the web application to scale, saving a lot of problems related to handling sessions. Each request to backend APIs will carry a token (for authentication), and it’s the responsibility of each API endpoint to manage how it wants to handle sessions.

• Because the application design is simple (HTML, CSS, and JavaScript only), the application can be hosted in any type of environment that can be accessed over HTTP and doesn’t require advanced web server capabilities.

• The application becomes more flexible because it can easily be changed to talk to any number of microservices (via APIs) for fetching data and rendering as appropriate.

• Because SPAs retrieve data mostly from standard HTTP-based REST APIs, they can cache data effectively and use that data offline. A well-implemented REST API supports HTTP ETags and similar cache validations, making it easy for browsers to store, validate, and use client-side caches effectively.1

C.3 Drawbacks of a SPA compared with an MPA

SPAs don’t come for free, however. They have drawbacks that you need to think about carefully before committing to implementing them. Luckily, engineers have found ways to overcome the limitations in SPA architectures:

• The rendering of content happens through JavaScript. If the pages contain heavy or unresponsive JavaScript, these can affect the browser process of the application user.

• Because the application relies on JavaScript, it becomes more prone to cross-site scripting (XSS) attacks; therefore, developers have to be extra cautious.

• SPAs won’t work on browsers that have JavaScript disabled. Workarounds exist for these cases, but these don’t help you reap the benefits of a SPA.

• The initial loading of the application into the browser can be slow because it involves loading all the HTML, CSS, and JavaScript. Workarounds are available to improve the loading time, however.

• The application would find it hard to deal with sensitive information such as user credentials or tokens because it works primarily on the client side (browser).