Headless architecture has been the one of the most discussed ways of implementing web applications during the past 6 months. In this blog post we explain the concept that the headless architecture is based on.
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.
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.
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:
However, this all comes with a price. Namely, there are a few downsides that need to be addressed as well:
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.