E Single-page application (SPA) architecture
highlight, annotate, and bookmark
You can automatically highlight by performing the text selection while keeping the alt/ key pressed.
E.1 What is single-page application (SPA) architecture?
A 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 the HTML for the browser to render, as shown in figure E.1. The reason these types of applications are known as multi-page applications is because it is the server which is responsible for generating the pages that are rendered on the web browser. As illustrated in figure E.1 when the web browser makes a request for a particular page, the web server requests for data from a data-source and generates the HTML content using that data. This HTML content is what is then sent back to the web browser.
Figure E.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 upon loading the application to the browser for the first time. On requests to fetch further data, it directly downloads the actual data (JavaScript Object Notation [JSON] or whatever the data format is) from the web server. The generation of the dynamic HTML content happens on the browser itself through the JavaScript that is already loaded (and cached) on the browser. Figure E.2 illustrates the flow of actions.
Figure E.2 A SPA loads content to the browser with no page reloads.
Any web application that follows this architectural pattern is known as 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 would talk to different endpoints (APIs) to retrieve new content, but the rendering of that content happens in the browser.
The reason these applications are called single-page 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. You’ll see how this works in examples later in the chapter.
discuss
E.2 Benefits of a SPA over an MPA
A SPA has several benefits compared with an MPA, some of which are specifically useful for microservice 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 only). The HTML, CSS, and JavaScript are loaded once throughout the lifespan of the application.
- Load on the web server is reduced because the server has been relieved of the responsibility to generate HTML content, thereby reducing the need for the web application to scale, saving a lot of problems related to handling sessions.
- Because the application design is simple (HTML, CSS, and JavaScript only), the application can be hosted in any type of hosting environment that can be accessed over HTTP and doesn’t require advanced web server capabilities.
- The application becomes 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 them offline. A well-implemented REST API supports HTTP ETags[2] and similar cache validations, making it easy for browsers to store, validate, and use client-side caches effectively.
settings
E.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:
- The rendering of content happens through JavaScript. If the pages contain heavy or unresponsive JavaScript, they may 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. There are workarounds for these cases, but they 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. There are ways to improve the loading time by using workarounds, 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).
Luckily enough, engineers have found ways to overcome the limitations in SPA architectures.
[2]An HTTP ETag is one of several mechanisms HTTP provides for web cache validations.