Frontend Development 35 min read

Micro‑Frontend Architecture and Garfish Solution Overview

This article explains the background, significance, and challenges of large‑scale web applications, introduces micro‑frontend concepts, compares SPA and MPA approaches, and details the Garfish three‑layer architecture, sandbox designs, routing strategies, deployment platform, and best practices for building enterprise‑grade micro‑frontend systems.

ByteDance Web Infra
ByteDance Web Infra
ByteDance Web Infra
Micro‑Frontend Architecture and Garfish Solution Overview

Background and Significance of Micro‑Frontends

Micro‑frontend is an architectural style similar to micro‑services, where a large front‑end product is composed of multiple independently delivered applications that can be developed, tested, and deployed separately while appearing as a single cohesive product to the user.

It arose from two major trends: the front‑end community’s rapid adoption of new frameworks, standards, and concepts, and the growing complexity of web applications that involve many teams, higher performance requirements, and larger codebases.

As network speeds, hardware capabilities, and web standards improve, traditional monolithic web apps can no longer meet user‑experience expectations, leading to the need for a new architecture that can handle massive scale without sacrificing developer experience (DX) or user experience (UX).

Challenges of Large‑Scale Web Applications

Even though web applications have become faster and more modular, their complexity and the number of involved teams have exploded, creating bottlenecks for business development. Traditional monolithic approaches (single‑page applications or multi‑page applications) each have distinct advantages and drawbacks when applied to enterprise‑level projects.

Traditional Web Application Pros and Cons

Two common strategies are:

Maintain multiple systems in a single code repository using SPA (Single‑Page Application) mode.

Separate systems into multiple repositories and aggregate them on a homepage using MPA (Multi‑Page Application) mode.

Each approach offers benefits such as better performance, local updates, pre‑loading, unified permission control, code reuse, and seamless communication, but also suffers from issues like permission conflicts, long build times, deployment blockers, messy commits, and difficulty supporting granular feature rollouts.

Micro‑Frontend Solution

The goal is to combine the UX advantages of SPA with the flexibility of MPA, while improving both DX and UX.

Ideal capabilities include isolation of development and deployment for each sub‑system, support for different technology stacks, shared base libraries, fast communication, independent iteration, incremental upgrades, unified gray‑release control, centralized permission management, a seamless user experience, and fine‑grained monitoring per sub‑system.

Overall Architecture of Garfish

Garfish, ByteDance’s internal micro‑frontend solution, follows a three‑layer design: deployment platform, runtime framework, and debugging tools, built on top of a SPA architecture.

Solution overall architecture

Micro‑Frontend Deployment Platform

The platform provides service discovery, registration, sub‑application version control, coordinated gray releases, incremental upgrades, and dependency analysis to avoid duplicate loading of shared libraries.

It delivers a list of sub‑applications (id, activation path, dependencies, entry resources) to the host, registers them, and lets the host control rendering and destruction of each sub‑app.

Micro‑Frontend Runtime

Why not iframe

Although iframes provide strong isolation, they introduce heavy memory usage, broken event propagation, inability to share login state, and poor performance. Garfish therefore implements a SPA‑based runtime that keeps sub‑apps in the same document flow.

Core Runtime Capabilities

Loader – parses HTML entry points, extracts scripts, styles, and registers sub‑apps.

Sandbox – executes code, captures side effects (global variables, events, timers, network requests, localStorage, styles, DOM), and can clean them up on unmount.

Router – synchronizes sub‑app routes with the host, provides route hijacking and driving capabilities.

Store – establishes communication bridges and shared mechanisms between sub‑apps.

Application Lifecycle

Render Phase – parse entry, create mount point, load resources, initialize sandbox, render DOM, trigger render hooks.

Destroy Phase – on route change or explicit destroy, clean side effects, remove DOM.

Loader Design

The loader works like React‑loadable , supporting asynchronous loading, pre‑loading, caching of components and instances.

Sandbox Design

Two sandbox strategies are provided:

Snapshot sandbox – saves the global environment before execution and restores it on unmount.

VM sandbox – creates a virtual execution context (window, document, timers, localStorage, listeners) to isolate dynamic side effects without the overhead of a full iframe.

Routing System Design

Modern SPA frameworks have moved routing logic from controllers to routers. In a micro‑frontend scenario, each sub‑app needs its own routing namespace (basename) to avoid conflicts, while the host must be able to synchronize route changes and trigger view updates.

Garfish provides four strategies:

Router map to reduce cognitive load in typical middle‑platform applications.

Automatic calculation of sub‑app basenames for isolation.

Accurate activation of sub‑apps on route changes.

Collecting or manually triggering popstate events to ensure view updates.

Ideal Routing Scenarios

Examples show how a host with base /demo can host Vue and React sub‑apps at /demo/vue-app and /demo/react-app , with nested routes, gray releases, and proper back‑button handling.

Best Practices with Modern Web Frameworks

Modern.js sits on top of Garfish, offering out‑of‑the‑box support for micro‑frontends, streamlined debugging, easy conversion of traditional web apps, and SSR capabilities.

Advantages and Disadvantages

Advantages: suitable for large‑scale enterprise web apps, faster development, incremental upgrades, reduced learning curve for individual modules, combined UX and DX.

Disadvantages: added infrastructure complexity, harder stability and security control, higher learning cost, need for comprehensive tooling (debugging, monitoring, deployment platform).

When to Use Micro‑Frontends

Large enterprise‑level web applications.

Cross‑team or cross‑business collaboration.

Long‑term ROI outweighs short‑term costs.

Projects with heterogeneous technology stacks.

Scenarios requiring independent release, gray rollout, or high user‑experience demands.

Conclusion

Micro‑frontends are a natural evolution of front‑end engineering, addressing the scaling challenges of modern web applications. While they shift complexity from code to infrastructure, they enable modular development, independent releases, and better DX/UX when supported by robust platforms such as Garfish and Modern.js.

For detailed runtime design, refer to the Garfish repository: https://github.com/modern-js-dev/garfish .

micro-frontendFrontend ArchitectureRoutersandboxgarfishenterprise web
ByteDance Web Infra
Written by

ByteDance Web Infra

ByteDance Web Infra team, focused on delivering excellent technical solutions, building an open tech ecosystem, and advancing front-end technology within the company and the industry | The best way to predict the future is to create it

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.