Abstract
This article discusses Headless architecture for eCommerce systems. Digging into the demand for this type of structure in the modern IT world, the negative points of a more traditional platform will be analysed from both the developer’s and the end-point client’s standpoint.
A headless structure separates the ‘head’ (front-end components) and the ‘body’ (back-end components), allowing for the production of tailor-made, fully customizable, API-driven systems that are open to an omnichannel approach. An architecture like this must be designed and directed by expert developers and project managers and has countless benefits, which the article illustrates.
Headless Architecture for eCommerce
Why should an experienced developer or a group of experienced developers take a step back from their skills to embrace new methods of development, both from the architectural and from a purely technical perspective?
Embracing a philosophy of “constant updating” leads to the realisation that there is always a specific reason modern technologies are designed in a particular way, and that developers should remain open to these new possibilities. The basis for this is simple: because the new technologies are better, more powerful and more flexible. New technologies present an upgrade on the weaknesses of older solutions.
That’s exactly the case when it comes to so-called “Headless Architecture for eCommerce” or, simply Headless eCommerce – a very powerful way to build fully-customizable, tailor-made eCommerce solutions for the end customer. As a full-stack developer who loves to develop and write code, Headless eCommerce allows greater freedom of expression and creativity, freeing the developer from many constraints and making it possible to offer the best possible solution, for both the front- and back-ends.
What is a Headless Architecture for eCommerce?
Having established that Headless eCommerce is an upgrade on the common e-commerce architecture, let’s consider the major problems of the latter approach.
Firstly, a ‘traditional’ eCommerce application is developed in a single monolithic layer. This means that various aspects of the application must be worked on to make any change, and to provide a full release for each update.
In addition, consumers are now accustomed to making purchases using different types of devices, not only via websites or web apps. In the Internet of Things (IoT) era, developers have to produce applications and user experiences that are adaptable to a huge range of different devices. Consumers are also getting used to the new, more powerful user experience provided by progressive web apps, created with different progressive web frameworks on the front-end.
So, what is Headless eCommerce?
This concept is an extension of a more abstract concept — Headless CMS (Content-Management-System). In a traditional CMS we find two interconnected primary technical areas: the back-end — that is, the CMS itself, which could be called the ‘body’ of the system — and the ‘head’ of the system, which includes all the front-end components, such as client-side frameworks and the template.
In this context, we can say that if you remove the ‘head’ from the system, you are left with a Headless CMS.
A Headless CMS is front-end agnostic, meaning that the platform does not have a default, tightly-coupled front-end layer. What is left is raw content – pure data-source. It is therefore possible to develop as many fully customised ‘heads’ as are required to serve content to different IoT channels. The data in the ‘body’ of the system is waiting to be manipulated by the fully customised front-end. One of the most common ways to have the data served to the different channels is through API calls. Headless eCommerce is simply a Headless CMS that performs the tasks of an eCommerce platform. Within a Headless architecture, the front-end layer has been decoupled from the back-end layer. The latter is the core of the eCommerce service and allows the users, catalogue, product search, shopping carts, promotions, orders, and all related elements to be managed. Back-end developers use APIs to deliver data, while front-end developers work on the presentation of content using their preferred stack (template, frameworks, client-side building), moulding the system to meet the specific needs of the customer. Moreover, they can deliver the right kind of data in the right shape for the right channel, be that a web-app or a specific device.
The advantages of a Headless architecture for eCommerce
While a Headless architecture is founded on loose coupling (a term dear to traditionalist OOP developers), in a traditional eCommerce system, a server-side layer is tightly coupled with the client-side system. It may be possible to customise various features of the platform, but these will always be within the range predefined by the system in use.
A traditional eCommerce system offers less room for customization in either the front or the back-end layers, while Headless imposes no limits. Of course, developers (at both ends) have to make things from scratch and exploit their creativity, but that’s exactly where the “freedom to write code” takes over. In Headless Architecture, there is no predefined experience.
As discussed previously, a typical Headless eCommerce architecture makes use of API calls via a RESTful system to deliver and provide content, so it becomes possible to move away from monolithic methods and implement a more modern, API-driven architecture, open to all kinds of IoT channels.
The advantages of Headless architecture can be summarised in four main points:
Point 1: More freedom and customizability for both developers and users
With no predefined front-end layer, front-end developers are able to be proactively creative in building the user experience they want to offer the final user, without the constraints encountered in a traditional eCommerce platform. Templates and databases (and other server-related issues) are no longer tightly coupled, meaning that constant adjustments to fit client preferences are no longer necessary. Experienced developers who like to write code and mould applications from scratch revel in the opportunity to immerse themselves in this fascinating scenario.
In this context, developers are able not only to be the executors of what has been decided at a strategic level, but can also be all-round advisors to their clients, from strategy to execution.
Calls to the various back-end RESTful APIs of the application (which in turn, may be fully customised in order to meet any need) build the link between the two universes, handling various requests between the presentation and the software layer.
Moreover, users of the application can be offered a truly personalised and unique user experience, in line with the specific needs of the customer.
Point 2: The perfect environment for the ‘omni-channel strategy’
We have already talked, from an IoT perspective, about the importance of multi-channel support. The omni-channel strategy (also called the omni-channel approach) allows us to refine the matter further.
The omnichannel strategy/approach is a sales strategy in which all channels of customer service and attainment work together to offer the highest level of comfort for shoppers using the retail network. The idea is simple yet powerful: the more integrated tools a customer has available for their shopping, the better their shopping experience.
Companies must follow a path that travels from the optimization of several contact points in a non-integrated way to an increasingly integrated management in order to fulfil the true nature of omni-channel strategy. The omni-channel approach is state of the art in terms of shopping interactivity, in which harmony between the different channels that offer access to services is of primary importance.
For example: a customer might look at a particular product/item in a physical shop, but it may not be in stock in the desired colour and size. The customer can then order the product either via a physical checkout or by using the totem channel (a device that allows buyers to browse catalogues and pay for an item that is subsequently delivered) and have the article delivered to their home.
With an omni-channel approach, users interact with the company through different on- and off-line touchpoints with the same, seamless experience, and without having to restart the process every time.
One of the core features of an omni-channel experience is providing the user with the same quality and customization on any platform, touchpoint, or device.
The structure and characteristics of the Headless architecture makes it possible to add new sales channels without having to create a new dedicated back-end for each addition. Centralising API and the database, and having infinite ‘heads’ (front-end points) allows a much higher level of integration. Greater harmony between the different channels is achieved in a much simpler, faster and more effective way than the traditional approach, using fewer resources.
Point 3: Dedicated solutions with no pain
A Headless architecture aims to configure the best eCommerce solutions to meet the needs of the client company. This involves adopting a holistic approach that is as tailor-made as possible in order to offer the best solution, both in terms of back-end management after release and of final usability.
This is where the power and flexibility of the Headless solution lies – in facilitating a dedicated solution tailored to the specific customer, that produces the desired user experience, uses the most suitable back-end technologies, in which changes can be made without having to rebuild the architecture.
Point 4: Shorter and improved time to market ratio
Headless architecture aims to exponentially improve the time to market ratio. In the commercial realm, the time-to-market concept (also known as TTM) is the period from the conception of a new idea or product until it is made available in the marketplace. A Headless approach makes it dramatically simpler to provide new front-end elements (campaigns, banners, updates) in a much faster timeframe, since the back-end components are separate. Reactions to new market trends can be rapidly implemented, launching new features in days or weeks instead of months, so improving the time to market ratio.
A Headless platform structure (Deloitte’s solution)
The architecture of a Headless eCommerce platform must be organised at multiple technical levels by a team of experienced project managers and developers.
In order to satisfy increasing market demand for eCommerce services decoupled from the user experience, a new technology stack has to be implemented. The main components, based on Deloitte’s solution, are:
- eCommerce service layer: core eCommerce services that allow the management of users, catalogue, product search, shopping carts, promotions, and orders.
- Front end layer: front end framework specific to the chosen content delivery channel
- API gateway: high-performance integration layer working through optimised connectors. ∙
- API caching layer: a caching layer that further improves the performance of intensive or underlying tasks for faster data retrieval and speeding up of the application
In creating this new technological architecture, the following issues must be taken into account:
- De-coupling of development teams: The teams working on the front and back end should be completely separate, with dedicated specialisations and different development and release processes.
- Management of communication between layers: Construction of an architecture that reduces the number of requests between back-end and front end to make the infrastructure scalable and performant
- Caching provision: several cache layers are needed to guarantee the fruition of the contents. It is therefore necessary to have a front end cache capable of managing basic data types, a back end cache capable of caching API calls, and an asset cache (typically implemented through a CDN).
- Ensure the appropriate level of security: the exchange of data between the different layers, saving data permanently or temporarily on one of the layers and their exchange with third party systems must be carried out in compliance with the security standards required by the type of data processed (e.g., user information, payment information).
In the front-end layer, there is a choice to be made between the different technologies that allow the building of progressive web-apps with the aim of making the user experience as pleasant as possible. It is possible to integrate tools such as Vue, React+Next, Angular, Svelte, and so on that have the ability to bind both to their development stack, in a typical Javascript-everywhere environment, or to a different back-end technology, such as Java / J2EE , PHP, or C #.
Conclusion
This article has provided an overview of the importance of adopting a Headless strategy for eCommerce platforms in order to improve on the flaws inherent in a more traditional eCommerce approach. This updated strategy aims to improve these old-school characteristics.
A Headless architecture brings the same flexibility required by marketing strategies to technical structures, allowing developers to choose the approach they prefer and consider most appropriate for the layer they are working on. This kind of architecture allows experienced developers a wide degree of freedom, and at the same time, allows for the creation of a personalised and tailor-made user experience based on the specific needs of the customer.
Headless architecture provides an environment suitable for the implementation of an omni-channel strategy, increasing the interactivity and fluidity of shopping actions. Changes, updates, and future interactions will be smoother than ever, and time to market will be drastically improved.
Finally, the semantic separation of the front- and back-ends means that architects are able to mould next-generation applications that deliver high performance, lightning-fast execution times and increased fluidity.
