7 Storefront Architectures For Headless Commerce: Which Is The Best For You?

Originally posted in LinkedIn - https://www.linkedin.com/pulse/7-storefront-architectures-headless-commerce-which-best-kane-balagtey/

Notes & Definitions

• BFF (dark blue in diagrams) - Backend-For-Frontend refers to frontend code responsible for API integration.
• FFF (light blue in diagrams) - Frontend-For-Frontend refers to the frontend code responsible for customer interaction.
• BE (red colour in diagrams) - Backend refers to Non-JavaScript software development.
• FE (blue colour in diagrams) - Frontend refers to JavaScript-related software development.

Introduction

Gone are the days where commerce suites are the only option.

Here are 7 Storefront Architectures for those thinking about headless commerce.

1. Digital Experience Platform (DXP) Led Storefront Architecture

2. DXP Led Storefront Architecture is best for established brands and mature retailers. DXPs are a good match for older institutions, such as AEM for Telcos.
   
   Investing in DXPs today is like buying a Nokia in the age of smartphones. Like Nokia, DXPs are reliable and performs well—but ageing. They lack the agility and dynamism required to meet modern-day consumer demand. Mid-market brands are better off with a JavaScript-oriented headless CMS. Choosing a modern CMS aligns your technology stack with PWA storefronts and emerging technologies.
   
   Other suited retailers for DXP are B2B organisations. For B2B, page load performance is not as critical compared to feature-richness. DXPs are more feature-rich than headless CMSs since they are older, and had more time to mature. Therefore, making DXPs ideal for handling B2B specific scenarios.
   

3. Headless Commerce Starter Pack Storefront Architecture

2. Starter Pack is best for brands and retailers modernising their commerce suite.
   
   Starter Pack keeps your options open while waiting as the technology landscape matures. For fast followers, going in this direction is a safe and future-proof choice. Businesses who err towards caution or sceptical of new technology can camp here. This architecture will keep business processes the same while appeasing internal Fears-of-Missing-Out (FOMO). For SAP Commerce customers, you can upgrade using SAP Spartacus. Spartacus is a PWA storefront that is well built and documented.
   
   However, if you're using many best-of-breed SaaS already—is a suite still suitable for you? It might be worth using a Mono Storefront Architecture instead. In this way, you can replace your commerce platform with another provider without additional cost for refactoring integrations.
   

3. Composable Commerce w/ Mono Storefront Architecture

2. Mono Storefront Architecture is similar to the Headless Commerce Starter Pack (Figure 2). However, in the Starter Pack, the commerce platform handles API integrations. In Composable Commerce w/ Mono Storefront, API orchestration happens in the BFF layer.
   
   Comparing commerce suites and composable commerce is like booking a holiday. All-inclusive package (commerce suite) versus DIY holiday (composable commerce). You either ask the travel operator to pull together an itinerary for you, or you plan it yourself. If you've made the comparison and chose composable, Mono Storefront is a great way to start your journey.
   
   Mono Storefront is the cheapest architecture for retailers moving to composable commerce. Early adopters can use this architecture to keep it simple, avoiding delivery risk. Depending on your requirements, you can choose to build or buy a commerce storefront.
   

3. Hydra Storefront Architecture

2. Hydra Storefront Architecture refers to having many 'heads'. The BFF acts as a man-in-the-middle separate from your commerce, CMS, or storefronts. At the same time, the storefronts are only concerned about presentation.
   
   Hydra Storefront is best for multichannel retailers wanting to reduce API integration cost.
   
   You can choose to have many BFFs if you're concerned about introducing a single point of failure. For example, having a dedicated BFF for the web storefront and a separate BFF for in-store & mobile.
   
   Separating business layers from storefronts is a tried and tested architecture similar to Model-View-Controller (MVC).
   

3. Micro Frontend Storefront Architecture

2. Micro Frontend is helpful for engineering teams struggling to scale. Imagine managing a football team. They need to get to a game. You hire a shuttle bus, and each player has to wait. An accident happens near the benchwarmer's home, causing the whole team to be late. What if some team members drove instead? They can leave in parallel, using their own cosy cars, and choosing the quickest routes. Allowing players to travel alone instead of waiting for the bus is like using Micro Frontend. Splitting the team leads to faster results with higher fault tolerance. If one vehicle arrives late, it does not delay the others.
   
   However, it helps to weigh the risk between fostering independence and unity. Independence might avoid delays, but a unified front is essential. In contrast to microservices, separation of concern in the frontend is a problem. Customers consume web pages, not isolated components. Websites are at their best when pieces are like threads woven together to create a single fabric. When engineers in charge of frontend abstractions know little about customer experience—Micro Frontend results in a car crash. Customer journeys become disjointed, and the page load is slow.
   
   Micro Frontend can only lead to successful storefronts when the engineering leader values customer experience more than developer comforts.
   

3. Edge Frontend Storefront Architecture

2. Edge Frontend Storefront Architecture is the most state-of-the-art architecture achievable to date. This architecture is best for ambitious up-and-coming brands pushing customer experience to the limit. The idea is to 'stitch' the storefront at the CDN Edge, which is closest to the customer.
   
   Edge Frontend interacts with cloud-hosted APIs close to the edge and a design system—a combination of speed and brand consistency. When personalisation is in the mix, this architecture beats any other.
   
   Edge Frontend is like delivering flat-pack IKEA furniture to a customer's house, and tailoring it to the space they have—efficient transportation, just in time build, and custom-tailored product.
   
   However, Edge Frontend also requires disruptive changes in software development and business practices. A double-edged sword, but for the do or die pure players—Edge Frontend is a speed train that can help you get ahead of the pack.
   

3. Low-Code Platform (LCP) Storefront Architecture

5. LCP is a speculative storefront architecture for the visionary leader. LCPs have been around for a long time, but new generation LCPs are being seeded generously. For example, WebFlow raised $140m, pushing its valuation to $2.1 billion.
   
   LCP goals have remained the same. Produce beautiful content with little technical knowledge. What's different today is the variety of technology allowing young LCP gardens to take shape:
   

• CSS features are developing deep roots
• Web Browser are now evergreen with no compatibility issues
• Component-based architecture is gaining vigour
• Utility-based practices like Tailwind CSS is climbing up
• Wild Design Systems are pleasing for designers and engineers alike
• Tools like Figma (UX), Sketch (UI), and Storybook (Dev) are cross-pollinating successfully

2. After headless and edge storefronts, LCP is the potential architecture to flourish next. Once LCPs mature, they will provide an environment for creatives to cultivate attractive content that will leave consumers in awe.

Final Thoughts

There are two related push-or-pull ideas worth noting:

1. Centralisation and Decentralisation (Control & Autonomy)
2. Technicality and Creativity (Constraint & Freedom)

Control and autonomy for architectures centralise and decentralise—much like people and nations. In the same way, the balance between creativity and technicality often swings like a pendulum. A historical phenomenon worth observing if you want to maximise profitability through architecture.

Too much freedom leads to inconsistencies, but lack of it stifles innovation. Architecture is the technical measures we put in place to ensure results. However, you can also solve the problem using people or process. As with every aspect in this universe, a tri-unity of variables go hand in hand:

• Platform (Architecture)
• Process (Delivery Management)
• People (Team Makeup)

I can cover the other Ps in future articles.

Your turn, what do you think?

What do you think about the storefront architectures listed? What are your thoughts about architecture in general? Please drop a comment and let me know!

Are you planning for Headless Commerce?

If you need help with your storefront architecture, send me a message. I'm keen to help and partner with IT leaders taking that next step to headless commerce.

About the Author

Kane Balagtey has 13 years of software development experience. With 7 years of experience as a commerce storefront consultant, architect, and developer.

Special thanks to friends and ex-colleagues at Tacit for various feedback and input.