可視化搭建系統之數據源

可視化搭建系統之數據源

https://www.zoo.team/article/visual-construction

背景

接上一篇文章 前端工程實踐之可視化搭建系統（一）鴿了比較久，看過的同學應該也都已經不記得了，也是又看到兩年前文章下熱評一位同學問的問題，兩年後我們換個形式來討論下這個問題 (手動艾特水白泉同學)。

衆所周知，可視化搭建系統是爲了提效，從純人工擼代碼開發需求到拖拖拽拽完成業務需求，大大提高了效率，降低了開發同學的壓力。我司可視化搭建系統魯班也已投入使用兩年有餘，取得的效果也十分顯著，但由於時間的推移，問題也逐漸暴露出來：

如何幫助運營同學提效？如何提高組件複用性同時並降低組件業務耦合度？這就是我們今天要聊的主題，可視化搭建系統中的數據源。

數據源是什麼

從字面上來看，其實就是數據的來源，告訴應用所需要的數據在什麼位置。數據源保證了應用程序與目標數據之間交互的規範和協議，它可以是數據庫，也可以是 Excel 等等。

產品設計

上文介紹了什麼是數據源以及在當前搭建系統中我們遇到的問題，下面我們就從需求入手，先充當起產品的角色，針對需求我們先做問題分析，然後我們再做詳細設計。

問題 1：大量的頁面使用相同組件，運營同學經常需要重複配置一個組件，導致每天要花費了大量的時間去維護頁面

分析：組件中的重複配置，其中以營銷場景以及前臺大廳爲主，這兩塊承載了我司大量的業務場景，其中各個組件的配置複雜且配置項繁多，其中又會出現針對不同的區劃做不同的數據項配置，一旦差異化配置過多，重複配置會不斷變多，維護起來會非常困難。

設計：從組件配置入手，正常業務開發中我們使用接口傳參來獲取差異化的數據，來做動態數據展示以及控制各項配置的開關。可視化搭建中控制配置項的開關我們已經有了，缺的是不是就是一個接口，我們能不能讓組件中的配置也變成一個接口，這樣即使組件數據出現差異性，我們也可以通過入參的不同來下發不同的數據來決定組件應該展示什麼數據。

問題 2：組件中耦合大量的特殊業務接口，導致組件複用性以及擴展性極差

分析：組件由各業務團隊同學自行開發貢獻，開發水平不一導致組件設計不同，有的同學喜歡把接口抽離成組件配置，有的同學又喜歡把接口直接寫在組件內部，兩者都有優缺點我們不做評價，時間久了，使用前者的組件使用難度會很高，一旦維護的同學離職，組件直接就變黑盒了，使用後者的不然，除了當時服務過的需求可以使用這個組件，其他即使視覺層面一致的需求，也由於組件內部耦合的特殊業務接口，讓其他業務團隊寧願重新開發也不敢在用這個組件。兩者最終得到的結果其實都是一樣的，組件複用性降低。

設計：如何提高組件複用性，從上述問題點接口入手，如果我們將可以將接口外置，動態與組件配置對接，也就是組件既可以使用外部接口做配置，也可以使用自己的靜態配置，是不是就可以解決上述問題。

下面是根據上述需求分析設計，產出的 PRD 簡版脈絡：

數據源實現

下面我們根據上述 PRD 脈絡來看數據源的詳細設計。

數據源創建

前面有提到，數據源我們可以使用接口，業務側有後端同學，不用多想，數據源直接用後端同學寫的接口就完事了，但是我們的搭建平臺大多用戶爲運營同學，業務場景基本上都無後端同學投入，這個時候問題就來了：

如何不用開發同學介入創造一個接口來跟組件做綁定呢？我們繼續往下看。

基於內部系統神筆，我們解決了這個問題，神筆是什麼，神筆是個數據投放接口管理平臺，可以讓不懂代碼的業務一樣可以寫接口。神筆中有靜態化這麼一個定義：

**靜態化：**即從 0 到 1 創建一個接口，接口入參以及出參支持自由定義，數據純靜態，可以自定義高級規則來根據入參不同返回不同的數據。

哎，這不就是我們想要的嘛。使用神筆靜態化，業務同學可以基於自己的需求，創造自己的接口來下發不同的數據，自給自足，媽媽再也不用擔心我不會寫接口啦。

數據源關聯

進入組件管理，選擇需要關聯的組件，點擊數據源維護。由於組件業務屬性不同，對應的數據源也會存在差異性，爲了避免運營同學配置數據源時，出現選擇困難症，我們以組件維度關聯數據源，一個組件可以關聯多個數據源，搭配數據源描述，讓運營同學可以最快選到需要的數據源。

新增數據源，目前我們使用最多的數據源多爲 API 類型，也就是我們每天都在瀏覽器裏看到的接口，在新增彈窗內輸入我們已有的接口或者神筆註冊的接口信息，配置好接口地址，請求方式，請求頭，請求參數，以及最重要的接口出參字段與組件數據字段之前的映射關係，輸入完成後就完成了數據源與組件的關聯。

維護接口與組件內部暴露字段的映射關係，輸入框會自動檢測映射關係是否正確。

數據源使用

進入我們需要搭建的頁面，選擇我們已綁定數據源的組件，右側配置面板選擇我們綁定的數據源，保存頁面配置，即可完成在頁面組件中使用數據源。

數據源管理

數據源注入

這一塊我們在搭建側做統一收攏，對一個頁面所有組件選擇使用的數據源做統一處理。

爲什麼這麼做？

  1. 上述提到數據源可以查看被哪些頁面使用，這部分數據便來自於此，在發佈頁面時針對當前頁面所使用的數據源做頁面與數據源的關係落庫。

  2. 當頁面組件數量居多，綁定的數據源也會劇增，這時候接口併發數也會劇增。在這裏無需開發者關心，我們可以統一處理，對全局的數據源請求做限流（引出一道經典面試題：[請用 JS 實現 Ajax 併發請求控制] https://juejin.cn/post/6916317088521027598），以及對重複的數據源過濾，避免重複請求。

其他還有很多優點不再贅述，感興趣的同學歡迎一起討論。

注入流程如下：

  1. 發佈時將當前數據源詳情注入組件 schema

  2. 訪問頁面時，針對當前頁面所有組件，過濾使用了數據源的組件

  3. 數據源去重，標記重複項

  4. 去重後的數據源併發請求數據，請求池控制併發數，最大併發 10

  5. 數據源返回結果後，根據各組件 schema 內存儲的數據源信息中的組件字段與數據源字段的映射關係做數據映射

  6. 最後通過組件的 props 統一注入（爲啥用 props ？請看我們上一篇：魯班核心代碼 (https://juejin.cn/post/6844903950508883982#heading-21)），最後完成整個頁面的數據源注入及渲染。

流程圖如下：

總結

數據源是搭建系統建設過程中重要的一環，爲提效再進一步，他不僅降低了頁面的重複搭建，還收攏了差異化配置的入口，並且讓運營同學可以做一些研發同學纔可以做的事：接口創建、引用、發佈等。以上是我個人對搭建系統中數據源的一些總結，後續還會繼續分享數據投放相關，如有錯誤，勞煩指正修改，感謝各位能看到這裏。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/rEUowonQhot0mkzDPD1ZvQ

猜你喜歡