Frontend Development 12 min read

Integrating Two Large Frontend Applications: Architecture, Deployment, and Code Refactoring

This article describes how two large front‑end platforms were systematically merged—covering background analysis, deployment optimization, repository consolidation, application‑type detection, routing, environment variables, request encapsulation, permission handling, and the resulting improvements in development efficiency and user experience.

JD Retail Technology
JD Retail Technology
JD Retail Technology
Integrating Two Large Frontend Applications: Architecture, Deployment, and Code Refactoring

Background: Two platforms A and B belong to the same system chain; A provides registration services, while B focuses on business operations. Both are online management tools relied upon by operators.

Current situation: B's pages are fully embedded in A, creating system and experience pain points. The team considered merging the two platforms at the code level to improve user experience and reduce cost.

Solution overview: The integration was achieved by systematic code merging, unified deployment, and environment‑aware routing, resulting in higher development efficiency and reduced server resources.

Key measures include:

Deployment optimization: moving from combined front‑back deployment to independent front‑end deployment and using a hybrid container strategy.

Repository consolidation: A’s three projects share a single code repository with unified coding standards, while B’s front‑end code was extracted and integrated without affecting existing configuration.

Project structure: unified Vue2 framework with a detailed directory layout, illustrated by the following tree: ├── root │ ├── mocks │ ├── public │ ├── src │ │ ├── api │ │ │ ├── apiA // A business requests │ │ │ ├── apiB // B business requests │ │ │ ├── apiC // C business requests │ │ │ ├── baseHttp.js // base request wrapper │ │ │ ├── ARequest.js // A‑specific request handling │ │ │ ├── BRequest.js // B‑specific request handling │ │ │ ├── CRequest.js // C‑specific request handling │ │ │ ├── DRequest.js // D‑specific request handling │ │ ├── assets │ │ ├── common │ │ ├── components // shared components │ │ ├── directive // custom directives │ │ ├── layout // shared layout │ │ ├── router │ │ │ ├── a.js // routes for A │ │ │ ├── b.js // routes for B │ │ │ ├── c.js // routes for C │ │ │ ├── index.js │ │ ├── store // Vuex store │ │ ├── utils // utility functions │ │ ├── views // page views for each app │ │ ├── main.js │ │ └── App.vue │ ├── env │ ├── package.json

Application type detection: a global mapping table in main.js sets APPLICATION_TYPE based on the host name. let APPLICATION_TYPE = 'a'; let host = window.location.host; const A_HOST = ['a.com','a_pre.com']; const B_HOST = []; const C_HOST = []; const D_HOST = []; if (A_HOST.includes(host)) { APPLICATION_TYPE = 'a'; } else if (B_HOST.includes(host)) { APPLICATION_TYPE = 'b'; } else if (C_HOST.includes(host)) { APPLICATION_TYPE = 'c'; } else if (D_HOST.includes(host)) { APPLICATION_TYPE = 'd'; } window._APPLICATION_TYPE = APPLICATION_TYPE;

Routing design: environment‑aware routes, separate route lists for each application, and dynamic component prefixing based on APPLICATION_TYPE . let router = [ { path: '/home', component: Layout, meta: { title: '首页', icon: 'el-icon-s-grid', alwaysShow: true }, redirect: '/home', children: [ { path: '/home', component: () => import('@/views/home/index'), name: 'home', meta: { title: '首页', icon: '' } } ] } ];

Environment variable design: separate .env files for mock, development, test, and production, combined with APPLICATION_TYPE to load the correct parameters. # .env.production # a business VUE_APP_A_BASEURL='' # b business VUE_APP_B_BASEURL='' # c business VUE_APP_C_BASEURL='' # d business VUE_APP_D_BASEURL=''

Request encapsulation: common baseHttp.js and business‑specific wrappers (ARequest.js, BRequest.js, etc.). export const createHttp = (baseUrl, successFun = () => {}, errorFun = () => {}, requestInterceptor = () => {}) => { const http = axios.create({ baseURL: baseUrl, timeout: 5 * 60 * 1000, withCredentials: true }); http.interceptors.request.use(async config => { await requestInterceptor(config); return config; }, err => Promise.reject(err)); http.interceptors.response.use(successFun, errorFun); return http; };

Permission and login handling per APPLICATION_TYPE , providing separate login flows for each platform.

Common utilities merging, scaffolding configuration alignment, and Vuex store consolidation to keep module names consistent while merging duplicated modules.

Page reference redesign: direct component import replaces iframe embedding, allowing seamless cross‑application component usage.

After two months of intensive work, the two large projects were deeply integrated, achieving unified code standards, higher component reuse, and a noticeable improvement in user experience.

Conclusion: The systematic fusion of the two front‑end systems demonstrates a practical approach for large‑scale application integration, offering valuable lessons for teams facing similar challenges.

frontendarchitecturedeploymentcode refactoringVueapplication integration
JD Retail Technology
Written by

JD Retail Technology

Official platform of JD Retail Technology, delivering insightful R&D news and a deep look into the lives and work of technologists.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.