背景
前端的發展太快了，前端框架和技術的發展也層出不窮，還包括不同智能設備的出現，對前端開發同學來說是個很大的跳轉，簡單列舉下：
- 前端框架：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的邏輯拆分、具體接口問題定位等。
本文轉載自公衆號閒魚技術（ID：XYtech_Alibaba）。
原文鏈接：