W13 - Survey of Architectural Options

This week I reviewed several architectural approaches used across the broader frontend domain to prepare for selecting an architecture for the merchant platform. I’ve currently collected the following three categories.

Page-level micro-frontend based on open-source frameworks. These are built using micro-frontend frameworks like qiankun and garage. Representative projects are mostly M-end applications, such as the ecosystem’s CMM and the Zhuge platform.

Component-level micro-frontend based on EDC. The representative example is the ecosystem finance MFC. Its stability and availability have been partially validated by co-branded C-end cards, and it is in the stage of platform-oriented externalization. The integration and modification costs remain to be determined.

Node-based multi-page application architecture. The representative is C Wealth’s CORPS..This addresses the splitting and autonomy of business processes. The merchant platform faces more issues with horizontal coupling between business domains; optimizing the deepest vertical processes is not the most painful concern.

Given our situation—limited manpower and the need to keep business running—the priority order for selecting an approach should be, from highest to lowest: cost, stability, and performance. Cost includes two aspects: low migration cost for existing projects and low maintenance and team comprehension cost. By stability I mean the intrinsic stability of the architecture, which should at least match the current merchant platform. After an architectural change, because subservices need to be independently autonomous, the overall stability of project iterations should improve significantly. Performance refers to the performance ceiling the new architecture can provide; I believe some trade-offs are acceptable. First, current service performance is not very high and has room for improvement; second, B-end scenarios are generally more tolerant of performance constraints than C-end.