閑魚前端基於 serverless 的一種多端開發解決方案

2019 年 11 月 25 日
筆記

背景

前端的發展太快了，前端框架和技術的發展也層出不窮，還包括不同智慧設備的出現，對前端開發同學來說是個很大的跳轉，簡單列舉下：

前端框架：vue、react、angular
小程式：微信小程式、支付寶小程式、字節跳動小程式
智慧設備：蘋果設備、天貓精靈、小度

這樣就滋生了一些問題，比如我要開發一個通用的頁面，兼容不同的端側和小程式，顯然目前是做不到的，我們只能開發多套頁面去適配不同的場景，這樣的話成本就太高了。

很多同學都在嘗試解決這個問題，也催生了類似 taro 這樣的多端統一開發框架，這是一個好的解決方案，但是比較被動，缺乏一定的擴展性。

這篇文章我們要探討的是，看能不能換個角度去解決這個問題，提升開發效率。

ViewModel

當我們在開發一個頁面的時候，不管用的是哪一種框架，通常都會抽象出一層 viewmodel 層，它主要有 2 個作用

和服務端進行交互，接受後台返回的數據，進行加工並傳遞給 view 層渲染
接受 view 層的回調，加工數據並返回給 view 層渲染

從上圖中我們可以看出，viewmodel 是一段獨立的通用程式碼邏輯，起到了承前啟後的作用。它和 view 層關係更加緊密，因此通常會放在前端測。

既然 viewmodel 是獨立的，那我們能不能把它放在後端呢？這樣一個最大的好處就是 viewmodel 可以進行復用，不需要在重複編寫，而且只需要改動一個 viewmodel，就可以全量生效。

似乎是一個很美好的想法，但是這部分程式碼由誰去開發呢，總不可能寄希望於後端同學吧，當然只能是我們自己，也感謝於 serverless 架構的出現，讓這件事情變成了可能。

有些同學可能會問，既然 viewmodel 後移了，那 view 呢？後續會考慮結合我們的 ui2code 技術，那真的就比較完美了。

什麼是 serverless

我們先簡單介紹一下什麼是 serverless，serverless 的基礎是雲技術，它是雲技術發展到一定階段而出現的一種革命性的高端架構。serverless 並不是說不需要伺服器，而是指不需要開發者去關心底層伺服器的狀態、資源和擴容等，開發者只需要關注於業務邏輯實現。

架構上，我們可以把 serverless 分為 FaaS 和 BaaS。

FaaS 是用於創建、運行、管理函數服務的計算平台，它支援多種開發語言，比如 java、nodejs、dart 等，這有利於不同端側的開發同學介入開發。FaaS 是基於事件驅動的思想，只有當一個函數被事件觸發時才會佔用伺服器資源執行，不然都是無需佔用伺服器資源的。

BaaS 提供了用於函數調用的第三方基礎服務，比如身份校驗、日誌、資料庫等，它是由服務商直接提供，開發者無需關係實現，直接調用即可。

業務落地

我們是通過 gaia 平台開發後端介面，gaia 可以理解為上文提到的 FaaS 平台。

日常開發中有這樣一個需求，下面是這個需求的一個頁面。

因為這個頁面上的數據比較多，先把它切分成一個個小的模組，後台返回數據的時候也根據模組來返回數據。

我們是根據 viewmodel 來設計介面，首先肯定有一個首屏數據介面；然後是頁面上的交互，比如切換卡片、切換芝麻信用按鈕，切換會引起頁面數據變化，我們可以統一封裝一個頁面更新的介面；最後是一個開通的介面。

後端介面

前後端交互最重要的數據結構的設計，我們省略了中間的業務邏輯處理，看下介面的數據結構。

首屏介面返回的數據主要有幾個特徵：

根據前端的頁面模組定義返回結構
欄位的顆粒度很細，頁面上的每個元素都對應一個欄位值
有兩個欄位來控制模組的顯示和刷新

更新介面的返回數據結構和首屏介面類似，但是入參有所不同，主要包括 2 個欄位：

data：當前頁面的數據，為了避免數據的重複獲取
action: 定義的頁面操作

前端處理

從後端返回的數據可以看到，數據是及其詳細的，無需我們做任何的業務邏輯處理，直接映射到頁面即可。這樣，前端已經變成了很薄的一層數據，沒有任務的業務邏輯處理，變的很簡單，當需要遷移到其他端時，只需要遷移視圖層即可。當有任何的業務變動時，只需要修改後端的介面，就能生效。

收益與總結

通過具體的實踐，我們發現，對於前端開發同學來說，變的簡單了，開發效率有很大的提升，前端同學甚至都不需要去理解具體的業務邏輯，就能完成頁面的開發。而且，提取的 viewmodel 可以復用到不同的端側，設置還包括 native 端。我們還可以將 viewmodel 拆分成更小粒度的 viewmodel，方便在不同的頁面介面中進行復用。我們有同學還在 FaaS 側基於 redux 的思想封裝了一個通用的狀態管理框架，規範了前後端的交互。

後面，還有一些問題待我們去解決，比如開發成本、viewmodel 的邏輯拆分、具體介面問題定位等。