In no context outside technology, losing your head has been a step in the right direction. Cue the beautifully disturbing Basement Jaxx video for Where’s Your Head At. For ecommerce architectures, however, it allows the front and backend to thrive without stepping on each other’s toes.

Headless solutions have been around for 8+ years now. And, they are a natural progression from monoliths especially where change is constant, omnichannel is the norm, and personalization is a universal expectation. But not all headless architectures are created equal. Those that can establish strong adaptive lines of communication between the two ends unlock the greatest value growth for businesses.

What does it mean to go Headless?

A headless commerce architecture decouples the customer-facing storefronts (head) from the operational backend engine (body) linking them through APIs. With such a shift, the frontend team no longer depends on the backend to add new channels or introduce new features. Backend developers are also free to update any functionality without interfering with the frontend flow.

For the 2 counterparts, it becomes an occasional collaboration rather than a mandatory conjoined relationship.

Endless touchpoints and facelifts.

Commerce channels are popping up everywhere and getting more immersive than ever. Our recent survey found that 73% of shoppers use at least 2 different digital channels. Brands increasingly sell on social platforms, marketplaces and IoT devices in addition to their websites and mobile apps. From virtual grocery walls to AR fitting rooms, ‘phygital’ experiences continue to expand presence in the physical world. Metaverse is making luxury collectibles and buying virtual real estate from Snoop Dogg mainstream.

Going headless provides the flexibility to quickly plug in any new ‘head’ and independently customize it based on user expectations. Whether it’s a new geography or alternate universe, it makes being where the customer is much easier.

Innovation right here right now.

The pressure is on across engineering teams to build & deploy faster, better, safer updates all the time. Amazon’s been reported to deploy new code every second and Netflix thousands of times per day. Google Cloud’s 2021 survey found “elite performers deploy 973x more frequently than low performers, have a 6570x faster lead time to deploy, a 3x lower change failure rate, and an impressive 6570x faster time-to-recover from incidents when failure does happen”.

A headless architecture is a major enabler for agility and scale. Delivery gets accelerated with parallel teams and isolating performance. It also facilitates the creation and onboarding of more value-added products. From seamless 3rd party integrations to exposing own features through various monetization options, an API-led design paves the way for richer experiences.

Separation of concern but not of common goals.

As a guiding design principle, separation of concern allows the front and backend teams to focus on what they each do best. Since neither of them operates in a vacuum, they have to work together for the overall success of the business. That’s where the ‘occasional collaboration’ comes into play, and APIs have a critical role as their main line of communication. The more value passed on to the consumer, the better and more productive the collaboration.

But, harmony in this space doesn’t always come naturally.

Oftentimes, what different frontends need and what the backend developers can or want to build are two very different things.

Frontend developers prefer payloads tailored to their specific touchpoint so that user expectations are met without jeopardizing speed. Backend developers want to create standard, interoperable outputs to minimize development time and maximize reuse across the board. Understandably, both parties are concerned with optimizing performance at their ends while reducing the work and maintenance load.

The dilemma is, if you push every customization to the front end, then, the decoupling starts to lose its added value. You end up with operational silos and redundancies rather than central consistent control. If you handle most of it at the backend with rigid structures, it may be costly and risky to maintain such a complex build.

We believe the optimal solution requires a joint vision to maximize total business value and the right technical capabilities to support it.

Beware of the backend platform monolith.

In transitioning to headless, if the backend is kept as is or given limited flexibility, an effectively omnichannel operation will be hard to achieve. In most cases, design conflicts around customization are, then, addressed in one of 2 suboptimal ways:

1. All frontends bow down and adapt to the fixed backend.

This means every touchpoint handles customizations independently upon receiving more or less the same inputs. Core backend flows and their exposed APIs are mostly fixed with room for only minor adjustments such as adding a couple more fields. It ensures a robust structure for reuse and rapid deployment but is inefficient in many ways.

You may be suffering from this if you implement the same process flow multiple times for different channels, or publish a new app version every time you change a small part of your business logic. Common drawbacks are:

• More calls and post-processing. Not receiving inputs in the desired format may lead to multiple API calls for the same task and a lot of reformatting afterwards reducing agility and site performance.
• Replicate and repeat. Whenever you change an API configuration, you need to update it on every channel creating a lot of otherwise superfluous workload.
• Risky exposure. Making sensitive customer data available at the frontend to allow certain executions may lead to privacy and security vulnerabilities.

2. Workarounds are added as an extra layer.

An alternative middle ground is introducing workarounds such as the Backend for Frontend pattern (BFF) where the global APIs are customized to fit different frontend needs at a separate layer. This allows more flexibility without the added repetition at every touchpoint. But, like any workaround, it is not the best solution for the problem. Typical issues are:

• More APIs. The added layer comes with its own set to connect the two ends which also needs to be maintained on a regular basis.
• Higher complexity. Multiple layers increase the operational complexity and reliance on more experienced resources.
• Continued double effort. Duplicating code across services is still an expected scenario in this model since the backend remains as it is.

GraphQL to the rescue?

Created and released into the wild by Facebook, GraphQL is a query language that allows APIs to answer precise data requests from multiple sources and in different formats in a single call. It allows frontend users to dictate the type of input they want alleviating some of the post-processing and performance burden. Added speed and flexibility with low backend impact is a strong promise — primarily for data retrieval use cases and touchpoints with limited bandwidth.

But, if you want to deploy more sophisticated rules or combine a lot of elements in an ultra-distributed architecture, it will definitely fall short by itself. Performance issues are bound to increase with the complexity of queries since it might not be the most optimal management of available resources. With great power to implement smart complex logics, comes great responsibility for the backend to optimally manage it instead.

According to a Wunderman Thompson survey, the majority of hesitation towards switching to a headless microservice environment is around risk (56%), complexity (57%), and cost (68%). With suboptimal implementations, these concerns are more than justified. Given the potential benefits of going headless, technology solutions should work towards optimizing all three for maximum adoption and ROI.

A good commerce platform should already be your “BFF”.

We think the ideal backend should already be equipped with the right tools and functionalities to resolve API conflicts — without workarounds like the Backend for Frontend pattern (BFF).

That means the backend should support ultimate flexibility in collaborative API design. And, the technology should make it easy to unlock frontend creativity without causing nightmares for backend developers. This ensures the communication in between is never one-note evolving with the rest of the business.

Continuing with the analogy, the backend is, then, an empathic communicator prioritizing and easily adapting to changing needs and contexts.

Achieving this, as foreseen by Gartner, requires a “composable digital commerce platform [bringing together] modular packaged business capabilities (PBCs)”. The more modules there are the easier it is to isolate and rapidly change a feature without disturbing the rest. Yet, even composable architectures can have their flexibility limitations. If your API inputs and outputs are specific to tools, components, data models, or 3rd party vendors, then you may not be as flexible as you wish.

With rierino, we take it one step further to make micro-composable possible. You define your APIs and process flows using any library, approach or language without constraints. If you prefer to manage them as larger chunks for easier governance, it is possible. But, if you want to break a microservice into million pieces, you have the inherent capability at your fingertips. You only customize and scale what you need, and we don’t stand in your way.

Headless with a brain co-creating unique experiences.

Another area where we think backend platforms should be pulling more weight is in personalizing and elevating customer experiences. Our Cyber Week survey confirmed that consumer expectations are ever-increasing, and frustrations remain around search experiences and excessive promotions. By seeing the best-in-class, they expect fast search results like Google, relevant recommendations like Amazon, and easy navigation like Instagram.

Personalization is a top agenda item for most ecommerce leaders as well with 67% planning to invest more according to SearchNode. Yet, many of them rely on frontend customizations and add-ons partly because they cannot mess with the backend.

In the optimal headless strategy, the backend is not just a transaction and data manager, but a smart value-adding layer.

With a centralized business logic, you not only have more control overall but also ensure quality and consistency across channels with seamless transitions. The decisions, automated or not, rely on the whole story not typically exposed to every frontend. By using more data, designed experiences can go well beyond pre-defined templates without the need to start from scratch for every touchpoint.

And you can make everything smarter. Not just customer interactions, but process flows and internal user experiences can benefit from the power of AI. From real-time analytics to smart assistance, all intelligence can be united and easily operationalized.

Final Thoughts

To stay ahead of the game, continuous evolution of technology is inevitable. In this reality, we aspire for ecommerce backbones to be a lot more than what they typically are — communicating with empathy and orchestrating with intelligence.

The ideal backend should be able to carry out continuous updates without disrupting the frontend, produce data and decisions that are independent but aware of every channel, while securely managing all 3rd party integrations.

Big promises worthy of big dreams.

Like any transformation, switching to headless needs to be backed by a solid strategy to be effective. If the business model and workflows remain the same, there will only be minor performance gains from using better mission-specific components. For headless to make a true difference, your ambitions should match its potential whether it be for new channels, geographies or more customizations.

One piece of a magnificent puzzle.

Going headless is an important shift, but it is merely a starting point on the way towards true modularity. There are other equally critical attributes of modern commerce architecture, and we intend to discuss them in later posts.