Composable explained with LEGO.

By Filippo Conforti on November 21, 2023

It is often necessary for developers to explain headless and composable commerce to non-developers. Many people might have heard that composable architectures represent the future of ecommerce development without knowing exactly what they are or what they differ from headless stacks. Other times, the terms "headless" and "composable" are just thrown around as interchangeable, which is inaccurate and can lead to misunderstandings.

As I tried to make these concepts as easy to understand and digest as possible for non-technical people, I found the LEGO analogy very useful. Even though this analogy between LEGO and composable isn't the most original, I thought I would share my take on it. Particularly, since we often talk about "heads" and "headless", I have discovered using LEGO minifigures instead of LEGO bricks helps get people to that a-ha moment quicker and remain quite imprinted in their minds.

Throughout this article—which is very visual—I'll walk you through some slides that describe the main concepts. All the images I used are available for download in a zip package below. They're all white labeled. Feel free to use them in your own presentations if you wish.

From monolith to headless

It is easy to visualize the difference between a monolithic architecture and a headless stack using a LEGO minifigure. The term "headless" refers to a body without a head.

From monolith to headless.
From monolith to headless.

According to this analogy, the head represents the frontend, which is decoupled from the backend.

The head is the frontend.
The head is the frontend.

Instead, the body is the "headless" backend.

The body is the "headless" backend.
The body is the "headless" backend.

Frontend and backend are connected through APIs. By doing this, you are able to design any frontend experience and modify it without having to change the backend.

Frontend and backend are decoupled through APIs.
Frontend and backend are decoupled through APIs.

Separating frontends and backends allows for unlimited creativity, but also provides a number of other benefits. Performance and security are two of the most obvious. In most cases, you go headless because you want a faster website that converts better.

Headless is fast!

Heads without bodies are lighter. This is why headless websites are faster. Since all functionality and data are provided through APIs, Jamstack websites can be built either with static site generation or via server-side rendering at the edge.

A decoupled frontend is lighter and faster.
A decoupled frontend is lighter and faster.

Furthermore, headless websites are generally safer, since they have a smaller attack surface than monolithic ones. The frontend and underlying APIs are the only parts exposed. It is your cloud vendors' responsibility to ensure the security of your data and the reliability of their services.

A headless architecture has a smaller attack surface.
A headless architecture has a smaller attack surface.

From headless to composable

Composable can be viewed as an evolution of headless. It is not only the frontend of your architecture that is separated from the backend, but also the backend has been broken down into specific components.

From headless to composable architecture.
From headless to composable architecture.

All components are connected via APIs. To make the integrations easier to create and maintain, integrations should be as lightweight as possible.

All components are connected via APIs.
All components are connected via APIs.

The main benefit of a composable system is the ability to select the components that are most appropriate for your specific use case. As a result, your stack will be tailored to your needs, allowing you to differentiate from your competitors and optimize your backend operations.

You can build your stack with best-in-class components.
You can build your stack with best-in-class components.

Isn't it too complex?

Does all this flexibility not introduce too much complexity and cost? The monolithic architecture is, without a doubt, simpler, but also much more limited. It is totally understandable if you don't need the flexibility of a composable platform and are satisfied with the functionality offered by a monolithic platform.

Composable may appear complex and expensive.
Composable may appear complex and expensive.

However, a monolithic application is much more difficult and expensive to customize than a stack composed of tools designed for your specific needs. Therefore, when your monolith doesn't have the functionality you need right out of the box, you will soon realize that composable is easier and can reduce your total cost of ownership.

The cost of customizing a monolith is much higher!
The cost of customizing a monolith is much higher!

Beware of imposters!

Last but not least, beware of imposters! Everyone wants to jump on the composable train. But a monolithic solution cannot become composable by just adding an API. Also, buying all components from the same vendor reintroduces the vendor lock-in that composable aims to eliminate. Don't be fooled by imitations and stay open. Put a glue on your LEGO and you're just making another monolith.

Everyone claims to be composable.
Everyone claims to be composable.

Enjoy the reading?

Subscribe to the newsletter and get a new article delivered to your inbox every week.