- In the background, there is a platform/CMS or other database-driven application, which is often commanded via admin panel (to create content, add products). All the other similar systems, like ERP, POS etc are integrated there as well
- The communication of frontend and backend is handled via API. API gives frontend an easy-to-use access endpoints to all the necessary data, which is stored in the CMS (see point 1). Usually this API is RESTful and uses straightforward data format, such as JSON.
- User interface. This is a front-end application which renders the I/O of the interface (point 2) as HTML in browsers. Usually this would be based on a modern Javascript application framework, such as Angular, Ember or Knockout. This presentation layer technology and solution naturally depends on whether is it a mobile app or a web application.
The need for a headless solution rises from high scalability requirements, modular software decoupling (enabling extendability, reusability of services, maintainability, dependency management) and using of microservices as an approach to enterprise architecture. However, microservices are a subject for another article.
Getting the most out of the API layer
The API, from which the front-end application is requesting data, does not need to be just a “dummy” layer delivering the data from backend system. Depending on the special needs, one could organize and use data in various ways. For example, data can be fetched also from other systems, and for that data some logic can be added or it can be just proxy’d. The API layer would be a good location to create caching layer, as well as data formatting, automatizations and such. The goal is to leave the smallest possible amount of the logic to the presentation layer. The API can obviously deliver data to some other frontend apps, like mobile app and self-service POS, in addition to ecommerce.
The Magento 2 momentum of headless approach
Magento as an out-of-the-box version is a full stack application, which means that it contains the backend as well as frontend implementation and functionality as a whole. The new version of this most scalable ecom platform, Magento 2, has a very feature-rich API, through which it is possible to fetch almost all the data resources which are held in the Magento backend. This creates a good starting point for a headless implementation. Also the Magento 2 service contracts are a good architectural design principle, which are supporting the headless model. However, there are certain things to note regarding the Magento headless solution. Some of those being: data formatting, for example prices. How to handle product images. How to divide the responsibilities of API gateway and Magento API. Is the gateway even needed. One of the main challenges of headless Magento applications is the fact that rewriting the full presentation layer of Magento is not a trivial task. Fortunately, this is not an all-or-nothing-situation. One could for example only replace key pages of an ecom app such as home page, category and product pages plus navigation. This strategy makes the development effort smaller. However, it should be thought out case by case which parts need to be rewritten. Another strategy would be rewriting the whole presentation layer. The difference in cost between these two is obviously significant.
The key decision is the value of replacing the Magento presentation layer. This trade-off has to be investigated very carefully.
Pros and cons of going headless
Due to changing the responsibility of the UI/UX totally to the client-side (browser, app…), the headless model gives us some remarkable benefits:
- Performance boost. Browsers are mostly pretty powerful and devices (not mentioning desktop computers) have a lot of processing power. Offloading this from the server will impact to the site performance significantly. Also, backend and frontend can be scaled not depending on each other.
- More efficient development. The technologies used in frontend usually differ from those that are needed to develop backend side. Very often also different people do one of either sides. The decoupling of frontend supports this fact by making development easier.
- State-of-the-art user experience. Front-end can be built using modern technologies and it can even be a single page web application. The interaction happens in real time and even without page loads in the browser. This gives designers freedom to create new kinds of user flows and UI logic. Also this supports greatly the PWA movement (again, a topic for a new post).
- Reusable software logic/API. By creating a RESTful API and possibly adding some extra flavor (caches, logic, endpoints to access other systems) it is very easy to reuse this part of the system for other frontends (also non-HTML) like mobile apps etc.
However, this all comes with a price. Namely, there are a few downsides that need to be addressed as well:
- Huge development effort compared to traditional way of doing things. Varies case by case, but usually the amount of work building ecommerce from the ground up using for example monolithic Magento vs. headless Magento, is a lot bigger in the latter case. Front-end needs to be built almost from scratch and a lot of standard features need to be recoded. A traditional ecom system would have these out-of-the-box.
- Losing the benefit of the platform. Usually the platforms, such as Magento, get better version by version. The security becomes hardened, new features are presented and so on. Using the headless model, all the frontend benefits of the platform are lost. This means that all the security fixes, new features etc. must be built as custom development, which can be very time and money consuming.
- Application size and complexity. Building the frontend application will require notable experience. The frontend application will be very complex, and things like proper fragmentation strategy, structuring and loading only the required JS must be planned and implemented carefully. The changes and new features will need development in many different applications.
- Most of the extension modules won’t work. The modules, which are one very big benefit of using popular platforms, won’t work if the developers haven’t specifically created support for this (which is the case regarding Magento 2). In most cases, they haven’t.
- Performance in some cases. Performance has to be listed as a con also, because the final outcome depends a lot on the whole setup. Headless approach (and usually microservices, which are used frequently together) tend to spawn a bunch of requests generated by the original request from client. Especially when designed badly in software architectural point of view, the overall load is much higher. Also the path from client request to rendered HTML output in browser is much more complicated compared to traditional way of ecommerce solution, and has many possible bottlenecks.
Final thoughts
As said, the headless approach offers some good benefits, but includes on the other hand some major drawbacks regarding implementation. As always, the added value for headless architecture must be carefully considered case by case. Many of the good outcomes of headless model can be reached just by doing a traditional application correctly. The headless architecture can make things a lot harder when applied recklessly, or alternatively allow the developers to create and extend large-scale systems efficiently. The worst option is to implement a new architecture just because of the coolness-factor.