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.
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:
- A method to locate resources (URLs/URIs)
- A method to transport those resources between client and server (HTTP)
- 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
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.
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).
Let’s start by comparing that to a monolithic web app. Here’s a simplified version of how a monolithic app works:
Now let’s return to a decoupled web app using a SPA 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.
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!