What is headless, and what do you need to know about it?

Michał Kuśmierz-small-image
Michał KuśmierzHead of Frontend, Monogo
Topics covered
Share this post

Who is headless for?

Let's start by explaining what a monolith is. A monolith consists of a single place where we manage data, have all the business logic, have an administrative interface, as well as a web-based client interface. There is one big advantage here - we have everything in one place.

In more complex systems, its disadvantages become apparent.

The first is a common requirement of modern online stores, for example, multi-channel or omnichannel capabilities. In other words, support for multiple sales channels outside the online store. For example a dedicated application, thanks to which customers can shop on mobile devices; a link to Instagram, so that products with a link can be posted directly on influencers' photos, or connections to marketplaces such as Empik, Allegro and many others.

Another key disadvantage of monoliths is the limited ability for customers to customize the graphical user interface. These monoliths and plugins typically come with default themes and template pages that are difficult to customize to fit a unique, branded visual experience.

The current Headless trend, which I'm trying to explain here, in simple terms, divides these monoliths into independent subsystems: content management is split into its own Headless CMS (builder.io or prismic), business logic into an API, and the client's GUI gets an independent life, on which there are no restrictions on the ability to visually design and implement visual changes.

Advantages of Headless

  • PWA - you can read about it in my other article: When a PWA and when an Application in e-commerce
  • Faster introduction of new functionalities - in monolithic architecture, backend and frontend works are dependent on each other; in headless architecture, each team can work independently. API provides flexibility to the service. Errors in the backend system may not have the impact of stopping the development of some parts on the frontend. Let's imagine that we need to update one of the microservices in our online store. Since each microservice exists separately, possible incompatibilities will not stop the store's operation. This means that you can implement a solution faster, which will help you outperform your competitors, who may encounter the same problem in a monolithic architecture, and will stop the operation of the entire store.
  • UX updates - Headless apps are likely to have higher conversion rates because headless apps run faster and the implementation of UX changes is done without the backend, cutting the process of implementing changes in half. Faster loading of apps also affects rankings in Google page speed, which in turn has a positive impact on SEO.
  • Personalization - Headless provides maximum customization in all areas, allowing the freedom to create personalized data for users.
  • Integration of non-web channels - by targeting the use of APIs, we can afford seamless integrations across all sales channels. Future changes and updates to the platform are also easy. If, for example, TikTok or another platform releases a shopping function, you will be able to quickly enter a new channel through integration. All you have to do is connect it through the API interface, and you can start selling.
  • Ability to experiment - with modern architecture, your Application is open to experimentation. Marketing can quickly implement CMS changes without affecting the application logic and without the involvement of the development team. Frontend changes can be implemented when customers make purchases. There is no need to stop the operation of the store when only frontend changes are implemented.
  • Saving time and money on IT support - the most common changes that are implemented in stores are marketing things (related?). Currently, thanks to Headless CMS architecture (e.g. builder.io), the marketing team can implement changes very quickly without IT team support.
  • Less risk for changes in the eCommerce platform market - if one day we want to change the eCommerce platform, for example, from Shopware to Magento 2 without changing the design of the application, all we need to do is adjust the API that the platform provides us with, without having to build the application from scratch.

Disadvantages of Headless

  • Headless technology does not cover 100% of the options available in either monolithic Magento 2 or Shopware - to cover 100% of the functionality available in these huge eCommerce platforms, there must be 100% coverage of the database data in the API. However, this is not the case. Software vendors do not provide complete coverage, and when we want certain business logic functionalities, we will have to add the appropriate methods or wait for the vendor to cover them themselves.
  • Additional costs - everything we build in Headless technology we have to pay for separately because we build everything individually. This means that in Headless technology we have to pay separately for the CMS, which in monolith we have in one place.
  • Logistically it is a huge undertaking - we build everything from scratch, implement custom APIs, test the backend separately, and test the frontend and integrations separately. This requires a great deal of work, which has to be done by qualified specialists.
  • Diverse large team - in the case of many companies, frontend, backend and QA, PMs (all of them are one team? or just the PMs are one team?) form one team. A small team cannot handle Headless technology. Building an API-based platform from scratch requires the use of many more technologies than traditional architecture. Team members specializing in each technology will be needed for both development and ongoing maintenance. With a large team, we usually have to delegate a huge number of tasks.

You've come to this article because you are most likely facing the choice of technology for your online store and are looking for answers as to whether Headless is worth considering. I can answer this question in this way: it depends.

If your deadline is tight, your requirements for the design are not necessarily complicated, you don't anticipate making modifications to your store's appearance very often, and you have few integrations with other systems, then it would probably be unwise to choose Headless technology. In this case, I recommend you choose a standard Magento 2 or Shopware solution. Just be sure to use a stable server solution, preferably "tailor-made". An excellent choice would be Monogo Cloud.

If you represent a larger company, have more complex requirements, want to support several sales channels, want to frequently modify visualizations on your application, and need a flexible and future-proof system to support PWA then Headless will be the ideal choice for you. The cost of implementing Headless is higher, but later development is cheaper.

Most of the big monoliths, the aforementioned Magento and Shopware, offer their Headless versions. At Monogo, we have our own solution, which we have been developing since 2018, so it is a mature and proven technology.

For details, feel free to contact me at [email protected]