Designing a Differentiated Front‑End Architecture for Internet Finance Platforms

Background: The team works on internet‑finance development, handling monthly new scenarios where 60% of requirements are common and 40% differ, covering four main processes (application, activation, loan disbursement, repayment) that feed data to various back‑ends.

Core challenges stem from differentiation in visual interaction, product flow, risk‑control data collection, and third‑party institution outputs.

Goal: Improve development efficiency while enhancing financial product management.

Overall Architecture Design

After a half‑year componentization effort, the current focus is platform integration. Business is split into B‑end (visual configuration generation stored in the Aconf module) and C‑end (page generation based on Aconf, using component or module approaches).

C‑end – Web Front‑End Layer

New project groups start with componentization; a diagram illustrates the workflow.

Web Application Layer

Initially, PHP powered the back‑end due to high‑risk financial constraints. Migration to Node was driven by strong internal support for Node frameworks, better alignment of FE with business, reduced manpower (from 1 FE + 1 PHP to 1 FE + 0.5 PHP per scenario), and lower communication overhead.

Key innovations include separating public business (handled by FMS) from scenario‑specific business (handled by SCENE).

FMS (Public Business Module)

Multi‑version control to allow independent public business updates.

Configuration‑driven page generation; all differences are expressed in config files.

Component‑based forms and module‑based standard pages for flexible visual configuration.

AXE (Common Utilities)

Provides shared methods such as passport handling, utility functions, action base classes, RPC wrappers, unified error codes, and mock data.

SCENE (Scenario Modules)

Represents each business scenario, built on top of AXE and PHP micro‑services.

Web Service Layer

Implemented in PHP as a set of public micro‑services; scenario services are merged into the common layer, eliminating the need for separate scenario‑specific PHP modules.

B‑end – Web Front‑End Layer

Leverages an internal JSON‑schema based rapid page generation system (Amis) that outperforms traditional componentization, allowing instant visual configuration changes.

Visual component configuration (Vue props) and a library of reusable business modules are presented, each with carefully designed config items.

Web Application Layer (Backend)

Node.js provides APIs for internal business modeling, handling CRUD operations for components, modules, scenarios, and the scheduling engine; most configurations are stored as files submitted to the Aconf module for FMS parsing.

Data Storage Layer

Although MongoDB is self‑managed, MySQL (accessed via Sequelize) is chosen to reduce risk; FE designs the tables while PHP reviews them.

Source: https://mp.weixin.qq.com/s/EQngWcWlN16LX5KbV_HSiA