Going headless with Magento

The Headless CMS architecture is steadily rising in popularity. This model allows completely custom user experiences while providing developers the great flexibility to innovate. It also helps website owners to future-proof their builds by allowing them to update the design without re-implementing the whole CMS. With all this upside, it’s no wonder this type of build has gained serious traction in Magento community off late.

It may be a tad hard to understand why this is needed or what it actually involves. Let’s get little deeper into figuring what and how. The headless Magento will run on original Magento application, but the application is not outputting anything to the browser.

Let’s take a product listing example. In the HTML page, you could create placeholders for the products so that every product looks similar. Then each product would be fetched one-by-one by JavaScript remotely and replace the placeholder. Applying the same principle to the checkout or customer pages would also require a push of data back to the Magento server.

Why go headless with Magento?

One of the benefits is that JavaScript is loosely coupled with Magento backend and which JavaScript framework to use would become a frontend developers choice, instead of KnockoutJS being now a solid requirement for developing in Magento.

Also, this would mean that there is no need for Magento developer’s to worry about designing on Magento. Instead, the focus can be on a REST API that simply offers everything that needs to be loaded. Magento provides a flexible framework that can be used to build custom logic on pricing, logins, checkout, etc. However, this contains a lot of additional stuff that is not needed. Building your own pricing rules might be easier than trying to extend and modify the Magento pricing rule system. It might require effort. But you will be dumping a lot of complex logic, in favor of code that simply works the way you want it to work.

Challenges of going headless on Magento

Cost of implementing headless approach with Magento

One of the biggest challenges of headless Magento applications is replacing the full presentation stack of Magento is not a trivial task. One of the strategies is to only replace key pages of a site such as home page, product navigation, and browsing, basically focusing on the navigation and discovery experience. In such strategies, other pages such as checkout or order history are left untouched. Another strategy is to replace the whole presentation tier. The cost of the two approaches is very different.

So a key decision is a value of replacing the Magento presentation tier. Each merchant needs to consider that trade-off. A part of the value of the Adobe and Acquia partnerships is that much of this integration effort is being solved up front, removing that overhead per site. But in general, headless strategies at present will be a higher cost than using the native Magento presentation tier

Using extensions with Magento

In Magento, extensions can plug themselves into the default Magento pages using the Magento layout engine. A key design goal of Magento is that you can purchase an extension and have it “just work”.

Extensions can be back-end oriented (e.g. a different tax calculation engine, a different promotions engine, etc). These extensions have minimal or no change in the consumer experience (presentation tier) and so are easy to add to a headless Magento installation.

The problem occurs for the extensions that enhance the presentation tier. Address verification, smarter merchandising, a search extension with auto-complete – extensions frequently inject additional JavaScript into a site to provide a better consumer experience. Injecting JavaScript into the Magento presentation tier does not help a headless deployment. If a headless Magento installation manually merges JavaScript from extensions into its code base, care must be taken to correctly apply future patches provided with that extension.

In Conclusion

By shifting responsibility for the user experience completely to the browser, the headless model provides a number of benefits such as:

1.  It allows the site owner to redesign the site without re-implementing the CMS
2. It gives frontend specialists full control over the user experience using their native tools.
3. Speeds up the site by shifting display logic to the client-side and streamlining the backend. An application focused on delivering content can be much more responsive than one that assembles completely formatted responses based on complex rules.
4. Builds true interactive experiences for users by using the website to powerfully function in-browser applications. The backend becomes the system of record and “state machine”, but back-and-forth interaction happens real-time in the browser.
5. Headless website development has the potential to unleash the creative power of frontend developers to deliver richer, faster, and more responsive user experiences.

Is “headless Magento” a major strategic direction for the future? That would be overstating it. But it is a valid use case that Magento will continue to support.