TLDR: Summary, Main Takeaways and Tips
- JavaScript has allowed for the development of full-featured user interface applications that run entirely on a web browser, called Single Page Apps
- SPAs need to communicate via Ajax to a web server running a back-end app
- A server app that exposes all of its features via API only may be called Headless, and any user interface may be connected to it (perhaps a better naming would have been Multihead?)
- Many e-commerce platforms still use a full-stack approach or a hybrid
- There are pros and cons to using Full-stack or Headless — be sure to know what they are
- If going a multi-channel route, consider going with a Headless API-first approach
- Headless is a possible solution to the multi-channel experience inconsistency problem
- Migrating one or a set of full-stack platforms to Headless is quite an endeavor and requires considerable replatforming investments and the right talent
- Headless is a great fit for online-first DTC brands that seek to provide a unified user experience across several channels
- When evaluating SaaS solutions to extend a Headless platform functionality, make sure the SaaS is also Headless (or at least has a very comprehensive API).
Single Page Applications and the Headless Approach
In 1991, still in its origins, the web was designed to serve full-formed documents in each server response. Upon the click of a link the server would return an entire document (in HTML format), with all necessary information for the web browser to render that page. Each interaction with the web page would yield an entirely new web page, even if the new document had very little changes compared to the previous page.
In its simplest and most traditional form, browsing the Web is simply requesting the document from the server and letting the web browser render it. In the context of e-commerce for instance, if we’d like to access the product “123”, a simple request to “/product/123” could return a HTML document containing all the information about that product together with all the layout information necessary for the browser to display it nicely.
Over time, web browsers were armed up with JavaScript and its related set of technologies (which became known as Ajax or Asynchronous JavaScript and XML), allowing for business logic (or more sophisticated UI rendering logic and events) to be executed in the browser, and for partial data (XML or JSON) to be transferred between the browser and the server. An immediate application of this was to allow partial layout changes of the web page (getting only the delta from the server) without having to render a whole new document again. This set of technologies paved the way to today’s modern SPAs (Single Page Applications), which are full-featured applications running on the web browser and that communicate with the server via Ajax *only* (essentially eliminating the original concept of hyperlinks altogether).
With SPAs, the server does not have to return HTML documents anymore. All layout and its logic resides in the JavaScript application, and only JSON data is exchanged with the server — by going full Ajax. As a result, the application running on the server does not need to care about UI anymore — which is now fully handled by the SPA. This is in line with the concept of SoC (Separation of Concerns) in which the SPA front-end is responsible for UI and communication with the server, and the server is only responsible for computing data that it receives. The interface (between SPA and server application) by which this communication takes place is known as a Web API, and the data interchange format is most commonly JSON (JavaScript Object Notation), but any other data format may be used.
Headless vs. Full-stack
In the context of e-commerce, the user interface can be thought of as the “head” of the platform, because it’s the tangible part that the customer interacts with. In many e-commerce platforms, the head is still very much strongly attached to the entire platform and cannot be easily removed (much of the UI is rendered by the platform running on the server, yielding a full HTML document as output). In fact, these platforms usually employ a hybrid approach, in which many pages are served through the traditional way of having the server create the full HTML document, and a JavaScript application running on the browser is responsible for making Ajax requests to the server and thereby performing partial changes to the original documents. E-commerce platforms that make use of server-side UI logic (in full or hybrid) may be called “full-stack”, whereas e-commerce platforms that have gone the full SPA route may be called “headless”.
Each approach has its pros and cons. Let’s have a look at a few.
Full-stack PROS:
- Easier to handle SEO and real-time web scraping bots (Facebook, Whatsapp, etc)
- No need for creating a front-end application from scratch, as is usually already comes bundled together with the e-commerce platform
- Requires less developers (only one application needs to be maintained after all)
- Arguably less complex, since an integration between two applications isn’t needed
Full-stack CONS:
- Less control over UI/UX changes
- Harder to maintain as Separation of Concerns between UI and business rules isn’t clear
- Poor UI responsiveness (tip: this can be improved using Turbolinks)
Headless PROS:
- Ability to have multiple user interfaces for same application (a website, a native mobile app, etc)
- Clear SoC makes it easier to maintain and evolve by a dedicated front-end team
- Much better UI responsiveness
- Allows for a more unified and consistent omnichannel experience
Headless CONS:
- More difficult to handle SEO and real-time web scraping bots (Facebook, Whatsapp, etc)
- Usually requires more developers to maintain two separate applications
- Arguably more complex, since two separate applications are integrated via http
A common analogy is that of comparing the full-stack approach to the now extinct TV+VCR combos — while there’s an obvious value in having the two integrated into one product (for instance, there’s no need to worry about connecting two separate devices via cables), it was very unlikely that one of these combos would provide the best TV and the best VCR in one single product, since advances in TV and VCR tech happened at different paces, and not to mention that soon enough VCRs would be replaced by an entirely new technology. With the combo, one would certainly get an easy to use all-in-one product, but at the cost of not having the most cutting edge tech on each individual component. Headless may be more complicated to set up, but its parts can evolve at distinct paces and even be entirely replaced if necessary.
Omnichannel, but with Inconsistent Experiences
For any B2C company, it is only natural that over time it expands its channels to wherever possible so as to reach out to a greater number of potential customers. With the advent of smartphones, m-commerce as an additional channel was quickly born. Be it via native mobile apps or via a mobile web browser, companies had to adapt their e-commerce platforms to offer this additional choice for customers. Before response layouts were a thing and mobile bandwidth was up to par with desktop bandwidth, an initial attempt taken by many companies was simply deploying another platform, on a m subdomain (as in m.company.com), to serve mobile web pages, which were reduced versions of the original desktop versions. Needless to say, this created more problems than solutions; companies that already had a lot of work managing the desktop platform (uploading products, images and banners, configuring promotions and coupons, etc) now had to also manage an entirely different mobile platform, which resulted in a lot of redundant work.
This approach not only wasn’t sustainable due to the double work involved, but it also provided very distinct experiences among the two channels. Over time, responsive layout techniques came to the rescue, allowing for a single HTML document to be served to both mobile and desktop, and let the browsers adjust it to the screen size according to programmed rules (CSS). This led to the centralization of platforms and the extinction of the infamous m subdomain or m-site.
The main takeaway we get from this is that deploying new platforms for any additional channel inevitably leads to inconsistent user experiences, as well as unsustainable workload for the company.
With the recent expansion of many B2C businesses to offline (physical stores), the rise of native mobile apps (iOS and Android), and the rise of online marketplaces, this again created a similar channel overload conundrum, with the following new systems being required:
Physical Stores:
A physical store POS system, meeting all POS fiscal requirements and providing the same customer experience as the online channel, plus specific business rules for the in-store customer experience
Native Mobile Apps:
An e-commerce platform providing *all* existing features via API, because native mobile apps are headless by nature (the layout of native apps is not described in HTML, hence the need to communicate with servers via JSON API)
Online Marketplaces:
An e-commerce platform providing all existing features via API, so that a third-party marketplaces may use them for promotions, reading product prices and inventory, and pushing orders (in reality, due to a lack of e-commerce API standardization, it’s the opposite that prevailed, and marketplaces are the ones providing such APIs)
It’s not unusual for companies to have POS systems sitting on top of a completely different platform for its physical stores (it’s usually a user interface for the ERP system), and it’s also not unusual for the native mobile apps to sit on top of an API that provides only a *subset* of all features available on the website. This approach enables a multi-channel world, but it also creates the problem of experience inconsistency and redundant workload. But can we do better? Would it possible to unify this as mostly as possible (as happened to the m-site)? This is where Headless may come into play.
[ This is the first part of a 2 part series, you can find part 2 here]
