攜程 Foxpage 前端低代碼框架

Jason Wang，攜程研發經理，目前主要負責低代碼類產品的設計和研發，關注低代碼行業的發展及相關解決方案在企業內部的落地。

一、背景

隨着低代碼開發方式被越來越多的人接受和認可，低代碼得到了蓬勃發展，更被寄希望成爲 IT 行業革命性的 “新生產力”。據報道，全球低代碼類產品市場規模在 2021 年超百億美元，預計 2023 年將突破兩百億美元關口。

1.1 低代碼行業現狀

國外：Salesforece，Microsoft，OutSystems，Mendix 等，是處於領導者地位的資深玩家，產品功能強大，流程完善，生態健全。

國內： 釘釘宜搭，明道雲，織信，奧哲，簡道雲等，大都結合某個場景提供支持方案，還處於發展階段。

還有些玩家在企業內部發展，並未公開。各類玩家各有優勢，關注的方向也各有差異。有的是結合某個行業定製，有的是結合單個使用場景深耕，還有的執着於提供應用開發的完整低代碼方案。大部分是 SaaS 產品，其中部分會有私有化部署方案。

1.2 暗藏的隱患

按理說，市場上低代碼產品功能已經足夠強大，企業內部還在自研，甚至同一個業務線的不同使用場景或不同的技術棧也都有不同的低碼類實現方案。據說某大廠內部的低代碼類系統或工具高達上百個。

其實這些系統或工具前端部分的核心功能和能力大體是相似的，就拿前端可視化頁面搭建這部分來講，從技術上看大家最終的實現方案和體驗上都趨於相近或相同，自研的整個過程會有大量的重複性的工作，造成了人力資源的浪費。

爲什麼會造成這樣的局面？大家的本意是想借助低代碼方案解決業務問題，但卻發現行業基建太差，藉助成品的方案也難以落地。只能一遍遍重複着低代碼的基礎能力和設施的建設，樂此不疲也無奈地重複造輪子。

1.3 低碼通用能力建設

基於此我們做了一些調研，整理了市面上成熟產品可能存在的問題：

既然大而全的低碼產品不能用，那就給個小而美的低碼框架吧。

爲了能讓前端項目快速且低成本的體驗到低代碼帶來的便利，帶着市面上成熟的產品的問題，我們決定從建設前端低代碼開發平臺的角度去研發一套前端低代碼框架，提供前端低代碼類產品的通用部分能力，幫助開發者解決重複開發，重複建設的問題。

同時也設立了一些需要完成的目標：

二、Foxpage 是什麼？

Foxpage 是一個輕量級的前端低代碼框架，藉助 Foxpage 可以讓前端項目用低代碼的方式進行迭代。Foxpage 重點在前端，關注前端頁面的整個生命週期，希望成爲一個易用，靈活，開放且百搭的開源框架。

特性

國際化和平臺化爲以後建設通用的前端低代碼開發平臺提供了基礎。

三、架構

3.1 整體架構

整個框架包含 Foxpage Admin，Foxpage API，Foxpage SDK，組件庫等部分，下圖描述了框架各模塊及它們之間的關係。

3.2 Node SDK 架構

Node SDK 是提供給 node 端應用使用的開發工具包，通過 SDK 開發者能夠快速接入和使用 Foxpage 框架。

除了上面的介紹，Foxpage 整個項目還有 Foxpage CLI、Foxpage Debugger 及組件部分相關的介紹，有興趣的同學可以前往官方文檔查看。

3.3 核芯設計

Foxpage 核心部分是圍繞着 Foxpage 需要提供支持多場景，多端，多技術棧的能力來設計的，可以算是對低代碼開發實踐的沉澱。

DSL（Domain Specific Language）

DSL 譯爲領域特定語言，作用是通過在表達能力上做的妥協來換取在某一特定領域的高效的。最常見的 DSL 有 Html，CSS，SQL，Regex 等。

爲了各類內容編輯高效性和一致性，我們基於 JSON 設計了一套 Foxpage 的 DSL，主要用作描述頁面和組件等內容。再結合自身需求做了一些擴展，如爲了加強 DSL 的動態能力加入了 “變量”，“條件” 等描述。特定的語法和語義需要提供對應的解析器，結合不同的應用場景提供定製功能，再針對具體的端提供對應 SDK 實現供應用接入。

頁面 DSL 的片段

上圖 DSL 中描述了一個橫幅組件，包含資源，屬性，事件，條件渲染等信息，當然完整的頁面描述還包含模板，頁面，資源詳情等描述。爲了減少 DSL 的冗餘，我們對公共部分做了最大程度的提取和複用。同時爲了防止單份 DSL 內容過大，還支持了 DSL 模塊化設計。運行時在 DSL 解析時會做合併，補全等操作。

無頭 CMS（Headless CMS）

無頭 CMS 與傳統的 CMS 相比，不同之處在於其將內容和展示分離，達到 “前後端分離” 的目的，這樣可以和前端的技術棧解耦，增強擴展性。

這裏主要提供了各類內容的定義、管理、存儲和分發等功能，其實就是管理着各類 DSL 數據，視爲框架的基建部分。參照文件系統的設計，提供了文件夾和文件等基礎的功能。並可自由的新增文件類型，讓整個系統變得更自由，更易擴展。同時還提供了 Restful API 方便了各端可以自由的獲取到託管的內容，也使得各接入端擁有了動態更新能力。

這樣的設計也爲前端項目想離線的使用 Foxpage 框架提供了基礎，後續 Foxpage 也會爲應用提供離線使用方案，使得整個框架變得更靈活。

解釋器（Interpreter）

這裏解釋器的作用，是在應用的運行過程中去讀懂並理解 DSL 然後再做對應的執行。廣義上來說解釋器主要包含資源管理器，DSL 解析器，渲染引擎三個部分

可以簡單看下解釋器在 H5 頁面渲染過程中所做的工作：

這種解釋執行的方式會帶來一定的性能損耗，但是和它帶來的高擴展能力和動態能力來比還是可以接受的。整個低代碼的開發方式，本身也是犧牲一定的靈活性來換取開發效率的提升的，這要看怎麼平衡和取捨。

3.4 如何工作？

舉個郵件頁面渲染服務（SSR API 以下簡稱 API）的例子來說明下工作過程。

首先 API 項目需要接入 Foxpage Node SDK（以下簡稱 SDK）。當用戶請求 API 獲取郵件頁面 HTML 文檔時，SDK 會請求 Foxpage Restful API 獲取郵件頁面的內容信息（DSL），拿到頁面 DSL 後會走解析流程，做一些預處理、數據綁定及資源文件加載（比如組件的 umd 文件）等工作。解析完成後 SDK 會根據解析後的對象做頁面的構建和渲染（SDK 默認內置 Reactjs 框架，這裏的郵件頁面組件爲 React 實現的），最終調用 Reactjs 框架的接口輸出頁面的 HTML 內容。

四、Why Foxpage？

以下是 Foxpage 的技術目標，這也是框架核心的能力，降低成本同時提高生產力。

目前前端開發還是一個 “勞動密集型行業”，需要大量的開發資源堆疊去解決業務需求。雖然有了一些工程化的加持，但在面對成倍的開發需求增長時，效率和成本問題會凸顯並放大。Foxpage 的出現可以一定程度上緩解這一問題，讓前端開發多一種選擇。

4.1 低碼****開發模式

開發從 “pro code” 到 “low code” 的轉變。拿前端頁面開發舉例（爲方便理解，結合製造業流程來說明），傳統的開發方式是在線下製作組裝，經過一系列工序後發佈到線上交付。而低碼的方式是在線可視化搭建頁面，然後產出一張張施工圖紙，在交給生產線做線上的自動化組裝，最後線上交付。

這種變化帶來的益處：

4.2 工程化的支持

從傳統前端的工程化轉變爲圍繞着低代碼開發建設的新的工程化體系。不管是新的還是傳統的工程化，最終目的都是爲了高效且低成本的開發並保質保量的交付。低碼的開發模式中同樣需要一些工程化的支持，只是會換成另外一種形式而已。

框架提供的基礎能力：

Foxpage 作爲一款前端低代碼的基建產品，會持續的探索圍繞着低代碼開發的工程化體系，給低代碼開發帶來更好的體驗。

4.3 工作流的改變

讓各個職能可以在線合作，改變了傳統線性接力式的工作流程，減少了各職能之間不必要的依賴，縮短開發工期。有人用遊戲中的 “圓桌範式” 來形容這種工作關係。我覺得有點像 “手術檯” 的形式，這種形式更強調合作。

作爲框架會有約束，但更多的是支撐。在享受低代碼帶來益處的同時也要適應它帶來的一些變化及約束。

五、組件化

組件是低代碼類產品非常重要的部分，可以說組件化的結果會直接影響項目低代碼開發的體驗。

Foxpage 作爲前端低代碼框架，理論上是不涉及到業務部分的。開發者需要站在整個項目角度結合業務去考慮怎麼組件化，如哪些模塊需要組件化來降低重複開發的成本，哪些不適合組件化；組件的主體內容是靜態數據，還是通過請求接口獲取的動態數據；組件數據部分的複雜邏輯是否可以交給後端；哪些信息根據具體的業務是要做成可配置的會更靈活。

組件的粒度粗細怎麼控制？粒度越細可能越靈活，但是組合起來可視化搭建過程中就會越複雜，增加使用成本。如果做的過粗，複用度就會降低，增加開發成本等。開發者需要結合自身業務綜合地去考慮這些問題。

5.1 提供的支持

當開發者按照自己的設計去完成組件化落地時，Foxpage 會提供一些支持。包括組件開發的腳手架，可視化調試，本地構建等工具及經過大量實踐後整理出的一些相對完善的流程。

我們關注組件化落地過程中整條鏈路上的開發和使用體驗，從組件的定義，開發實現，調試，測試，部署，註冊，可視化配置使用及效果分析。同時也會提供一些自己的實踐供開發者參考。

當然在對組件化做支持的過程中，會有一些原則：

除了用戶需要爲自身業務實現的組件外，Foxpage 會提供一些基礎且比較通用的組件，同時還會結合行業比較流行的 UI 庫做一些組件化實踐，提供給用戶多樣的選擇。

5.2 不提供的支持

Foxpage 不提供組件項目靜態資源存儲、部署及 CDN 內容分發相關的功能。對於靜態資源存儲，開發者可以按照自身的情況來選擇通過雲服務自建或者使用第三方託管服務。Foxpage 也不提供組件項目的 CI/CD 相關的功能，因爲 Foxpage 本身沒有對應的構建和部署環境。開發者可以藉助市面上成熟的工具或服務來完成 CI/CD，整個過程 Foxpage 不會介入。當然作爲低代碼配套基建的重要部分，我們未來也會去提供這部分的實踐。

六、擴展性

擴展能力是 Foxpage 框架最重要的能力之一，主要體現在對多場景，多技術棧，多端等的支持上。

在瞭解擴展能力之前，我們再回過頭看看 Foxpage 的 DSL 部分。DSL 本身除了用作描述之外沒有承擔任何其他的職責，實體是一份 JSON 格式的數據。技術上不涉及到任何的編程語言，框架，運行環境等。它的能力會體現在對應的場景的具體實現上。

拿建築行業舉例來說 DSL 就好比施工圖紙，它是一門工程語言，建築工人可以根據施工圖紙在不同的環境和地點，選用不同的建築材料搭建出建築物。也正是因爲如此才使得框架有了支持多場景，多技術棧，多端的可能。

那擴展能力具體是怎麼體現出來的呢？我們可以先從 DSL 的視角，通過對 Web 頁面的製作和渲染這個過程的簡單剖析，看下 Foxpage 是怎麼運作的，其中涉及到擴展的幾個關鍵點已標註。

注 1：DSL 部分可以隨意的擴展，只要提供對應 DSL 的解析器即可。

注 2：Foxpage Node SDK 內置 Reactjs 框架，主要負責頁面的構建和渲染。如果想用其他的前端框架，可以提供 SDK 中對應的渲染引擎部分的實現即可。理論上可以選用任何你想用的前端框架，這是對多前端技術棧的支持能力的體現，當然要做到多技術棧支持還有其他工作需要做，如可視化，客戶端渲染等環節也要有對應技術棧支持。框架後面也會提供對 Vuejs 的支持。

注 3：對多端，多場景的支持，Foxpage 提供了對服務端的 Node SDK 和瀏覽器端的 JS SDK 的實現。不同端的實現會有差異，但大體都包含資源管理，DSL 解析器，渲染引擎。其核心架構中的無頭 CMS 的設計，使得整個框架擁有了更強的擴展性。針對不同的端或場景可以提供對應的的實現。具體可以參考文檔進階之路頻道中 Node SDK 實現部分。

注 4：我們在 DSL 的解析，頁面的構建及渲染的過程中預置了鉤子並暴露出了很多鉤子函數（圖中的只是一部分例子），結合框架提供的插件機制，開發者可以很方便的介入到整個運行過程中去，結合業務需求做一些定製，這樣大大提高了可擴展性。

從上圖的運行的過程中看，整個框架都是圍繞着 DSL 來建設的，可以這麼說 DSL 的描述能力有多強，框架擴展的能力就有多強。

七、可視化搭建

可視化積木式的搭建其實是網頁低代碼開發的一個很基礎的能力，Foxpage 也提供了相應的功能，與其他同類的產品不同的地方是我們提供了好幾種可視化編輯器，有針對富文本類的，Markdown 類的，有頁面類的，有畫圖類的等等，根據不同的要編輯的內容的類型可以選擇對應的編輯器。

這一部分我們也預留了常用的接口，甚至可以開放給用戶定製內容編輯器，這也是 Foxpage 支持多場景能力的體現。當前 Foxpage 內置的只有針對網頁內容的可視化編輯器，後續會考慮繼續開發其他類型的內容編輯器。

可視化能力不僅體現在編輯的過程，還會在一些如歷史版本快照，組件在線預覽，頁面點擊曝光埋點等功能上有所體現。目前可視化核心部分已經組件化，這樣可以給任何其他需要可視化功能的模塊帶來便利的，一致的可視化體驗。

八、平臺化

Foxpage 提供支持多應用的開發和管理，是 SaaS 產品的一種 “多租戶” 的模式，在面對多個前端項目要使用 Foxpage 框架時，無需部署多套服務。同時爲了各個應用之間的信息流通分享，還提供了商店模式，通過商店可以上架應用，頁面模板，組件，變量等內容，從而大大的提高的各類內容的複用度。

開發者在完成一個前端項目低代碼框架接入工作後，可以將自己項目的應用上架商店，通過這種方式開放自己應用的前端低代碼開發權限，這個時候其他使用低代碼開發的用戶（可以是編輯，運營或開發者，以下簡稱用戶）也可以在你的應用上做低代碼開發。

這個過程中開發者變成了提供某一個項目的低代碼開發的服務者，開發者接入低碼框架後讓項目擁有了低代碼開發的能力，通過平臺將這種能力賦予用戶，這個過程中開發者相對於用戶來說變成了服務方。

開發者還可以專門開發組件，提交到商店後供其他的開發者在自己的應用中使用。使用低碼開發的用戶可以將自己開發的作品，如搭建的 xxx 頁面上架到商店供其他用戶克隆使用等等。

Foxpage 爲各種角色提供了一個在線合作的平臺，同時提供在線協作能力，提高各個角色之間的合作效率。

九、項目實踐

Foxpage 已經在 Trip.com 內部多個項目中使用，且已經穩定運行多年。這裏結合幾個有特點的項目來介紹下項目實踐，這些項目本身的頁面數非常多且結構各異，頁面內容變更非常頻繁。應用也都是 MPA（Multi-page applicaiton）多入口應用，業務需求決定需要支持多種渲染模式 SSR，CSR，SSG。

其實每一個項目的低代碼實踐，不僅僅只是解決單個項目的問題，而是解決了這一類項目的問題。下面三個實踐都各有特點，在實踐的過程中也遇到了各種問題，特別是在對組件化的支持上和不同系統之間的對接上，總之就是框架結合具體業務場景落地上還有各自的路要走。這裏不做詳細介紹只簡單讓大家對 Foxpage 的使用場景有個直觀的感受。

9.1 促銷頁面

爲了營銷需求而搭建的落地頁面，有各種各樣的玩法，主要有產品促銷，好友拉新，秒殺，抽獎等活動。

需求特點：

接入 Foxpage 後：

案例：Trip.com Eventsale 系統

簡介：Eventsale 系統是 Trip.com 的活動配置系統，包含活動的基礎信息，促銷信息，玩法信息，活動頁信息等配置。其中頁面搭建能力由 Foxpage 提供。

現狀：截至 2021 年中爲止，大約有數千張的活動頁面通過活動配置系統製作完成。

9.2 SEO 頁面

爲了搜索引擎優化提供的一些頁面。大部分頁面的主體內容都是動態生成的，不同的關鍵詞頁面的結構和內容都不一樣。頁面模塊需要有一定的動態性，會根據模塊點擊和曝光動態排序以及控制是否展示。

接入 Foxpage 後：

案例：Trip.com SEO 管理平臺

簡介：SEO 管理平臺管理着 Trip.com Hot 頻道的內容，包括關鍵詞管理，頁面 TDK 信息，結構信息，內容等。其中頁面搭建能力由 Foxpage 提供。

現狀：截至 2021 年中爲止，SEO 平臺目前由 Foxpage 框架生成的頁面大概有 百萬級的頁面，頁面部分的主要模塊都是通過算法動態生成。

9.3 郵件頁面

在郵件頁面發送這個場景中，傳統的方式是前端切圖，將 HTML 交付給到後端，後端再結合模版引擎做數據綁定，然後調用發送渠道發送。這個過程中前後端沒有分離，前後端合作低效。結合 Foxpage 方案後很好地解決了痛點。

案例：Trip.com MessageHub 系統

簡介：MessageHub 系統是 Trip.com 觸達用戶的消息系統，包含短信，郵件，站內信等內容的管理和發送。其中郵件頁面搭建能力由 Foxpage 提供。

現狀：截至 2021 年中爲止，通過郵件配置系統製作的各類郵件頁面大約數千張左右， SSR 服務平均每天調用量在幾百萬次，靜態頁面渲染耗時 99 線在 60ms 左右。

9.4 更多的前端使用場景

適用的場景除了我們已經實踐過的其實還有很多，大家可以繼續探索。

9.5 不適用的場景

主要是從體驗和使用成本角度總結出以下不適用場景：

兩個需要用戶注意的事項：

低代碼雖好卻並非適合所有的項目，根據實際情況謹慎使用。

十、未來規劃

目前 Foxpage 低代碼框架才完成基礎部分的功能開發，離一個成熟完善的低碼框架還有很長的路要走，2022 年我們將從以下幾個方面梳理規劃：

10.1 框架迭代

1）版本 1.0（2022 H1）：提供低代碼開發所需的基礎功能，將於上半年發佈 1.0 版本

2）版本 1.x（2022 Q2）：提供對國際化，系統權限，Debugger 工具，自定義組件等的支持

3）版本 2.0（2022 Q4）：對 Foxpage Admin UI 改造，重點會在交互部分，視覺部分也會升級，同時做功能上的簡化和流程上的優化

4）版本 2.x：提供對系統集成，Serverless 方案，頁面數據分析等的支持

10.2 場景拓展

除了網頁製作部分已有的使用場景，還會探索圖片生成，主要會在海報製作方向

10.3 配套建設

1）組件：

2）靜態資源服務：結合雲服務的對象存儲服務，提供靜態資源服務建設的最佳實踐

3）託管服務：結合雲服務提供 SaaS 產品

深入瞭解

如果你想更深入的瞭解 Foxpage，可以移步至項目文檔，同時推薦下面幾篇文章供閱讀：

Foxpage 在 Node 應用中的落地實踐

Foxpage 低碼下的組件化實踐（一）

Foxpage Node SDK 資源管理 

Foxpage Node SDK 插件化

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

猜你喜歡