Cloudflare just rolled out a Worker template for Vertical Microfrontends (VMFE), an architecture that maps independent Cloudflare Workers to specific URL paths on one domain. By pulling together Service Bindings and the Speculation Rules API, the template lets decentralized teams manage their own stacks and CI/CD pipelines while still giving users that smooth, single-page application (SPA) feel.
The shift here is about moving away from horizontal component mixing toward vertical, path-based ownership. Essentially, if a team owns the /docs route, they control the whole vertical stack—from choosing a framework like Astro or React to handling the entire CI/CD pipeline—without ever stepping on the toes of teams managing /marketing or /dashboard.
The technical glue comes down to three parts. Service Bindings allow a Router Worker to talk to sub-application Workers directly at the edge, keeping latency low by staying off the public internet. Then there’s the Router Worker itself, acting as the front door to steer requests based on path prefixes. Finally, the HTMLRewriter automatically tweaks HTML responses to fix pathing issues, such as adding /docs to image sources, which usually break when services are reverse-proxied.
To keep things from feeling disjointed, the template bakes in two modern browser APIs. First, CSS View Transitions help keep DOM elements (like a nav bar) visible during page changes, which kills off the “white flash” you’d normally get with Multi-Page Applications. On top of that, it uses the Speculation Rules API to prefetch linked microfrontends into memory. Truth be told, this only works in Chromium-based browsers for now, but it makes jumping between physically separate Workers feel nearly instant.
Cloudflare’s own internal dashboard actually uses this model to split core features from products like Zero Trust. As Brayden Wilmoth, a full-stack engineer at Cloudflare, put it:
Teams face problems as they grow, where different frameworks serve varying use cases… An update to add new features from several teams can get frustratingly rolled back because a single team introduced a regression.
This move toward verticality mirrors a bigger shift in how we think about software. In a recent InfoQ article, Luca Mezzalira, principal solutions architect at AWS, pointed out that micro-frontends should really be about team autonomy and “flow” rather than just reusing code. He argues that an end-to-end vertical slice is a perfect “proving ground,” letting teams tackle messy stuff like auth and observability without the nightmare of a “big bang” migration.
While the architecture offers organizational benefits, it introduces specific operational trade-offs. On a Reddit thread, a correspondent noted a caveat involving the billing model for edge-based routing:
CAVEAT: Adding Router Worker means every static asset request now hits a billable Worker first (the router), even though the underlying static asset Workers are free. We’d be converting free unlimited static requests into metered Router requests just for path-based routing.
Lastly, Vercel saw similar wins back in late 2024 by cutting preview build times by 40% with their vertical approach, but they didn’t ignore the headaches. Testing these setups locally is still a bit of a chore, and certain features often need manual workarounds. The industry is still pretty split on the whole idea, too. While vertical slices are a lifesaver for massive enterprises, many smaller teams are realizing that if you’ve got fewer than 15 developers, the extra architectural “tax” might not be worth the trouble.
