GrowingIO 智能运营产品微前端实践

作者：俞展弘 GrowingIO 前端开发工程师，主要负责智能运营团队前端开发、gio-design 开发

引言

GrowingIO 智能运营产品，是 GrowingIO 为客户运营团队提供的一站式、精细化运营管理与数据分析平台。

近期，GrowingIO 智能运营产品团队需要将站内触点等运营功能从 SaaS 平台移植到增长平台上，以支持私有化部署（On-Premise，简称 OP）方案在客户环境中的进行，以此为背景，GrowingIO 运营前端团队在微前端的实践上走了自己小小的一步。

1. 什么是微前端

虽然「微前端」三个字这两年已经在前端领域被大家所广泛熟知，但本着严谨写文章的精神还是需要在这里简单说明一下。

微前端的概念脱胎于服务端的「微服务」概念。最近几年前端世界的趋势就是构建一个功能丰富、强大的浏览器应用程序（SPA）。

一般一个前端应用通常会由多个独立的团队开发，随着时间的推移，前端应用的代码规模会不断增长，并且表现得越来越难以维护，成为一个谁看都头疼的巨石应用。

微前端出现的意义在于将这样一个单一的巨石应用，转换为多个较为小型的前端应用再聚合为一。各个小型应用可以独立开发、部署，乃至于独立选择自身的技术栈与依赖，而不影响其他兄弟应用与父应用。

在此基础上简单总结一下微前端需要做到（或者说带来的好处）：

• 应用自治：只需要遵循统一的接口规范或者框架，各个应用可以集成到一起，同时相互之间是不存在依赖关系的。
• 单一职责：每个前端应用可以只关注于自己所需要完成的功能。
• 技术栈无关：可以在使用 Angular 的同时，又可以使用 React 和 Vue。

2. 为什么要拆分微前端

如同上一段所说，目前的 GrowingIO SaaS 主站前端应用也是一个伴随迭代变得越来越大的巨石应用，但对于运营的前端团队来说，除了公共方法平时不会触及到大多数不相关模块。

其次，在当前以及可预见的未来，在 SaaS 环境与 OP 环境中运营的业务场景在大部分情况下是相同的。但是对于前端团队来说，OP 与 SaaS 差别包括但不限于：

• 采用了全新脚手架
• 用 GraphQL 取代了 RESTful API 获取基础资源 基础组件版本与路由
• 基础设施与 SaaS 有破坏性更新
• OP 不需要全部的 SaaS 功能

如果采取最原始暴力的开发方式（copy），就需要开发维护两套运营平台前端代码，一套在