看了兩個個知乎的回答, 自己總結下.
大公司里怎樣開發和部署前端代碼？回答一
- 非覆蓋發布:
- 文件的摘要信息放到資源文件發布路徑中, 這樣內容有修改的文件變成了一個全新的文件, 不會覆蓋之前的文件
- 先全量部署靜態資源, 再灰度部署頁面.
大公司里怎樣開發和部署前端代碼？回答二
回答二: 簡單情況下的發布方式
- 前提: 前后端發布分離
- 前端渲染, 不考慮SSR和BFF服務的發布, 只考慮頁面發布.
- 簡單場景下: 可以使用中間托管服務FE getaway方式, 網站入口和所有配置, 主要功能如下:
- 頁面管理: 提供可用的URL
- 模板托管: 管理后端模板
- 遍歷管理: 后端模板里各種變量的值, 也包括前端資源版本號
- 三種合並到一起, 就是一個完整的html
- 該情況下的發布流程:
- 前端首先打包靜態資源, 使用非覆蓋發布方式, 發布到CDN
- 靜態資源的URL中含有版本號
- 在變量管理中將要發布的模板版本號改為最新即可
- 好處: 前端頁面切割成各個工程, 互不影響
- 壞處: 版本稀碎, 不易管理
回答二: 在先發布方式下的打包方式
- 頁面工程(js, css, img)和第三方庫, 放到CDN上面.
- 公共庫: 全局使用或者高頻使用的的組件和基礎庫代碼打包成為bundle單獨放到CDN上
- 不一定是一個bundle, 可以組件一個, 非組件一個
- 公共庫, 使用webpack的external引向全局變量
- 好處一: 項目之間的復用, 使用code split不能搞定
- 好處二: 公共庫的版本號便於管理, 公共庫升級所有頁面開發人員進行適配.
- 組件庫, 基礎庫使用npm發布
- 構建頁面的時候, 局部使用的組件和庫, 使用npm install引入, 進行常規
大前端時代下的微前端架構
微前端是一種架構風格, 其中眾多獨立交付的前端應用組合成一個大型整體
通讀文章后, 我認為微前端的方式需要再議. 並一定適合現在的需求
遺留問題
- BFF服務是什么