Generation 4: The 25-Year Evolution From Monolith to Frontend as a Service

Commerce frontends did not jump from monolith to modern in one release cycle. They moved through four distinct generations over roughly 25 years, and each generation exists because it solved the failure mode of the one before it. Knowing which generation your storefront is actually running, not which one the vendor pitch deck implies, is the fastest way to plan the next replatforming without repeating the last one's mistakes.

Generation 1: The Monolith (2000 to 2010)

The first generation of commerce platforms, Demandware (now Salesforce Commerce Cloud), ATG, and hybris among them, bundled backend logic, templating, and rendering into a single deployable application. A landing page change meant a template edit, a QA cycle, and a release window measured in weeks. Marketing depended entirely on IT capacity, and every campaign competed with every other backlog item for the same release slot.

Generation 2: Headless Commerce (2011 to 2018)

Generation 2 decoupled the backend from the presentation layer. commercetools shipped API-first commerce, Shopify Plus opened its Storefront API, and BigCommerce followed with headless options of its own. The upside was real: teams could finally choose a best-of-breed backend without inheriting its templating engine. The catch was that someone still had to build the frontend from scratch, usually a dedicated React or Vue team, and that team became the new bottleneck. Marketing still filed tickets, just against a different backlog.

Generation 3: Composable Frontends (2019 to 2023)

The MACH Alliance formalized the term in 2020, and a wave of component-based tooling followed: Vue Storefront, Frontastic, and framework starter kits built on Next.js. Frontends became assemblies of interchangeable parts rather than one custom build, which cut development time meaningfully. But a composable frontend still meant an in-house codebase that engineering owned, deployed, and maintained. Adding a new section type or swapping a hero component was faster than in Generation 2, but it was still a sprint ticket.

Generation 4: Frontend as a Service (FaaS) (2023 to 2026)

Frontend as a Service moves the frontend itself from something a team assembles to something a platform operates. A Frontend Management Platform (FMP) ships the storefront, the visual editor, and the release pipeline as one managed, EU-hosted product. Marketing edits sections directly in Studio; engineering keeps ownership of the design system and the integration layer, not of every content change. This is the FaaS commerce model: composable stays true underneath (backend, search, and PIM remain swappable) while the frontend layer changes from infrastructure your team builds to a service your team runs on.

The four generations at a glance

What the operating-model shift actually means for teams

This is a commerce frontend evolution in ownership as much as in technology. From Generation 1 to 3, "who can change the frontend" almost always resolved to engineering. In Generation 4, that question splits: engineering owns the platform, integrations, and design system through a composable digital experience platform, while marketing owns day-to-day storefront content. That split matters more once agentic tooling enters the picture: an agentic frontend management platform can propose section changes or flag underperforming pages, but someone still needs a governed, EU-hosted environment to publish the result without a deploy. For a longer breakdown of what qualifies as an FMP in the first place, see what a frontend management platform actually is. If you are earlier in the FaaS research process, our companion piece walks through the FaaS category from the definition up.

FAQ

What is Frontend as a Service (FaaS)? Frontend as a Service is the fourth generation of commerce frontend architecture: the storefront, its visual editor, and its release pipeline are delivered as a managed, EU-hosted service rather than a codebase your team assembles and operates itself.

Is FaaS the same thing as composable commerce? No. Composable commerce describes swappable backend services (commerce engine, search, PIM, CMS). FaaS describes how the frontend layer that sits on top of those services is operated. A composable frontend can still be self-built; a FaaS frontend is managed for you, and the two are complementary rather than competing categories.

Do we lose flexibility by moving to a managed frontend? Not on the backend side. Your commercetools, Shopify, or Shopware backend stays exactly as swappable as it was in Generation 3. What changes is that your team stops maintaining frontend infrastructure and instead configures a platform.

How does FaaS fit with an existing commercetools or Shopify backend? FaaS platforms connect to existing composable backends through APIs, the same way a Generation 3 custom frontend would. The difference is that the connection layer, hosting, and editor are already built and maintained, so integration work is scoped to your specific catalog and checkout logic rather than the entire frontend stack.

What does replatforming to Generation 4 look like in practice? It typically starts with the highest-traffic templates (product listing, product detail, landing pages), migrated section by section rather than as a big-bang cutover, while the existing frontend keeps serving traffic. Most teams keep their backend and search integrations unchanged during the move.

Next step

If your team is still filing tickets for section changes on a Generation 2 or 3 frontend, the fastest way to see what Generation 4 looks like in practice is to explore the Frontend as a Service platform.