Headless, not like the horseman Ichabod Crane claimed to see, but referring to the User Interface or UI. Moving from a tightly coupled server delivered UI to a headless API and a statically served application UI leads us to the architectural design concept of the JAM Stack. This starts our journey into our headless design.
The JavaScript, API, and Markup (JAM) stack architecture provides a number of improvements over the typical server generated UI and conforms with another major theme I’ve written on which is a highly distributed future. JAM utilizes JavaScript, an API and HTML Markup, either as statically generated HTML content or a dynamic single page application to deliver a highly distributed and thus scalable design solution.
Statically generated HTML is by far the most performant when delivering a UI. A number of tools are available for this purpose: Hugo, Jekyll, Nikola, and Gatsby to name a few. With some extra tooling, and a web-component library, ultra-light weight applications can be delivered nearly instantly as the payloads can be small and no additional rendering is required to display in the browser.
JAM Stack
JAM provides numerous benefits including:
Higher Security: security should always be top of mind when developing software. Security can be hard and especially so with various frameworks such as WordPress or others that support “ease-of-use” and plug-in extensions. With a JAM design we have a clean separation of concerns (SoC) making analysis a bit easier and reducing the attack surface with read-only files.
Loose Coupling: A loosely coupled design wins every time. Loose Coupling and High Cohesion are hallmarks of great software. I’ll discuss this more in a later section. Your UI lives on CDN’s and your APIs are microservices. Period.
Highly Scalable: Loosely coupled designs allow for ease of scalability as we have a highly modular design allowing for distributed resources and scalability options.
High Reliability: highly reliable sites can be delivered as the UI assets can be hosted on Content Delivery Networks (CDNs) delivering both high performance cached assets served from a geographically distributed server and reliability given the redundancy of the CDN network.
Decoupled and Headless — A beautiful combination
Let’s take a deeper look at decoupled applications which are at the core of a headless system. As mentioned earlier, a major hallmark of great software design is the dual concept of Loose Coupling and High Cohesion. You may have heard these phrases, but let’s dive into them a bit more and see why they’re so important.
Loose Coupling
The concept of minimal dependencies among classes or modules. Minimal dependencies mean that classes or modules can exist without another. Modules can be shared and accessed from various other modules and combined with clean consistent interfaces and other design patterns, can make a developers and the product managers life much more manageable especially in the fast-paced agile processes we find ourselves in today. Clean modular design also cuts down on technical debt and the eventual clean-up associated with that debt. An additional benefit is testing, unit testing loosely coupled modules is a breeze whereas tightly coupled modules become a nightmare and lead to confusion and possibly no testing at all.
High Cohesion
Putting things together that belong together, like chocolate and peanut butter? The idea of grouping together methods or behaviors that are similar or can be thought of as a group. Low cohesion on the other hand gives us a scattered approach and will leave people scratching their heads as they wonder which module or class to use rather than having everything close at hand. This also leads to possible replication and runs counter to the concept of Don’t Repeat Yourself (DRY). High cohesion also bring a bit of art to the mix as decision points arise as to how various methods are grouped. A good rule of thumb is to typically look at your domain model and use cases as the driver of these decisions.
Freedom of choice
With these fundamental concepts in hand, we now have a basis from which to design our headless system and much more freedom to choose what tools we wish to use and how to use them. Headless gives us the ability to choose our Frontend or UI framework — or no framework at all. We may opt to use Plain Ole’ JavaScript or go with one of those libraries like React or a full-blown framework like Angular. We can, using the concepts of loose coupling and high cohesion, begin formulating our idea of interacting with a Microservices API which we’ll delve into later in more detail.
The freedom to choose the UI which, being a statically delivered web site or application, can now reside on CDN’s giving us high scalability, redundancy, and thus reliability and performance. Decoupled microservice APIs give us highly modular systems that can also be distributed and live anywhere on the cloud, if we wish.
That’s it for this article, I’ll dive deeper into the Microservices API in the next article.
Please give me a clap or follow as I’ll be trying to post more articles in this series in my limited time as my day job has kept me quite busy of late.
