How Micro‑Frontend Architecture Transformed a Massive Ops Management Platform

Introduction

Many internal management systems become increasingly large and are maintained by multiple teams, making traditional single‑page development cumbersome and inefficient. The ShouQianBa operations management system faced similar challenges with numerous pages and fragmented team ownership.

Micro‑Frontend Operations Management Platform

The term micro‑frontend was first introduced at the end of 2016 in the ThoughtWorks Technology Radar. It extends the micro‑service paradigm to the frontend, allowing complex web applications to be composed of relatively independent functional modules maintained by separate teams. The original monolithic platform, referred to as a "giant monolith," suffered from feature bloat, code conflicts, and hard‑coded permission logic.

By adopting a micro‑frontend strategy, the platform was split into loosely coupled, fine‑grained subsystems, enabling independent maintenance. The advantages include:

Unified menu entry that aggregates different business systems.

Development isolation with vertical separation of technical platforms.

Technical isolation allowing each micro‑app to choose its own stack.

Flexible permission management via configurable modules and menus.

Loose coupling, finer granularity, and better performance.

The architecture consists of three main parts:

Container framework system

Janus‑cas SSO system

Resource permission system for registering pages and assigning permissions

Container Framework System

The platform is built with a container and a main page, using traditional iframe technology to compose them.

Container structure:

Header – top area with user info and global actions.

Tabs – primary navigation under the header.

Menus – left‑side secondary navigation.

Main area – displays the specific business function.

Resource Loading

The framework first fetches user information from its API service, stores it globally, then retrieves the authorized menu and resource tree to render Tabs and Menus.

Clicking a leaf menu loads the configured page into the main area.

Page Communication

The main page communicates with the container via the postMessage API, while the container listens for "message" events using addEventListener:

if ('addEventListener' in window) {
  window.addEventListener(
    'message',
    function(event) {
      if (event && /(\.shouqianba\.com$|\.testenv\.com$|localhost)/.test(event.origin)) {
        const { data: action = {} } = event;
        if (typeof action.type === 'string') {
          switch (action.type) {
            case 'user/logout':
              // ...
              break;
            // ... other cases ...
          }
        }
      }
    },
    false
  );
}

The container provides common functions such as logout, resource loading, showing/hiding loading indicators, global messages, tabs, menus, and setting global parameters for cross‑page communication.

When the container needs to pass data to a main page during initial load, it encodes the parameters and appends them to the page URL.

Janus‑cas SSO

Janus‑cas is an SSO system built on CAS . It centralizes authentication for all micro‑frontend applications.

It consists of:

CAS Server – handles user login and maintains session state.

CAS Client – integrated into each backend API service; unauthenticated requests are redirected to the CAS Server.

Key concepts:

TGC – Ticket‑granting cookie storing login information.

TGT – Ticket Granting Ticket generated by CAS after successful authentication.

ST – Service Ticket issued by the CAS Client to grant access to a specific application.

Resource Permission System

The system is divided into a resource module and a permission module.

Resource Module

Resources are defined as a tree: directories → menus → sub‑pages or elements. Directories and menus map to container Tabs and side menus, while sub‑pages represent concrete pages and elements represent component‑level controls (e.g., buttons). An Authorized component is provided for permission checks:

// JSX
<Authorized resourceCode="1314">
  <button>Delete</button>
</Authorized>

// TypeScript
const hasPermission: boolean = Authorized.check('1314');

Resource types include:

Directory

Menu

Sub‑page

Element

Permission Module

Permissions are organized by role and user. Roles are assigned resources; users are assigned roles, forming a many‑to‑many relationship.

Conclusion

Modern web applications are becoming increasingly feature‑rich, turning many frontends into giant monoliths. Adopting a micro‑frontend approach enables more reasonable development and modularization. Since its adoption, the platform has integrated over 500 pages, supports dozens of teams, and manages more than 200 role configurations, providing a stable and efficient environment for developers and business users.

Future work includes exploring seamless page integration via JavaScript loading, incremental resource types, and richer page structures.