Imagine a robot chef
Traditional E-commerce (Not Headless)
Think of a regular restaurant. The robot chef (the backend) cooks the food (products, prices, orders) and also serves it directly to the customers in the dining room (the frontend — the website you see). The chef and the waiter are tightly connected. If you want to change how the food is presented (new plates, different table layout), you often need to change the chef’s kitchen too.
Headless E-commerce
Now imagine the robot chef is in a separate building (the backend). It only focuses on cooking the delicious food (managing products, prices, inventory, orders). It doesn’t have a dining room.
Instead, it has a menu API — a way for other services to ask for the food.
Then, you can have many different waiters (the frontends) in different locations:
🍝A fancy waiter in a nice restaurant (your website built with Next.js).
🗣️A friendly voice assistant taking orders over the phone (a mobile app).
📍A self-service kiosk in a stadium (a point-of-sale system).
🧊Even a smart fridge that automatically orders when you’re low on milk!
The key idea is the separation:
💻Backend (Head): The “brain” that handles all the logic and data (products, customers, orders, payments). It just provides the information through the menu API.
💅Frontend (Body): The “face” that the customer sees and interacts with. It asks the backend for information through the API and displays it in whatever way makes sense for that specific channel.
Why is this useful?
💸More Flexibility: You can create many different customer experiences without changing the core e-commerce logic. Want a website, a mobile app, and a smart device integration? No problem!
💸Faster Innovation: Frontend developers can work on the customer experience using the latest technologies without being tied to the backend’s limitations.
💸Better Performance: You can optimize each frontend for its specific platform.
💸Future-Proof: As new ways to interact with customers emerge (like voice or AR/VR), you can easily build new frontends that connect to your existing backend.
Examples
🤹🏻♂️Content Management Systems (CMS):
🤯Headless:
- Contentful: A popular API-first CMS focused solely on content creation and delivery via APIs.
- Sanity: Another API-first CMS with a real-time content lake and flexible data modeling.
- Strapi: An open-source, Node.js-based headless CMS that allows developers to easily create custom APIs.
- Netlify CMS (Git-based): A headless CMS that stores content directly in your Git repository.
- Ghost (as a headless CMS): While Ghost has a built-in frontend, it can also be used as a headless CMS with its API.
💀Headful (Traditional):
- WordPress: A widely used CMS where the content management and presentation layers are tightly coupled (themes). However, WordPress can also be used in a headless manner with its REST API.
- Drupal: A powerful CMS with a traditional architecture, but also increasingly adopting headless capabilities.
- Joomla: Another traditional CMS with a coupled frontend and backend.
- Adobe Experience Manager (AEM): A comprehensive digital experience platform with both content management and delivery capabilities tightly integrated.
🛍️E-commerce Platforms:
🤯Headless:
- Medusa: An open-source, API-first e-commerce platform (as we’ve discussed).
- Shopify (via Storefront API): While Shopify has a built-in online store, its Storefront API allows developers to build custom frontends (headless).
- BigCommerce (via APIs): Similar to Shopify, BigCommerce offers APIs for headless implementations.
- Commerce Layer: A headless commerce API platform focused on transactional logic.
- Saleor: An open-source, GraphQL-first e-commerce platform.
💀Headful (Traditional):
- Shopify (with its default themes): Using Shopify’s built-in theme system creates a headful setup.
- BigCommerce (with its Stencil themes): Similar to Shopify, using the default theme engine is headful.
- Magento (Adobe Commerce): A traditional e-commerce platform with a tightly coupled frontend (Luma theme). However, it’s also moving towards more decoupled architectures.
- WooCommerce (WordPress plugin): Being a WordPress plugin, it inherits the headful nature of WordPress by default.
🏰Other Tools/Platforms:
🤯Headless:
- Algolia (Search-as-a-Service): Provides search functionality via APIs, without a built-in UI.
- Twilio (Communication Platform): Offers APIs for SMS, voice, and video communication.
- Stripe (Payment Gateway): Provides APIs for processing payments.
💀Headful:
- Traditional Web Servers (e.g., Apache, Nginx serving static HTML): The server directly delivers the complete web page.
- Desktop Applications: Typically have a tightly integrated UI.
All in All
The core difference lies in the separation of concerns:
🤯Headless: The backend (data, logic) is decoupled from the frontend (presentation). Communication happens via APIs. This offers flexibility in building diverse user interfaces.
💀Headful: The backend and frontend are tightly integrated. The tool typically dictates how the content or functionality is presented.
Many modern platforms are adopting a more API-first approach, even if they started as headful, to offer greater flexibility and cater to the growing demand for omnichannel experiences.
If you liked this content I’d appreciate an upvote or a comment. That helps me improve the quality of my posts as well as getting to know more about you, my dear reader.
Muchas gracias!
Follow me for more content like this.
X | PeakD | Rumble | YouTube | Linked In | GitHub | PayPal.me | Medium
Down below you can find other ways to tip my work.
BankTransfer: "710969000019398639", // CLABE
BAT: "0x33CD7770d3235F97e5A8a96D5F21766DbB08c875",
ETH: "0x33CD7770d3235F97e5A8a96D5F21766DbB08c875",
BTC: "33xxUWU5kjcPk1Kr9ucn9tQXd2DbQ1b9tE",
ADA: "addr1q9l3y73e82hhwfr49eu0fkjw34w9s406wnln7rk9m4ky5fag8akgnwf3y4r2uzqf00rw0pvsucql0pqkzag5n450facq8vwr5e",
DOT: "1rRDzfMLPi88RixTeVc2beA5h2Q3z1K1Uk3kqqyej7nWPNf",
DOGE: "DRph8GEwGccvBWCe4wEQsWsTvQvsEH4QKH",
DAI: "0x33CD7770d3235F97e5A8a96D5F21766DbB08c875"