In part 1 of this two-parter, we delved into how the web evolved from its modest beginnings to the present day, and looked at how a decoupled architecture works in the context of a SPA frontend. Now, we look at why you might want to do it.
Advantages of decoupling
Better for users and site owners: Less waiting to load
According to Google, 53% of users will abandon a site if it takes longer than 3 seconds to load. Using an SPA, after the initial load, the interface elements remain loaded and painted in the user’s browser (unless you’re using server-side rendering, but let’s leave that for another blog). This means that navigating around the app involves updating what is already loaded, rather than requesting brand new (or repainting cached) content each time.
The ready-loaded app makes API requests, the responses of which contain just the raw data the app needs to correctly display. The result of this is instead of seeing a blank white window as the browser loads the content of the link they clicked, the user can see a loading bar in-keeping with the site’s design, giving developers greater control over the users’ experience.
Better for users: PWAs — websites as apps
A decoupled architecture allows easy implementation of a SPA frontend in frameworks like Vue, which make it easy to create Progressive Web Apps (PWAs). PWAs are a concept championed by Google. According to them, these are the key features:
- Progressive — Work for every user, regardless of browser choice because they’re built with progressive enhancement as a core tenet.
- Responsive — Fit any form factor: desktop, mobile, tablet, or forms yet to emerge.
- Connectivity independent — Service workers allow work offline, or on low-quality networks.
- App-like — Feel like an app to the user with app-style interactions and navigation.
- Fresh — Always up-to-date thanks to the service worker update process.
- Safe — Served via HTTPS to prevent snooping and ensure content hasn’t been tampered with.
- Discoverable — Are identifiable as “applications” thanks to W3C manifests and service worker registration scope allowing search engines to find them.
- Re-engageable — Make re-engagement easy through features like push notifications.
- Installable — Allow users to “keep” apps they find most useful on their home screen without the hassle of an app store.
- Linkable — Easily shared via a URL and do not require complex installation.
Better for developers: Separation of concerns
Separation of concerns means that code/markup/styling is not mixed with code/markup/styling responsible for unrelated things. The creation of CSS was to separate the concern of presentation from that of the structure (HTML), for example.
In a web app, there will typically be a number of concerns. In a monolithic app, these concerns would (hopefully) be organised to keep their roles and functions distinct, but there are some scenarios it’s common for them to cross under.
Separating concerns is good, because:
- To change a feature, there is less chance of code relating to other features requiring changes too
- There is less chance of breaking an unrelated feature
- If a developer is only responsible for one part of the system, they don’t need to understand other parts to work on it
Better for third parties: Services that can communicate
Your app’s frontend doesn’t need to be the only thing that communicates with your app’s backend. No sir. The great thing about having an API is that you can grant other parties access to it, meaning their system can perform operations on your system.
Say you’ve created an app that tells you the top 100 songs in the charts in a given year. If you grant applications other than the frontend you wrote for it access to its API, another developer could write a WordPress plugin that lets bloggers include that feature on their site.
Downsides of decoupling
For all the wondrous possibilities decoupled web apps offer, I would be neglecting my responsibilities as a balanced arbiter if I didn’t address the less fine aspects of the approach.
The learning curve
As with any new skill, there are new concepts to learn. Creating RESTful APIs, the framework of choice and authentication are just a few things that may be new to monolithic application developers.
Suitability for smaller projects
Writing an app that allows users to submit their email address to a mailing list and nothing more? Don’t want to provide an API? Perhaps a decoupled app is overkill where a simple PHP page will suffice.
Additional point(s) of failure
Both monolithic and decoupled applications have client-side and server-side code, but in a decoupled application, the communication of the front and backends via the API is theoretically a potential point of failure. Similarly, if the app uses authentication, the authentication service is another.
In practice though, if the app is well made and authentication properly implemented, failures should be as infrequent as in a monolith.
In a decoupled web app, it’s common for the backend’s API to be served from a different origin to the frontend.
For example, a single page app might be hosted at example.com, with its API hosted at api.example.com. Modern browsers have a mechanism called Cross-Origin Resource Sharing that prevents requests being made from a site to a resource of a different origin (protocol, domain or port) unless the server sends a header to explicitly allow it. Cross-origin requests that contain certain commonly used headers like the Authorization header are preceded by a preflight request to make sure the server will accept the actual request before sending it.
This means that a common way to implement a decoupled web app architecture can lead to two requests being sent for each API action, which can result in actions taking slightly longer to complete. This delay is measurable in milliseconds but may be more noticeable on slower connections.
He concludes on this:
- A decoupled WordPress site. Frontend written in Vue, with a WordPress backend:
- A slightly more complex SPA written in React: https://risingstars.js.org/2017/en/
- A clone of Hackernews made as an SPA using Vue: http://vuejs.github.io/vue-hackernews/#!/news/1
A decoupled app architecture is not a silver bullet for every complication, nor is it the only way to make an app the world will envy, but in giving the user an interface to interact with the system before anything else, a decoupled architecture allows you to create a rich user experience, freeing users of interruptions that can turn them off a site, streamline development, more easily implement CI/CD and open up your service to work with third parties. You can also experience the joy that is developing in Vue.
- MDN – Progressive Web Apps
- An SEO’s survival guide to Single Page Applications (SPAs)
- Vue.js & the WordPress REST Api on a large content site
- Progressive Web Apps: Escaping Tabs Without Losing Our Soul
- Google Web Fundamentals
- Google Progressive Web Apps
- Perks of a decoupled architecture