Building a Front‑End System: Connecting Design, Backend, and Self‑Organization

The piece begins by noting the recent buzz in the front‑end community and introduces the author, a leader of Alibaba's data‑tech front‑end team, who will discuss systematic front‑end development.

Connecting with Designers – Front‑end work translates visual interaction designs into code, but designers often produce unpredictable specifications. By extracting reusable component standards and style variables, teams can create a base component library that supports multiple visual themes and aligns with design systems such as Ant Design.

Component Abstraction – Highly abstracted components (e.g., Ant Design’s rc‑component) allow higher‑level libraries to choose interaction behaviours, enabling rapid creation of new design languages and theme configuration platforms.

Material Design Example – Google’s Material Design sketch plugin demonstrates how design tools can generate complex UI components and even code, illustrating a chain reaction from design to implementation.

Connecting with Back‑End Development – Modern front‑ends rely on asynchronous APIs rather than synchronous requests. Interface contracts act as a binding agreement, but challenges arise from data model mismatches and frequent schema changes. Adopting shared data models, GraphQL, or mock services (e.g., Easy Mock) can reduce integration friction.

Cross‑Platform Adaptation – Different clients (web, mobile) have varying data requirements. Introducing a BFF (Backend‑for‑Frontend) layer abstracts underlying services, allowing separate BFF instances for each client while keeping core services stable.

Template Management – Historically, templates embedded system variables caused maintenance pain. Moving template rendering to a Node‑based service decouples front‑end assets from back‑end variables and simplifies SSR (Server‑Side Rendering) workflows.

Stability Assurance – End‑to‑end monitoring, trace IDs, and performance metrics across the request chain ensure rapid detection of failures, reinforcing product stability.

Front‑End Self‑Connection – The front‑end discipline has evolved from page‑level to application‑level development, demanding modular architectures (React, Flux, Observable) and continuous tool upgrades.

Architecture Selection – Choices depend on future‑oriented and scenario‑oriented considerations; static sites favour template‑centric stacks, while rich interactive products benefit from component‑driven frameworks.

Process Standardisation – The core workflow (scaffolding, build, debug, test, release) remains constant, now powered by Node‑based tools like Grunt, Webpack, and custom CLI extensions that support extensibility, decentralisation, and data monitoring.

Extensibility, Decentralisation, Data Monitoring – Command‑line tools can be extended (e.g., Gitflow), support local‑first development while synchronising to remote platforms, and report metrics to central services for optimisation.

Self‑Understanding – Distinguishing between UI logic (non‑persistent) and data logic (persistent) helps reduce uncertainty in human‑machine interaction.

Conclusion – Effective front‑end system building reduces inter‑role agreements, strengthens standards, and balances efficiency with stability; each stage should follow Unix‑style granularity, be customisable, enforce input/output contracts, automate link management, and be data‑driven.