Composable commerce architecture: MACH vs. JAMstack vs. DXP

by Ned Hallett
Published on July 2022

MACH. DXP. JAMstack. Composable architecture. PBCs.

In an industry that loves to drown you in acronyms – and doesn’t mind when meanings overlap – keeping up with everything can feel like wading through a pool of scrabble tiles.

In this trusty guide, we’ll be unpicking the technology and business contexts that fall under the broad umbrella of composable commerce. 

So, lean in; it’s about to rain.

What we’ll learn (in the patented Just After Midnight ‘CAC’ format):

Concepts:

  • What composable architecture is 
  • How it differs from composable DXP

Architecture:

  • How MACH fits in 
  • What PBCs are 
  • How PBCs differ from microservices 
  • How JAMstack fits in 

Contexts: 

  • Why composability is key
  • Advantages of composable commerce 
  • How we can help 

Concepts: what is composable commerce?

Composable commerce is more of a business-level term. That means it describes an outcome that can be reached via a few different technology approaches (which we’ll get to below).

This outcome is composability in a commerce stack, which means various business capabilities (e.g. payment gateway, product search, billing) can be selected and replaced easily from an array of third-party service providers.

Or, a traditional ‘monolithic’ commerce stack = soup; a composable commerce stack = tapas.

In the former, all the ingredients are irreversibly mixed up. In the latter, pick, swap and nibble at your leisure.

There are other advantages to composability, which we’ll get to later, but this core functionality is the bedrock.

How is this different from DXP/composable DXP

When people talk about DXPs, they mean non-composable monolithic experience platforms. Once these become composable (as in composable DXP) they’re very similar concepts to composable commerce, except composable DXP is the slightly more specific term, naming an actual platform rather than the more general idea of composability in commerce.

Architecture: MACH and JAMstack, the technologies behind composable commerce

The easiest way to think about MACH and JAMstack is that MACH enables composability on the backend while JAMstack does so on the frontend.

They very much are two sides of the same coin.

So let’s start at tails (the backend).

How MACH fits in 

MACH is a group of technologies which, used together, enable composable architectures.

These are:

  • Microservices 
  • API-first 
  • Cloud-native SaaS
  • Headless

Well, that’s one acronym down. Now let’s take a closer look…

a diagram

Image source: fabric.inc

Microservices are small modular services that combine to form an application. Very similar to our soup and tapas example.

API-first is a development approach that centres on APIs (application program interface; another acronym bites the dust) which can be thought of as the shared language of various components of MACH.

Cloud-native SaaS is a software deployment pattern wherein users access a single cloud-native hosted version of the app that can be scaled and updated from a central point.

Headless means decoupling the front and backend so that content can be served via APIs to a variety of touchpoints and devices.

What PBCs are – one level deeper 

PBC – the third acronym on our hitlist – stands for packaged business capabilities. 

a diagram

Image source: Sitecore.com

In composable commerce, microservices are generally aggregated into a single business function (like cart and checkout in the above example).

However, also as per the above example, these can be fulfilled by a single microservice.

A good way to think of it is that, in composable commerce, the architecture building blocks are grouped by purpose – but this purpose can be fulfilled by a single block, in which case it’s in a group of its own.

A bit like how you can have multiple people making up a party, but if you’re incredibly fun, a party of one is possible.

On to heads (the frontend).

How JAMstack fits in 

Like MACH, JAMstack is a development approach that focuses on composability.

But it’s also an acronym hidden in plain sight:

  • JavaScript 
  • APIs 
  • Markup 

All combined in a stack – hence Jam…stack.

As explained, JAMstack is more focused on the front end. And each element has a role to play.

a diagram

Image source: researchgate.net

In the above, we can see a JAMstack setup vs. a traditional webpage.

In JAMstack, the UI is decoupled from the backend services, and pre-rendered static sites are served via a CDN in mark-up.

This all happens client-side, as opposed to in a traditional set-up where the backend services are engaged to handle user requests.

This all means much less time and resources go into serving a webpage.

On top of this, microservices can be brought in via API (much like in MACH), while JavaScript handles dynamic features and communicates with the backend.

JAMstack vs. MACH…JAMstack + Mach?

JAMstack and MACH both enable composable commerce – and they can work together or separately.

When to use JAMstack and MACH together 

It’s possible to apply a MACH approach to the backend of your composable commerce architecture and a JAMstack approach to the frontend. 

This could give you very fast-loading static web pages served by an array of lean, replaceable PCBs.

Why NOT use JAMstack and MACH together 

Dynamic elements

If your composable commerce solution features dynamic pages, you won’t be able to use JAMstack. Static pages only  – unless you want to do A LOT of extra work.

Content editor friendliness 

The goal of some composable commerce platforms is to have non-technical users author experiences via intuitive UIs. 

This is full composability. 

In JAMstack, editors will need to interact with the markup, which goes against the ethos a little.

Pushing things client side can drain the battery 

Seeing as many composable commerce solutions are going to be accessed by mobile, the drain on device resources caused by pushing everything client side can be an issue. 

Context: why composability and how we can help 

Why composability is key 

As explained, the key functionality of these technologies is enabling composability: a component-driven, fast-adapting stack capable of pulling in the very best of third-party vendor services and dropping them just as quickly.

This is the trend throughout tech. To decompose, decouple and generally atomise (atomic content is a tech-ism we didn’t even get to) so that we get these lean mean orchestral sales-generating machines. 

Which in practice means…

Key advantages of composable commerce 

  • A future-proof technology stack (since it can incorporate and shed services as and when)
  • Faster time to market for new features 
  • Unparalleled scaling (each service can be scaled independently via cloud-native services)
  • No vendor lock-in
  • The ability to define and personalise customer experiences  
  • A business-focussed approach to architecture that can help align stakeholders 
  • Massively increased flexibility

And with Gartner predicting that companies adopting a composable approach will outpace the competition by 80% in 2023, it’s safe to say people are taking notice.

How we can help 

Now we’ve put a word to a fair few anonymous letters, there might be something else we can help you with.

At Just After Midnight, we’ve made a name for ourselves supporting mission-critical apps via our pioneering 24/7 support system – be it fully composable, an old-school monolith – or something in between.

We’ve helped No.1 eCommerce brands like Procook and fortytwo secure millions in revenue through support, cloud solution architecture and more.

So to find out how we could help you – just get in touch.

While we’ve got you

If you want an even more in-depth understanding of composable commerce and how we got here, why not download our free report on the future of eCommerce.

SHARE