Performance Optimization and Architecture Refactoring of DeWu Customer Service Ticket Frontend

1. Business Overview DeWu's customer service ticket system handles events that require客服 (customer service) intervention. Its core functions are to store event basic and related information and to allow客服 to process and circulate the information.

2. Core Workflow The ticket workbench serves as the production line for second‑line客服, covering ticket collection, display, processing, circulation, and final closure. Daily ticket volume is large, with many客服 spending most of their workday on the workbench.

3. Front‑end Issues Two main pain points were identified: (1) performance, stability and usability for客服; (2) development efficiency problems such as difficult code maintenance and heavy online incident handling.

3.1 API Aggregation By collaborating with backend to use a gateway aggregation mode, the number of initial interfaces for ticket detail rendering dropped from 21 to 5, reducing total render time to under 600 ms.

3.2 Fast/Slow Interface Split Over 190 fields in the order detail API were divided: fast interfaces remove the slow external‑domain fields (cutting RT to <300 ms) while slow interfaces provide the remaining data. Interface batch updates were limited to three render cycles to lower CLS.

3.3 Module Federation Introducing Module Federation (MF) replaced iframe and npm‑package solutions, cutting render time by ~6× and memory usage to ~1/10. A comparison table shows iframe first‑screen 7076 ms vs. MF 1279 ms; non‑first‑screen 2594 ms vs. MF 428 ms.

3.4 Single‑Instance Design Ticket detail pages were redesigned as a single instance to avoid DOM explosion when multiple tabs are opened. PostMessage communication between the workbench and the ticket system enables fast tab switching without iframe overhead.

3.5 Dynamic Rendering via Schema A schema‑driven approach was adopted for ticket creation, closure, and order detail pages. Forms and workflows are expressed as JSON schemas, allowing rapid UI changes without code modifications. This reduced front‑end to back‑end development ratio for closure flows from 1:1 to 1:3 and saved ~66 % of front‑end effort for order‑detail changes.

4. Release and On‑Call Mechanisms Strict release gates (environment validation, permission checks, impact assessment) and multi‑person front‑end acceptance were introduced. On‑call duties were aligned with second‑line客服 work hours, achieving ~5‑minute response times for issues.

5. Outcomes After the refactor, TypeScript‑related front‑end bugs dropped to zero (Q1 2023) and客服 satisfaction rose to 80 % (Q1 2023).

6. Class‑like Capabilities Exploration The workbench exhibits high usage frequency, long daily usage time, and intensive interactions, similar to desktop applications. Future work includes: (a) plugin‑based business components via MF; (b) standardized routing SDKs; (c) built‑in utilities such as clipboard‑based screenshot upload; (d) caching of frequently requested data with Service Workers, achieving order‑of‑magnitude speed gains; (e) version push notifications and independent window deployment.