The main idea behind this concept: Separate the presentation layer which customers interact with from the backend layer with all the business logic and infrastructure and connect the two via a flexible API. The benefits: Businesses who want to deliver inspiring experiences to their audience are not tied to what their (legacy) commerce platform allows them to do. They do not have to stick to the rules of a user-interface logic which are designed to produce a standardized web experience, consisting of plain old HTML and CSS in the background. Instead, they are entirely flexible regarding content delivery, UX, and even SEO.
Having an API at one’s disposal allows for an unlimited number of different frontend technologies: the presentation layer can be a voice skill, a chatbot interface, a social media site, an IoT device and even a car which is connected to the internet. An API is blind to the source that sends information to and requests information from it. In other words: Whatever new user interfaces and devices there will be in the future, businesses can be sure that their platform can still deliver content to touchpoints of all shapes and forms. And: They don’t have to run an isolated system for each new touchpoint, creating an ugly collection of information silos.
Server-Side Browser Code: Not Everybody Needs a Voice Skill (Yet)
The future looks very bright and diverse for those who want to dive deep into all those new wonderful touchpoints. However, not everybody needs a voice device hooked up to their service – at least not right now. Most businesses will rely on more “classic” interaction methods. And this is the mobile web browser.
Many have argued that a mobile browser is just a smaller version of its desktop counterpart, which is the reason why responsive websites have been so successful in the past couple of years. The idea behind this design paradigm: structure a website in a way that it dynamically responds to the form factor and the context which it is used in. If people access a web page via a Desktop browser, show it in maximum resolution; if your customers choose to access it via a smartphone or a tablet, resize and rearrange the elements accordingly. This does make a lot of sense when the input device is your index finger instead of an arrow steered by a mouse or a touchpad.
The downside of this approach: the HTML/CSS code necessary to render those kinds of websites is built on the application server. In eCommerce, it turns product information and interface elements such as forms and buttons into chunks of HTML/CSS code which is transferred to the browser and rendered into a page. The client itself – the mobile browser – does not have much influence on the way in which the information is presented.
Looking at the Client Side: Native Apps
The next evolutionary step that brands and merchants took was to resort to native apps. Those apps take full advantage of the hardware’s capabilities, such as geolocation, camera, or push notifications. Running natively on the device, they are mostly faster than mobile websites conveying the same information. And they can keep their data in local storage, meaning they can be used even if the device itself is offline. There are a lot of those apps in the Apple and the Google Play app stores that in most complement the offering a retailer already has with a “simple” mobile website.
In contrast to the server-generated frontends mentioned above, those apps are clients in their own right, containing design and interaction rules and functionality. Of course, those apps still need a counterpart to receive their information. But instead of transferring pre-built chunks of website code, all there is to be exchanged is raw, text-based information. Once more, this is where headless commerce platforms can shine: For those solutions, a native app is just another client requesting data. Every time such an installed app needs fresh information, it opens up a channel and requests it from the API – the commerce solution in the background takes care of the rest.
The advantage: because of the reduced amount of information that has to be exchanged and the app’s access to the device’s hardware, the experience is usually much faster and more fluid. The downside: users have to actively install the app before being able to interact with the brand – a hurdle which needs to be overcome.
Progressive Web Apps: Best of Both Worlds
Recently, frontend development has focussed on the so-called PWAs (progressive web apps), sometimes also referred to as single-page apps. In a nutshell, these are user interfaces which combine the advantages of regular, server-side websites and client-side apps. They contain JavaScript elements which take care of the dynamic aspects of the user interaction.
A PWA is loaded by merely opening a website in a mobile browser – like you would access any other site. However, in contrast to those regular ones, the PWAs download a chunk of JavaScript code which make them behave like native apps:
Add to homescreen: Users can add a shortcut to the PWA to their device’s home screen. This will generate an app icon through which they can access it like any other (native) app.
Push notifications: This feature has been restricted to native apps for a long time. In PWAs it is now also possible to use push notifications to communicate with users.
Offline functionality: PWAs have caching mechanism built-in, allowing them to preload chunks of raw information from a source such as headless commerce platform. Should the device lose the internet connection, the PWA is still useable.
Lately, an advanced ecosystem has evolved around those PWAs, so frontend developers and UX engineers can start straight away, without having to start from scratch. Frameworks like ReactJS, AngularJS, and Vue.js are gaining more traction in the market every day. They are mostly OpenSource libraries maintained by companies like Google and Facebook. Some of those technologies have already made it into the mainstream, driving international websites such as a lot of Google and Youtube services, Electronic Arts, and Coca-Cola.
And the best thing: Should businesses require native apps, after all, those can be built by using the same technologies that work behind the scenes of PWAs – using new frameworks such as React Native. In other words, the know-how gained by building PWAs is entirely reusable in the world of iOS and Android apps.
Separate Application Layers to Increase Customer Value
Businesses aiming at providing the best digital experiences to attract and retain customers should not have the presentation layer dictated by the technology platform they are using. What worked at the beginning of commerce – with integrated, full stack monolithic suites being the result – is now a stumbling block that keeps brands and merchants from reaching their full potential.
Especially innovators and visionaries need to be able to customize their user interfaces exactly the way they want to create brand recognition. They need to experiment with new frontends and interactions without hurting their backend processes. Put simply: They need to rely on a stable headless commerce platform with a flexible API like commercetools which powers those applications and keeps the business future-ready.
Want to know more about this subject? Head over to this blog post on headless commerce to find out more about this concept.