At the end of the Imagine conference this year, instead of the traditional bar camp, Sherrie Rohde tried something new – DevExchange. Rather than presentations, groups of developers shared there experiences and thoughts on a current hot topic. There were two sessions of around 10 tables, intermixed with drinks and a ping pong table. The first topic I sat in on (well, stood up for really – there were almost as many people standing as sitting) was on Headless Magento.
I previously wrote a blog post on headless Magento, so I was curious to see where the conversation was going to go. I was half expecting an Angular 2 vs React JS discussion to break out.
Instead what immediately struck me from the table was the breadth of different use cases different people wanted to support. Sure, there were Content Management System integrations where the experience was managed by the CMS, and some did want to play with Angular or other frontend stacks, but just as common were others looking at Internet of Things use cases, Alexa integrations, chat bots, and more. Rather than focusing on the client talking to Magento, the discussion quickly converged on Magento APIs.
There was general agreement that the M2 APIs were much better in coverage than M1, but they could still be improved. Many were interested in a more modular version of Magento where you could use individual parts of Magento independently.
For example, a fair bit of the discussion was around the cart to order flow. To create a new order, for example, a cart id needs to be supplied. That is, you have to use the Magento APIs to create and populate a cart first, then use the cart id to create an order. In headless use cases, another system might implement the cart functionality, so it is more efficient for developers to go directly to order creation and supply all the details directly. (For illustration, think of a fridge with a button to order a new water filter cartridge. The fridge knows what to order, it just wants to get it done without messing around with a cart to collect things first.) People were happy to have large data structures passed in and out to achieve this (the full order contents in this case, to avoid having to create a cart first).
And this seemed to be the crux of the issue for most people. The current APIs are geared around a typical web store flow. Many of the APIs are fine, but some assume you have completed a previous step in a web store experience. People wanted to start the flow from wherever they wanted. Rather than pass in a quote id to create an order, they prefer to pass in the desired final order contents; rather than pass in a customer id, they want to pass in the billing and shipping address to use; rather than pass in a cart id to the tax or promotion discount calculation rule engine, they rather pass in the cart contents.
The end of this discussion was agreement from many participants to set up a GitHub repo for capturing further use case discussions (see github.com/ishakhsuvarov/going-headless), then move on to API definitions to better capture what different people want to achieve with the APIs.
All up this was an interesting discussion. I am sure I missed some details – others who attended are welcome to add their perspective or make any corrections to this thread!
