Cloudflare has recently unveiled a Worker template for Vertical Microfrontends (VMFE), a groundbreaking architecture that revolutionizes how independent Cloudflare Workers are mapped to specific URL paths on a single domain. This innovative approach, detailed in the link (https://dash.cloudflare.com/?to=/:account/workers-and-pages/create?type=vmfe), empowers decentralized teams to manage their own stacks and CI/CD pipelines, all while delivering a seamless, single-page application (SPA) experience to users. The key to this transformation lies in the shift from horizontal component mixing to vertical, path-based ownership. Imagine a team that owns the /docs route; they have complete control over the entire vertical stack, from choosing frameworks like Astro (https://developers.cloudflare.com/pages/framework-guides/deploy-an-astro-site/) or React (https://react.dev/) to managing the entire CI/CD pipeline, without any interference from teams handling other routes like /marketing or /dashboard. This level of autonomy ensures that each team can work independently and efficiently, without stepping on each other's toes. The technical underpinnings of this architecture are threefold. Service Bindings enable a Router Worker to communicate directly with sub-application Workers at the edge, minimizing latency by avoiding the public internet. The Router Worker acts as the front door, directing requests based on path prefixes. Lastly, the HTMLRewriter automatically adjusts HTML responses to correct pathing issues, such as adding /docs to image sources, which often break when services are reverse-proxied. To ensure a smooth user experience, the template incorporates two modern browser APIs. CSS View Transitions keep DOM elements like navigation bars visible during page changes, eliminating the 'white flash' typically seen in Multi-Page Applications. Additionally, the Speculation Rules API is used to prefetch linked microfrontends into memory, significantly enhancing the speed of jumping between physically separate Workers, although this feature is currently limited to Chromium-based browsers. Cloudflare's internal dashboard actually leverages this model to separate core features from products like Zero Trust. Brayden Wilmoth, a full-stack engineer at Cloudflare, highlights the challenges teams face as they grow, where different frameworks serve varying use cases. He notes, 'An update to add new features from several teams can get frustratingly rolled back because a single team introduced a regression.' This shift towards verticality mirrors a broader trend in software development, as emphasized by Luca Mezzalira, principal solutions architect at AWS, in a recent InfoQ article (https://www.infoq.com/articles/adopt-micro-frontends/). He argues that micro-frontends should be about team autonomy and 'flow' rather than just code reuse. An end-to-end vertical slice, according to Mezzalira, serves as a perfect 'proving ground,' allowing teams to tackle complex issues like authentication and observability without the nightmare of a 'big bang' migration. However, while the architecture offers significant organizational benefits, it also introduces specific operational trade-offs. A Reddit thread (https://www.reddit.com/r/CloudFlare/comments/1qr8bzr/buildingverticalmicrofrontendsoncloudflares/) highlights a caveat involving the billing model for edge-based routing. The addition of a Router Worker means every static asset request now hits a billable Worker first, even though the underlying static asset Workers are free. This could potentially convert free, unlimited static requests into metered Router requests just for path-based routing. Lastly, Vercel, in late 2024, achieved similar wins by reducing preview build times by 40% with their vertical approach, but they didn't ignore the challenges. Testing these setups locally remains a bit of a chore, and certain features often require manual workarounds. The industry is still divided on this concept, with vertical slices being a lifesaver for large enterprises, but many smaller teams are questioning whether the extra architectural 'tax' is worth the trouble, especially if they have fewer than 15 developers.
