TL;DR Version (Too Long; Didn't Read)
A couple of months ago, this “buzzword” was introduced to me. Before researching more on the subject, I asked one of my brilliant colleagues what it was about. His response was “the thing we’re doing right now”. Ah. Right. So that must mean we’re doing some things right, no?
So what is it about?
In more detail, it’s about decoupling the user interface with the application logic, so that in theory, you can switch user interface entirely and have it working the same way. The user interface doesn’t necessarily mean the design. It can be a complete other way a user interacts with your application. For example if you have a headless commerce website, you could implement a mobile app using the same logic, because the logic is not strictly coupled with the frontend of the website. Or even more trendy, make parts of your application usable via Alexa, Google Assistant, Cortana, etc. Voice APIs are here to stay and work exceedingly well with integrations.
Making an app with the existing “site” logic? Why wouldn’t you want to run headless?
There are many positive effects of running headless and in my opinion they in most cases outweigh the negative effects. But if we are talking about the subject of what can go wrong, there are some mentionable points:
- It requires more from your development team. Headless architecture is something you need to consider in all features, making sure you are not just catering to one UI. This also means you might need more code in the backend to handle this, whereas in a site project you could rely on site specific addons or pre-built packages. To be successful, I think you’d need a skilled tech lead in a team that’s building a headless ecommerce site.
- Maintaining the same UX One thing that seems to float a round quite much in the headless topic is that the UX for the UIs will generally be worse than if you built one backend for each UI. And while that is sort of true, you can and should work around it. You should make sure the site has the same UX as if it wouldn’t be a headless and the same with all the other UIs. You have all the tools to do it, it just might require a bit more thinking to make it happen.
- More often than not, you cannot use built in functionality if the functionality includes an UI implementation. What I’m talking about here is features that comes shipped from your headless system that relies on a specific UI. Maybe it relies on javascript to be run, maybe it relies on being able to render a .cshtml-file, etc.
The biggest benefit of running headless according to me...
… is that you are completely free choosing any tools/frameworks/technologies implementing your UIs. I love experimenting with new technologies and evaluate if they would make the UX (counting in performance and all that) better for the end user. In the end, better UX allows you to have higher prices than the competitors, while still having the customers!
Epi Cms + Commerce
So you might want to look into going headless. One of the big selling points is that you can use any CMS together with any Commerce system together with any UI. Why then use both Epi CMS and Commerce? Why not use Storm Commerce that’s built headless? I’m stealing a Powerpoint slide from mentioned brilliant colleague, Anders Ekdahl, to explain why we at Avensia think it’s a great idea.
So imagine that you have Storm Commerce as the Commerce Platform and Epi CMS as the Publishing Platform, because you wanted to try headless commerce. Storm Commerce will say “we integrate with anything, look at this API that gives you that possibility”. Epi CMS will say “we integrate with anything, look at this API that gives you that possibility”. Great. Perfect headless solution, right?
The problem comes when we developers take a look at this. Wait, we need to build a complete integration between these two systems? Of course Storm/Epi will never build the integration themselves because they can’t implement 40 connectors to 40 different systems and keep them up to date. So first you need to build a major stable connection between the systems and then build an UI on top of that.
This is where Epi CMS + Commerce shines. They’re already deeply integrated with themselves and you can make this solution (of course together with some other Epi products) headless:
So using all the benefits that comes from headless architecture, we’ve now gotten rid of a huge integration between two complex systems and can now build our headless implementation of our CMS and ecommerce system. Three words for making the headless layer implementation: make everything JSON!
So what have we done with it?
At Avensia, we run a lot of labs testing different frontend technologies together with Epi CMS & Ecommerce (among others). Some of these labs yield a “cool, but not really a use case for it right now”-result, others yield a “let’s use this instantly”-result. One of the “let’s use this instantly”-results lead us to build a Headless layer, named SCOPE, that powers many of our customer projects, including our first implementation of SCOPE, Lyko.se, that resulted in a site awarded Best Nordic website & Commerce.
Challenges creating SCOPE
Making Epi CMS+Commerce didn’t come without challenges and hardships. Developers much more talented than I have spent many hours solving some of the hardships. Since Epi comes with many out of the box solutions that are connected to the web UI, you have to make sure it works with your headless implementation. Things like On Page Editing, routing, promotions, etc must work like out of the box in order to deliver a great system to the content creators.
What’s coming?
Our headless layer implementation have been relying on the existing usual APIs, the same ones you’d use for a standard implementation of Epi CMS+Commerce. However, Epi is working on a new package/API specifically tailored for going headless that will be revealed Q1 2018. From what I’ve heard, the first version will have its focus on utilizing the Content system, making it easier to push any type of content to any platform. Not much details have been released, but I look forward to evaluating it in a lab session!
TL;DR
People saying their systems are headless doesn’t necessarily mean it’s easy to integrate and implement. Epi comes out of the box with an integrated CMS+Commerce platform that you can morph into a headless system.
