When headless architecture makes sense

Headless pays off when you deliver the same content or commerce functions to more than one frontend, or when your frontend has to do things a standard platform cannot. You do need a team that keeps maintaining that frontend. For a single marketing site, or a shop that runs fine on a standard theme, you mostly pay for extra moving parts.

What you decouple

With headless you separate the frontend from the CMS or the commerce platform. Shopify describes headless commerce as separating a storefront's frontend from its backend. The backend delivers data through APIs, and the frontend becomes an application you build, host and monitor yourself.

That last part is the biggest change. The platform handled previews, redirects and caching for you, and now you do.

When it pays off

I see four situations where headless is worth the effort:

• You deliver the same content or catalogue to several channels, such as a website, an app, in-store screens or a partner portal.
• You combine data from different systems on one page: product data from a PIM, content from a CMS and prices or stock from an ERP.
• Your frontend has requirements a theme cannot meet, such as a product configurator, heavy personalisation or strict load time targets.
• You want to replace the backend later without customers noticing. With your own frontend you can switch platforms behind the scenes.

When it mostly costs you money

If you have one site, a small marketing team and a standard theme that does the job, I advise against it. You would build a second application that does what the first one already did.

The same goes when no frontend team remains after launch. A headless frontend needs framework upgrades, dependency updates and security patches. If nobody does that work, the site ages faster than a theme the vendor maintains.

Think about your editors as well. People used to a page builder in the platform lose it with headless, unless your CMS has a good visual editor. Bas writes about that choice in choosing a headless CMS.

The extra parts you now build yourself

Preview is the first thing editors miss: they want to see a draft before it goes live. In Next.js you use Draft Mode for this. The CMS opens a preview URL with a secret token, and Next.js skips the cache for that editor while other visitors keep getting the cached page. It works well, but you build and secure it.

This also lands on your plate:

• Cache invalidation, with webhooks from the CMS and the commerce platform when content or prices change.
• Redirects, sitemaps, canonical URLs and structured data. The platform did that before; now it is your code.
• Customer accounts and login. With Shopify that goes through a separate Customer Account API.
• The handoff to checkout. Shopify's Storefront API serves products, collections, search and the cart, and then hands the customer off to checkout.
• Monitoring and error handling across several vendors. If the search service goes down, your product pages should keep working.

Composable commerce means more vendors and contracts

Once you go beyond a separate frontend, you choose a vendor per component: commerce, CMS, search, PIM. You can pick the best one in each category, but each one also brings its own contract, pricing model, SLA and roadmap.

So settle a few things up front. Who owns the integration layer between the frontend and the vendors? Who calls which vendor when something breaks at night? And how do you pin down the contracts between your own components? Boris covers that last question in designing API-first.

I would never let the frontend talk to five vendors directly. Put a layer of your own in between, a backend for frontend, that translates vendor APIs into what your pages need. When you swap a vendor, you change that layer and the frontend stays as it is.

Who runs it

A headless frontend needs maintenance for as long as it is live. Plan for ongoing capacity, even when no new features are coming. For a small site that is part of one developer's time. For composable commerce with several vendors it is a team.

Splitting up your backend involves the same trade-off: more separate parts means more boundaries to guard. That is the subject of monolith or microservices.

A middle ground

You do not have to rebuild everything at once. A middle ground I recommend is to keep checkout and customer accounts on the platform and build only the content and landing pages headless. That is usually where teams want the most freedom, and where the risk is smallest.

If you work with Shopify, there is a headless route of its own. Hydrogen is Shopify's toolkit for building a storefront and Oxygen is its hosting for those storefronts. You are still in Shopify's ecosystem, but the frontend is yours.

Sources

• Shopify: headless storefronts
• Next.js: Draft Mode