01 寫作背景

在低代碼平臺建設項目中，最核心最關鍵是對“應用”的理解和抽象。好比你要建設一個生產工廠，總得先把你要生產的產品設計好。但是在對應用理解和抽象時，產品團隊產生了一個很關鍵的分歧“低代碼應用是否需要強制劃分出前后端兩類服務”。一方的觀點是服務（服務是一個獨立部署單位，一個應用可以有多個服務組成）只要有“頁面、接口、邏輯、數據”這四類設計對象就可以了；另一方的觀點是不僅要有這四類對象，而且服務要劃分出前端和后端兩種類型。以下是個人對這個問題的一些思考和總結，歡迎點評和指正。

02 web應用兩種基本的解構方式

1、前端、后端

這種解構方式下，一個完整低代碼應用中，用戶都至少會看到“前端”“后端”兩個服務。這其實是一種程序員視角下的web應用解構方式，體現的是一種實現層面的思維。

2、頁面、接口、邏輯、數據，(流程、認證與權限)

這是一種非程序員思維下較為直觀的web應用的解構方式（“流程、認證與權限”包含領域拆解思維，不過這不是今天文章探討的問題，后面有空再單獨討論）。這種拆解方式能更加直觀體現出應用設計的思維。

03 第一項建議：在設計層面低代碼應用不需要劃分出前后端兩類服務

1.從用戶的角度，要從目標客戶群的認知出發

低代碼平臺的最終目標客戶是是非專業程序員、非程序員，因此從降低目標用戶認知成本的角度考慮，不應該出現“前端服務”、“后端服務”這兩個實現層面的概念；
“頁面、接口、邏輯、數據，（流程、認證與權限）”更貼近非程序員對應用設計的直觀理解，可以降低用戶認知和學習難度。這對一個想覆蓋更多人群來贏得市場的低代碼產品來說至關重要。而且這種方式能夠實現“用戶理解和操作”、“應用設計和實現”在用戶認知的層面上保持一致。

2.從低代碼應用設計的角度，要真正理解應用設計和實現的差異

1）從設計DSL的目的說起

完整的抽象低代碼應用
保證應用抽象具有靈活可復用性
保證應用抽象有足夠的可擴展性
保證低代碼平臺本身架構穩定性

因此基于以上四點我們在可視化編輯器到交付物之間設計了一層DSL（由于應用本身橫跨多領域，因此低代碼DSL會有多項子DSL構成，比如流程由BPMN2.0協議表示、接口定義由swagger表示等等，不過這不是今天文章討論的重點，后面有空再單獨討論）。

2）DSL的核心功能主要是兩項：

把可視化設計轉變為DSL腳本（把抽象概念映射成dsl的結構和對象的能力）—>（應用設計）
把DSL腳本解釋（實現）成源碼、制品及部署（把dsl結構和對象解釋成GPL的能力）—>（應用實現）

3）兩個核心觀點（劃重點）：

良好的DSL設計，在應用設計階段，支持用戶表達意圖的方式越簡單越好、對表達的約束越少越好。按照這個原則，在低代碼的例子中，在應用設計階段，首先DSL腳本中只應該出現“頁面、接口、數據、邏輯，（流程、認證與權限）”等概念，不應該出現“前、后端服務”的概念，這對保證DSL腳本的簡潔性和確定性至關重要；其次，一旦出現前后端劃分，就會約束和限制用戶表達設計意圖的自由，比如“前端服務”不能操作數據庫、后端服務不能帶前端頁面就是非常典型的一種限制；再比如因為劃分了“前、后端服務“，為了滿足用戶一個界面編輯所有業務邏輯的目的，把所有“前、后端服務”都塞進了同一個編輯界面里，這也是一種限制，而且這種限制導致了交互復雜度和用戶使用難度的急劇增加。
在應用實現階段，可以通過提供不同的DSL解釋器，來提供不同的實現。（比如前后端一體化實現或者前后端分離實現）

換一個視角和思路：讓用戶區分前后端其實類似于讓用戶在為他所搭建的應用做“前端渲染”還是“服務端渲染”這樣的技術實現方案的選擇。首先，這種選擇對用戶實現業務功能來說沒有任何意義；其次，一旦把前后端概念暴露給用戶了，不僅用戶已經沒得選了，而且應用實現方式今后也難于做調整，這其實是一種比較糟糕的“設計、實現”分層策略。

3.在設計層面“頁面、接口、邏輯、數據”已經可以完整、自洽的描述一個服務

在設計層面“頁面、接口、邏輯、數據”的抽象已經可以完整、自洽的描述一個服務。在此基礎之上，強行引入前后端服務的分類，是一種過度的、重復的描述，而且帶來了不必要的約束。這種設計的根因是根植于程序員腦中的根深蒂固的前后端分離開發的思維。當然這跟我們低代碼產品的演進路徑也有一定的關系，后續我會單獨寫文章介紹。

想象一下，你只是想買一臺能用的電腦，但賣家告訴你只能單獨買機箱和顯示器，沒有筆記本也沒有一體機，這是挺怪的一個邏輯。

4.“前、后端服務”劃分帶來的后遺癥后患無窮

前面提到過，因為設計階段區分了“前、后端服務”、前端服務不能操作數據庫、后端服務不能帶頁面的限制，為了滿足用戶在一個界面編輯所有業務邏輯的目的，把應用所有“服務”都塞進了同一個編輯界面里。這樣的設計帶來如下兩個問題：

1）在用戶意圖編輯某個服務時，很可能不小心修改到其他服務，因為用戶的編輯視圖能操作到應用內的所有服務，不管你是從“應用編輯”還是“服務編輯”進入；在編輯界面點擊“預覽、提交、發布”的時候，用戶又得清晰知道并選擇要“預覽、提交、發布”哪些服務，否則可能帶來意向不到的效果，這對使用者來說可能是件令人崩潰的事情。

2）可視化編輯視圖“一次可編輯應用的所有服務”跟“一次只編輯應用的一個服務”，后者應用了問題域拆解的思維，通過合理的問題域拆解，設計要面對的復雜度就能顯著降低，才能有可控的解決方案；反之，前者沒有對問題域做任何拆解，需要一次面對所有的復雜度，解決方案自然同等復雜。可惜的是，在現階段低代碼平臺的實現中，我們不僅沒有做問題域的拆解，而且還把問題丟回給了用戶，這是一種糟糕的解題思路。

我們的設計本來是該幫助客戶解決問題的，但是卻制造了麻煩。

04 第二項建議：在實現層面也不要劃分出前后端服務

在實現層面，在DSL解釋、編譯和打包階段，前后端可能需要提供不同的解釋器和流水線，但是不建議做前后端完全獨立的部署。主要原因是，如果要做完全獨立部署，那勢必就需要為前端引入BFF。而引入BFF從低代碼應用角度出發，除了導致整體實現復雜度會增加以外我想不到有任何明顯的收益。解釋這一點，我們首先要真正理解BFF產生的原因和目的：

一方面微服務思想普及導致api向原子化演進，另一方面產品由于用戶體驗多變需求，也希望前端承擔更多的接口組合、業務邏輯實現職責，以縮短開發響應用戶需求的路徑。這時候這就需要有地方去承載這些實現，如果都在應用前端實現，那當有多端或者多系統需求的時候，這些業務邏輯就需要重復實現，這對程序員來說是無法忍受的事情。這也是前端引入BFF的最根本最原始的原因。
前端請求性能優化的考慮。把多個網絡請求組合放在靠近微服務的BFF層實現，可以解決因存在多次串行請求所帶來的用戶體驗問題。
前后端徹底分離。前后端獨立開發更加方便：前端靈活性，即使有微服務遷移，也不影響前端。
此外，在實際實踐中，我們經常還會在BFF實現用戶認證和部分鑒權工作。