Website Development, Digital Marketing and Odoo ERP Development
The headless architecture, also known as decoupled architecture, is based on the following concept.
- A platform/CMS or other database-driven application is running in the background and is frequently controlled through an admin panel (to create content and add products). All other similar systems, such as ERP and POS, are also integrated.
- API is used to communicate between the front end and the backend. API provides frontends with simple access endpoints to all necessary data stored in the CMS (see point 1). This API is typically RESTful and uses simple data formats such as JSON.
- The user interface. This is a front-end application that renders the interface’s I/O (point 2) as HTML in browsers. This is typically built on a modern Javascript application framework, such as Angular, Ember, or Knockout. This presentation layer technology and solution are naturally dependent on whether the application is a mobile app or a web app.
High scalability requirements, modular software decoupling (enabling extendability, reusability of services, maintainability, dependency management), and the use of microservices as an approach to enterprise architecture all contribute to the need for a headless solution. Microservices, on the other hand, are a topic for another article.
Making the most of the API layer
The API from which the front-end application requests data does not have to be a “dummy” layer that simply delivers data from the backend system. Depending on the specific needs, data could be organized and used in a variety of ways. For example, data can be fetched from other systems, and logic can be added to that data or it can simply be proxy’d. The API layer would be a good place to create a caching layer, as well as data formatting, automation, and other features. The goal is to leave as little logic as possible in the presentation layer. In addition to eCommerce, the API can obviously deliver data to other frontend apps such as mobile apps and self-service POS.
The Pros and cons of going headless
Because the headless model shifts the responsibility for the UI/UX entirely to the client-side (browser, app…), we gain some significant advantages:
- Improved performance. Browsers are generally quite powerful, and devices (including desktop computers) have a lot of processing power. Offloading this from the server will have a significant impact on site performance. Furthermore, the backend and frontend can be scaled independently of one another.
- Improved development efficiency. Frontend technologies are typically distinct from those required for backend development. Different people frequently do one of the two sides. The decoupling of the front contributes to this by making development easier.
- A cutting-edge user experience. Front-end development can be done with modern technologies, and it can even be a single-page web application. The interaction takes place in real-time, even if the browser does not load any pages. This allows designers to experiment with new user flows and UI logic. This also lends significant support to the PWA movement (again, a topic for a new post).
- Software logic/API that is reusable. It is very simple to reuse this part of the system for other frontends (also non-HTML) such as mobile apps by creating a RESTful API and possibly adding some extra flavor (caches, logic, endpoints to access other systems).
All of this, however, comes at a cost. There are a few drawbacks that must be addressed as well:
- Significant development effort in comparison to the traditional way of doing things. Depending on the circumstances, the amount of work required to build eCommerce from the ground up using, for example, monolithic Magento vs. headless Magento is typically much greater in the latter case. The front end must be built almost entirely from scratch, and many standard features must be recorded. A traditional eCommerce system would include these features out of the box.
- The platform’s benefit is being lost. Platforms, such as Magento, typically improve with each release. Security is strengthened, new features are introduced, and so on. All of the platform’s frontend benefits are lost when using the headless model. This means that all security fixes, new features, and so on must be built as custom development, which can take a long time and cost a lot of money.
- Size and complexity of the application Building the frontend application will necessitate significant experience. The frontend application will be extremely complex, and details such as proper fragmentation strategy, structuring, and loading of only the necessary JS must be carefully planned and implemented. Changes and new features will necessitate development in a wide range of applications.
The majority of the extension modules will not function. The modules, which are a significant advantage of using popular platforms, will not function unless the developers have specifically created support for this (which is the case regarding Magento 2). Most of the time, they haven’t. - In some cases, performance. Performance must be listed as a disadvantage as well because the final result is heavily dependent on the overall setup. The headless approach (and usually microservices, which are frequently used together) tends to spawn a slew of requests generated by the original client request. The overall load is much higher, especially when the software architecture is poorly designed. In addition, the path from the client request to rendered HTML output in the browser is much more complicated than in traditional eCommerce solutions, with many potential bottlenecks.
Final thoughts
As previously stated, the headless approach has some advantages, but it also has some significant disadvantages in terms of implementation. As is always the case, the added value of headless architecture must be carefully considered on a case-by-case basis. Many of the positive outcomes of the headless model can be obtained simply by performing a traditional application correctly. When used carelessly, headless architecture can make things much more difficult, or it can allow developers to efficiently create and extend large-scale systems. The worst option is to implement a new architecture solely for the sake of novelty.
English
Chinese (Simplified)
Dutch
French
German
Italian
Portuguese
Russian
Spanish