Micro Frontends: Evolution, Architecture, and Implementation in Car Service Platform

In 2019 micro‑frontends emerged as one of the hottest front‑end technologies. This article introduces the origins of micro‑frontends, how the architecture evolved from real‑world business needs, and the concrete practice built by Xiaoju Car Service.

What is a micro‑frontend? The concept mirrors micro‑services: a large monolithic front‑end application is split into many small, independently developed and deployed sub‑applications. Each sub‑app can use any technology stack, and a lightweight communication mechanism links them together, preserving both autonomy and overall cohesion.

Why do we need micro‑frontends? An illustrative story describes two founders who built an online shop with a single Jquery/HTML admin system. As business grew, the admin system became increasingly monolithic: product, inventory, order, and marketing modules were all tangled together, leading to cumbersome development, duplicated code, and poor operational efficiency.

The “2.0” approach tried to decouple the system by assigning different modules to different teams, but it introduced new problems: users had to switch between many separate systems, login and permission management were duplicated, and shared resources could not be reused efficiently.

3.0 – the micro‑frontend solution aggregates all business functions into a single entry point while allowing each team to maintain its own codebase and technology stack. Users enjoy a seamless experience (single sign‑on, no page refresh) and teams retain independent deployment pipelines.

Technical options for micro‑frontends include:

Routing‑based distribution (reverse‑proxy via Nginx)

Iframe containers

Widget‑style services (SDK/NPM packages)

Web Components (standard‑based, but with limited browser support)

Custom micro‑app frameworks such as single‑spa

Midway platform implementation is built on single‑spa . Applications are registered with registerApplication and loaded via loadApp . The platform adds lifecycle hooks such as beforeUnmount , afterUnmount , beforeMount , afterMount , and beforeLoad to allow custom processing before and after mounting.

For pre‑loading, after the first micro‑app mounts the event single-spa:first-mount is emitted. The platform then pre‑loads other apps during idle time using window.requestIdleCallback (or setTimeout as a fallback).

A JavaScript sandbox isolates untrusted code by creating a proxy environment, preventing interference between apps. Style isolation is achieved by hijacking HTMLHeadElement.prototype.appendChild to snapshot and restore styles; future work may adopt Shadow DOM for stronger isolation.

Resource caching uses IndexedDB managed by Dexie.js. Core APIs include cacheAssets , getCacheAssets , and clearExpiredAssets , providing a 7‑day cache lifecycle and reducing load time.

Summary : Midway follows the micro‑frontend philosophy to deliver a high‑cohesion, low‑coupling platform for backend systems, offering unified login, routing, and shared services while allowing teams to keep their own stacks. It aims to become a best‑practice, one‑stop solution for building and managing micro‑frontend based enterprise applications.

The article concludes with a recruitment notice from the Xiaoju Car Service terminal technology team, inviting front‑end engineers, client engineers (Android/iOS), AIoT hardware engineers, and interns to apply via the provided email address.