With the improved REST APIs in Magento, more “headless Magento” projects are emerging. This is where some other software provides the “glass” (presentation code) and Magento provides all the underlying ecommerce functionality (cart, taxes, shipping, order management, etc). But should extension developers do anything different in Magento 2 to work in such scenarios?

Headless Magento

Recently Magento has announced strategic partnerships with Adobe (9/26) and Acquia (11/2) where they take the primary responsibility of presentation. Similarly, there have been experiments with technologies like Angular and single page apps where more logic is performed outside the Magento core code base. These are generally referred to as “headless Magento” because the presentation tier (the “head”) of Magento is not used (at least not as much). Instead, Magento REST APIs are used for the presentation tier to communicate with Magento.

REST APIs

One of the significant areas of investment in Magento 2 was improvement of API infrastructure. “Service Contracts” were introduced both to provide well defined APIs for modules to communicate with each other (reducing patch and upgrade pain) and to make it easier to bind web APIs directly onto core functionality. The latter goal was to enable easier integrations with external systems, and to enable the “headless Magento” use case.

There have been some issues with the new APIs that have been worked on, there are still missing APIs (modules where a service contract has not yet been defined), it is always good to improve the performance of APIs, but overall the feedback I have been receiving on the Magento 2 API work is positive – the direction has been a worthwhile investment for Magento.

Is Headless Cost Effective?

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

So a key decision is the 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.

Extensions in a Headless World

But what about extensions? In Magento, extensions can plug themselves into the default Magento pages using the Magento layout engine. A key design goal of Magento is 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 is for 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.

Recommendation to Extension Developers

Extension developers need to think whether their extensions are suitable for supporting headless Magento deployments. Some extensions may simply not be suitable for that purpose.

Some extensions sit behind the scenes of Magento. If an extension only adjusts the Admin panel, then that extension may “just work” in headless scenarios. (Headless scenarios generally only make sense with the consumer experience – the cost of reworking the Admin panel would probably never be worth the investment.)

If an extension does affect the consumer experience but the extension developer wants to make the extension useful in headless environments, consider supporting a set of REST APIs in your extension. To maximize benefit, design the APIs to be friendly for both access from both JavaScript and from other applications. The benefit of the extension “just working” won’t be realized because it cannot plug itself automatically into the presentation tier, but providing a well-defined (and stable!) API will greatly reduce the effort for headless applications making use of that extension functionality. Remembering that headless applications will typically require more effort anyway, this is not such a burden.

Conclusions

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

The simple recommendation this blog makes for extension developers is to consider, where appropriate, providing REST APIs to functionality of your extensions. This will make the extension potentially valuable in headless scenarios, unlike extensions that only hook into the Magento layout engine.