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?
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.
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.
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.)
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.
I enjoyed your article. In response to extensions question, I see two feasible scenarios (there are probably more):
1) Would it not be possible to have extension developers add methods to the API that serve up the required injections to the front end (e.g., a JSON object that provides the appropriate endpoints, even the script tag) for the front end designer to work with? In addition, they could provide snippets or SDKs for various front-end languages (e.g., Angular 2 components or jQuery libraries)?
Of course, this requires more work on the part of the developer to adapt the code/SDKs.
2) Extend the Magento APIs to include ‘through points’ for the extension. In effect, the extension would simply extend the API endpoints/methods available for the front-end designer to tap into. If data is being served up by a 3rd party, it would work in a fashion similar to payment tokenization where the data traffics through Magento, but, is coming from an external source.
Interesting post, which presents some interesting challenges for QA of Marketplace extensions. Should we require a minimum level of decapitability from curated extensions? Or at least require that the level of support the extension provides be documented in their marketing material? Questions to ponder, I think.
I’m also delighted by the edited Ultima VII graphic. Not sure if it’s art by Jeff Dee or Denis Loubet, but like the Ultimas themselves, both are beloved Austin institutions, and it’s lovely to see such a hat-tip to them 🙂
Hey Alen , Do you think Ionic 2 is ready for Magento 2 app?
Interesting concept – a few of my clients are ‘kind of’ using Magento in this fashion but the phrase ‘headless Magento’ sums it up really nicely.