Cloudflare刚刚推出了一种专为垂直微前端架构设计的模板，该模板允许独立的Cloudflare Workers对应于同一域名下的不同URL路径。通过结合Service Bindings与Speculation Rules API，这一模板能够帮助去中心化的开发团队自主管理他们的技术栈及CI/CD流程，同时依然能够为用户提供流畅的单一页面应用体验。
这种设计模式的核心在于从传统的横向组件混合架构转向基于路径划分的垂直化管理方式。具体来说，如果某个团队负责维护 /docs 这一路径，那么他们就可以完全掌控整个相关的技术栈——从选择诸如Astro或React这样的开发框架，到管理整个CI/CD流程，而不会影响到负责维护 /marketing 或 /dashboard 等路径的团队。
实现这一目标的技术关键在于三个方面：首先，Service Bindings使得Router Worker能够在边缘层直接与子应用Worker进行通信，从而避免通过公共互联网传输数据，进而降低延迟；其次，Router Worker本身充当了请求路由的核心组件，根据路径前缀来决定请求的处理方式；最后，HTMLRewriter会自动修改HTML响应内容，以解决路径匹配问题——例如在图片资源的链接中添加 /docs 这一路径，因为当服务经过反向代理处理时，这种链接通常会出现问题。
为了确保各个组件能够顺畅地协同工作，该模板还融入了两种现代浏览器API：CSS View Transitions技术有助于在页面切换时保持DOM元素（如导航栏）的可见性，从而避免出现“白屏”现象；而Speculation Rules API则可以预先将相关的微前端资源加载到内存中。虽然目前这一功能仅适用于基于Chromium的浏览器，但它确实能够让用户在不同的Worker之间进行几乎即时的切换。
实际上，Cloudflare自身的内部管理平台也是采用这种架构来区分核心功能与像Zero Trust这样的衍生产品。正如Cloudflare的全栈工程师Brayden Wilmoth所指出的：随着团队规模的扩大，不同框架往往适用于不同的使用场景；如果多个团队同时添加新功能，而其中某个团队引入了错误代码，那么整个更新过程很可能会被撤销，从而导致不必要的麻烦。
这种向垂直架构发展的趋势，反映了我们对于软件开发方式的根本性转变。在最近一篇InfoQ的文章中，AWS的首席解决方案架构师Luca Mezzalira指出，微前端技术的真正价值在于提升团队的自主性以及工作的流畅性，而不仅仅是代码的重用。他认为，端到端的垂直拆分结构为团队提供了理想的试验环境，使他们能够从容地处理认证、监控等复杂问题，而无需经历大规模的迁移所带来的种种麻烦。
虽然这种架构模式能够带来一些组织上的优势，但也会引发一些特定的运营方面的权衡。在这个Reddit帖子中，有人指出了与基于边缘的路由机制相关的 billing 模型所存在的问题：
需要注意的一点是：一旦添加了 Router Worker，那么所有针对静态资源的请求都会首先被发送到需要计费的 Router Worker 上，尽管实际上处理这些静态资源的 Worker 是免费的。这样一来，原本免费的、不受数量限制的静态资源请求，仅仅因为使用了基于路径的路由机制，就会变成需要付费的 Router 请求。
最后，Vercel也在2024年底采用了类似的架构方案，结果他们的预览构建时间缩短了40%，但这也带来了一些麻烦。在本地测试这些架构配置仍然是一件比较繁琐的事情，而且某些功能往往需要通过手动的方式来实现。整个行业对于这种架构模式的看法也还存在分歧：虽然对于大型企业来说，这种垂直分割的架构模式确实非常有用，但对于许多小型团队而言，如果他们的开发人员人数少于15人，那么额外的架构开销可能并不值得为此付出努力。