Photo of someone working on a laptop with a larger monitor behind the laptop

Moving from the monolith Part 1, or: How I learned to stop worrying and embrace Single Page Applications

Introduction

The evolution of JavaScript from its initial form, hastily written in 10 days, to its substantially developed current form, which allows the browser to update its content dynamically from new requests, has changed the paradigm of the web. Where there were static pages, there are now interactive apps.

We’re now rounding a corner where Progressive Web Apps (PWAs) allow what we would once call a website to act more like a slick native application using Single Page Application (SPA) frameworks like Angular and Vue.

Team Eco have been doing some work with Vue to create a decoupled front and backend system, and we’re rather enthusiastic about it. In this two-parter, I’ll cover what a decoupled architecture is, before extolling the virtues of doing things this way, compared to the monolithic way.

Decoupling what should be output from the files processing things behind the scenes simplifies the development process and, if you have different frontend and backend developers, lets each focus on their area of expertise.

Before getting to that though, maybe it’s a good idea to start at the beginning (of the web).

‘Member when things were static?

The web has come a long way since the internet was used to host the first web page in 1991. The advent of the world wide web was essentially the creation of three technologies it’s easy to take for granted:

  1. A method to locate resources (URLs/URIs)
  2. A method to transport those resources between client and server (HTTP)
  3. A way to structure data to be displayed and fetch additional media to clients (HTML)

URLs/URIs haven’t changed in a particularly noteworthy way over the years. HTTP also remained remarkably unchanged until relatively recently, with HTTP/2, but our focus here is the content that is served.

In the olden days, the World Wide Web was talked about in library-like terms. You opened web pages on your browser. You marked web pages you wanted to come back to using bookmarks. When you went to a website, your browser loaded a web page as a static electronic document.

The content was served as HTML (which is still a key part of the web), but not much more. HTML is a markup language that specifies content and what it is. “Hello world!” is a heading; “This is my first website.” is a paragraph, next output an image hosted at this location, etc.

By today’s standards, it’s not too flashy, but the result would be a series of static pages you could request and navigate using links. Here’s the world’s first website in all its glory to demonstrate.

Dynamism: From DHMTL to AJAX

Though early HTML allowed for some presentational styling through attributes of elements, it was the creation of CSS that brought a standardised way to style web content based in a way that separated content from presentation. The creation of JavaScript then allowed that content and styling to be manipulated by user actions, making page content dynamic within the browser. Dynamic HTML (or DHTML) was born.

Interactivity is a key requirement for a user interface, but for most purposes, that interface also needs to be able to communicate with external entities and update itself based on the outcome of those communications.

A new addition to the JavaScript environment called IXMLHTTPRequest became available with Microsoft Internet Explorer 5.0 in 1999, which was a forerunner of the XMLHttpRequest (XHR) object.

This XHR object allowed JavaScript code to make HTTP requests without the browser itself updating the address bar or site content. The requested resource would then return content, often itself HTML or XML in the earlier days, more often JSON now. Code can then be written to handle the result of that request and update the browser’s content selectively according to the developer’s will, rather than loading a whole new “page”.

At this level of interactivity, the experience is more akin to an application than static pages, which is why there’s increasing talk of web applications instead of websites. But more on that later. The web application here is a single entity though; a monolith. What happens when we break it apart?

Decoupling front from backend

When we talk about decoupling, what exactly is decoupled from what? In the context of web app architecture, the frontend (the user interface) is decoupled from the backend (the bit on the server that processes and stores the data).

Rather than writing an app in PHP files (other server-side languages are available) that generate/include HTML, CSS and JavaScript for the browser to parse, we instead write a frontend consisting of that HTML, CSS and JavaScript. That frontend then makes new requests to a backend that receives, processes and returns only pure data.

Let’s start by comparing that to a monolithic web app. Here’s a simplified version of how a monolithic app works:

Flow chart of how a monolithic application is produced.

Here, when you as the user type the URL of the app into the browser’s address bar, it makes a request for content. The server will receive the request and either directly serve HTML, CSS, JavaScript and images, or run some code that dynamically generates that HTML, CSS, JavaScript and/or images. AJAX might be used on some of the pages that the monolithic app returns, but if the URL is changed, the page reloads afresh.

Now let’s return to a decoupled web app using a SPA framework:

Flow chart of a decoupled web app using a single page application framework

Here, the initial request for the app doesn’t return a view, but returns a single page, containing all the styling and code for the frontend.

All subsequent requests on that site (i.e. the links) don’t request new pages in the browser, rather they instead make calls from the frontend app to the backend, via an API layer.

API stands for Application Programming Interface and is a standardised way for our frontend to communicate with our backend by making HTTP requests. It then returns data in a standardised format (JSON being the most widely adopted). It makes these requests using XHR, meaning a request is essentially an AJAX one, but here, XHR is central to navigating the app, rather than just augmenting it.

The API returns just raw data (no styling, no code). The response of these API calls containing the output of the backend’s work is then used to update the frontend user interface.

Isn’t this more complicated?

Well, to look at the diagram above, yes. Once you’ve got your head around the concept though, development actually becomes easier. Why? Backend logic is separated from frontend rendering. Frontend rendering is centred about what the user views, whereas backend logic tends to focus on processing and storing data.

With a monolithic app, though you can of course (and should) organise code to separate code responsible for the view from code responsible for data processing, more often than not, a file will contain both frontend languages (HTML, CSS, JavaScript) and backend languages (for Eco Web Hosting, PHP).

This makes files difficult to read and makes it difficult to run linting for the different languages contained within. Decoupling what should be output from the files processing things behind the scenes simplifies the development process and, if you have different frontend and backend developers, lets each focus on their area of expertise.

Simplified developing is not the only bonus though. Stay tuned for part two to see what perks are on offer!