淺談業務中臺前端設計

做前端中臺業務一年多的時間，有一些心得體會，和大家分享分享。

• 中臺是什麼
• 中臺業務的價值是什麼
• 做了哪些前端中臺業務
• 如何設計前端中臺業務
• 未來展望

中臺是什麼

百度百科的解釋比較言簡意賅：“中臺，網際網路術語，一般應用於大型企業。一般是指搭建一個靈活快速應對變化的架構，快速實現前端提的需求，避免重複建設，達到提高工作效率目的。”
當公司發展到一定規模，就需要建設中臺團隊來提高工作效率。
在前後端分離的協作模式下，會分為後端中臺、前端中臺。
對於前端中臺來講，常見的有BFF中臺、業務中臺等等。
我今天要分享的，主要是業務中臺的一些經驗。

中臺業務的價值是什麼

中臺業務的大背景，誕生於“降本增效”的大號角下。
無論公司大小，無論業績如何，“降本增效”一直都是一個不變的、可以挖掘的話題。
企業需要盈利，除去增加利潤之外，經營成本也是需要考慮的重要部分。而人力成本或者說協作成本作為經營成本的重要組成，投入一定的時間和經歷，產出服務或者工具，從而降低成本

做了哪些前端中臺業務

大致列舉一下。

• 低程式碼載入器（xxx官網接低程式碼平臺前端技術方案）
• 統一登入頁（xxx賬號統一過渡頁業務線對接）
• webComponents（webComponents版本管理方案設計）
• 微應用（微應用主子應用通訊設計、微應用前端按配置渲染）
• 閘道器外掛（xxx與yyy免登、zzz ISV最佳化對接文件）

光看業務可能比較模糊，下面來談談技術實現細節。

如何設計前端中臺業務

關於如何設計前端業務，我覺得主要有幾個方面需要考慮

• 通用性儘可能強
• 使用方接入儘可能簡單
• 文件儘可能詳細、更新及時
• 接入前自測並充分相信接入方

通用性儘可能強

通用性強其實有一個非常大的前提：前端技術棧統一、前端基建完善（比如前端閘道器、前端釋出平臺）。
得益於TUYA前端技術棧統一為基於next.js的React技術棧，以及完善的前端基建，通用性強這一點有著先天的不用考慮相容性的優勢，只需要考慮“業務通用”即可。
例如在xxx業務線，有業務線A、業務線B、業務線C、業務線D、業務線E等等業務線。
在開發中臺業務時，主要需要考慮：技術方案在各個業務線是否通用？

舉例來說：

• 前端元件如何既相容UI框架 v3，又相容UI框架v4
• 閘道器外掛是否既支援協議A，又支援協議B
• 若專案以微應用子應用方式下沉，主應用是否具備接入能力
• 微應用前端按配置渲染，context方式可以無感注入到hook及元件

使用方接入儘可能簡單

前端中臺設計，面向的是業務線各團隊的前端提供服務。
如何讓“使用方接入儘可能簡單”，這個可謂是非常重要。

舉例來說

• 低程式碼載入器接入：遇到next版本不一問題，需要一一統一。只有統一後，才能統一使用npm包接入
• 統一登入頁：資料儲存localStorage、配置代理即可
• webComponents：初期以script指令碼連結接入、後期最佳化為指令碼實時接入和更新；元件功能儘可能收斂，減少接入方工作量
• 微應用：主子應用統一通訊方式為foo，提供統一子應用獲取應用資訊npm包
• 閘道器外掛：儘可能將邏輯收斂到閘道器外掛內部，例如登入態獲取、api呼叫、redirect等等

文件儘可能詳細、更新及時

一份清晰、易用的文件非常重要。
可以幫助接入方更快速的接入，可以節約很多溝通時間。
如果鏈路較為複雜，儘可能提供一份清晰的鏈路圖（推薦使用mermaid繪製鏈路圖）。

文件主要考慮幾個方面

• api / props 說明
• 清晰的demo
• 文字少一點，一圖勝千言
• 鏈路圖、架構圖、原理圖
• changelog（如果更新非常頻繁的話）
• 容易踩坑的一些友好提醒備註

接入前自測並充分相信接入方

在做前端中臺初期，公共模組開發完成後，我會直接在業務線的專案中，做一次接入測試，確保鏈路可通、服務可用。
當服務在第一條業務線接入成功，並且線上上成功執行時，功能可用性已達成。
當有第二條業務線接入時，雖然接入方對鏈路不清楚，但是作為服務提供方，已經有了自測以及第一條業務線的接入，需要充分相信對方，輔助接入即可

未來展望

除去上述的很多方法論或者說經驗之外，想要做好業務中臺前端設計，還有很多事需要做：

• 增強服務意識和溝通能力
• 擁抱新技術、拓寬技術棧
• 提升程式碼通用性、內聚性