01 寫作背景

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

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

1、前端、后端

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

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

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

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

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

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

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

1）從設計DSL的目的說起

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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