Patrick Steil Cloud eCommerce Architect

Patrick Steil

Headless Commerce

What in the world is headless commerce!

Ok, so lately I've been having all kinds of fun with random projects.

Headless Commerce

I have been testing out different headless CMS platforms:

  • buttercms
  • django-cms
  • keystone.js
  • payload
  • sanity
  • strapi
  • webiny

I have also been testing out different ecommerce platforms:

  • crystallize - pim with headless commerce
  • hydrogen - shopify headless project
  • strapi - also for ecommerce

So the basic idea is that you have a headless CMS and a headless ecommerce platform. You can then use the headless CMS to manage your content and the headless ecommerce platform to manage your products and orders. You can then use a headless frontend framework to build your frontend.

The idea here is to make you more nimble, not dependent on a single monolithic platform for your entire ecommerce presence.

Each headless component would give you an API interface to access your content on every media you might need it: web, mobile app, watch app, kiosk, edge-content app, pwa, whatever comes next!

But this also means that:

  • you have to build your own frontend and do the API integration - AND SUPPORT THIS CODE
  • it also means you will have many moving parts to manage and maintain

These are the low hanging fruit that everyone realizes:

  • you will have to build your own product catalog experience
  • you will have to build your own product detail experience
  • you will have to build your own checkout experience

But what about all these functions that your monolithic ecommerce platform does for you?

  • the customer account experience
  • the product search experience
  • the product filtering experience
  • the product sorting experience
  • the product recommendations experience
  • the product reviews experience
  • the product ratings experience
  • the product wishlists experience
  • the product compare experience
  • the product upsell experience
  • the product cross-sell experience
  • the product bundle experience
  • the product subscription experience
  • the product gift experience
  • the product gift card experience
  • the product gift registry experience
  • the product gift wrapping experience
  • the product gift messaging experience
  • the product gift receipt experience
  • the product gift return experience
  • the product gift exchange experience
  • the product gift card balance experience
  • the product gift card reload experience
  • the product gift card redeem experience
  • the product gift card check balance experience

I am not convinced this is the right way to go!

But I do see some architectual benefits that this latest movement might bring:

  • will force the monolithic vendors to make their API's more robust and awesome
  • will force the monolithic vendors to support allowing us to define the data model of the catalog

This last point is a big one. If we can define both the location and the data model of the catalog, then we can be more nimble in changing out the platform without having to change the data. THIS could be huge.

I am not sure if this is the right way to go, but I am excited to see where this goes!

Copyright 2023 - Patrick Steil - All rights reserved. patrick@infranet.com