精讀《低代碼邏輯編排》

邏輯編排是用可視化方式描述邏輯，在通常搭建場景中用於代替邏輯描述部分。

更進一步的邏輯編排是先後端邏輯混排，通常出如今一站式 paas 平臺，今天就介紹一個全面實現了邏輯編排的 paas 工具 node-red，本週精讀的內容是其介紹視頻：How To Create Your First Flow In Node-RED，介紹了若是利用純邏輯編排實現一個天氣查詢應用，以及部署與應用遷移。

概述

想要在本地運行 Node-RED 很簡單，只要下面兩條命令：

npm install -g --unsafe-perm node-red
node-red

以後你就能夠看到這個邏輯編排界面了：

咱們能夠利用這些邏輯節點構建前端網站、後端服務，以及大部分開發工做。光這麼說還比較抽象，咱們接下來會詳細介紹每一個邏輯節點的做用，讓你瞭解這些邏輯節點是如何規劃設計的，以及邏輯編排究竟是怎麼控制研發規範來提升研發效率的。

Node-RED 截止目前共有 42 個邏輯節點，按照通用、功能、網絡、序列、解析、存儲分爲六大類。

全部節點均可能有左右鏈接點，左鏈接點是輸入，右鏈接點是輸出，特殊節點可能有多個輸入或多個輸出，其實對應代碼也不難理解，就是入參和出參。

下面依次介紹每一個節點的功能。

通用

通用節點處理通用邏輯，好比手動輸入數據、調試、錯誤捕獲、註釋等。

inject

手動輸入節點。能夠按期產生一些輸入，由下一個節點消費。

舉個例子，好比能夠按期產生一些固定值，如這樣一個這個對象：

return {
  payload: new Date(),
  topic: "abc",
};

固然這裏是用 UI 表單配置的：

以後就是消費，幾乎後面任何節點均可以消費，好比利用 change 節點來設置一些環境變量時，或者利用 template 節點設置 html 模版時，均可以拿到這裏輸入的變量。若是在模版裏，變量經過 {{msg.payload}} 訪問，若是是其它表單，甚至能夠經過下拉框直接枚舉選擇。

然而這個節點每每用來設置靜態變量，更多的輸入狀況是來自其它程序或者用戶的，好比 http in，這個後面會講到。其實經過這種組合關係，咱們能夠把任意節點的輸入從生產節點替換爲 inject 節點，從而實現一些 mock 效果，而 inject 節點也支持配置定時自動觸發：

debug

用來調試的，當任何輸出節點鏈接到 debug 的輸入後，將會在控制檯打印出輸出信息，方便調試。

好比咱們將 inject 的輸入連上 debug 的輸入，就能夠在觸發數據後在控制檯看到打印結果：

固然若是你把輸入鏈接到 debug，那麼原有邏輯就中斷了，然而任何輸出節點均可以無限制的輸出給其它節點，你只要同時把輸出鏈接到 debug 與功能節點就好了：

complete

監聽某些節點觸發完成動做。經過這個節點，咱們能夠捕獲任意節點觸發的動做，能夠接入 debug 節點打印日誌，或者 function 節點處理一下邏輯。

能夠監聽所有節點，也能夠用可視化方式選擇要監聽哪些節點：

catch

錯誤捕獲節點，當任何或指定節點觸發錯誤時輸出，輸出的格式爲：

error.message 字符串
錯誤消息。

error.source.id 字符串
引起錯誤的節點的ID。

error.source.type 字符串
引起錯誤的節點的類型。

error.source.name 字符串
引起錯誤的節點的名稱。（若是已設置）

其實每一個節點都有固定輸出格式，這些固定格式限制了開發靈活度，但熟練掌握後能夠大大提高開發效率，由於全部同類型節點格式都是同樣的，這是邏輯編排帶來規則約束的好處。

status

監聽節點狀態變化。

link in

只能鏈接 link out。link in、link out 就像一個傳送門，用來整理邏輯編排節點，使之看上去易於維護。

好比下面的例子，在一個天氣 http in 服務後，穿插了許多邏輯處理節點，有處理響應 html 內容的 template 節點，也有處理請求查詢城市天氣的 http request 服務，總體邏輯雖然聚合，但比較雜亂：

較好的方式是分類，即相似代碼開發中的模塊化行爲，將天氣服務導出，其餘任何用到的模塊直接導入，這個導入動做就是經過 link in 實現的，link out -> link in 只是一個空間位置的變換，傳輸值是不會變的：

這樣模塊看起來清晰了許多，若是要知道各個 「傳送門」 見鏈接關係，只要鼠標點擊其中一個就能夠給出提示，看起來十分方便：

link out

和 link in 成對出現，用來導出輸入值，後面對接 link out 能夠像傳送門同樣將值傳送過去，在視覺上不會造成鏈接線。

comment

註釋，配合 link 系列使用，可讓邏輯編排 UI 更易於維護。

結合原視頻的例子，對於天氣服務，有建立環境變量邏輯，有查詢邏輯，其中查詢天氣還分爲查詢當前天氣、連續 5 每天氣、查詢國家信息，咱們能夠在 UI 上講每塊邏輯分組，並利用 comment 組件標記好註釋，方便閱讀：

功能

功能型節點，通常用於處理業務邏輯，因此包含了基礎的 if else、js 代碼、模版處理等等功能模塊。

function

最核心的 js 函數模塊，你能夠用它作任何事：

其輸入會傳導到 msg 對象，能夠經過代碼修改 msg 對象後再經過輸出節點傳導出去。

固然也能夠訪問和修改節點、流程、全局變量，這個在 change 節點裏介紹。

switch

對應代碼的 switch，只是用起來更加方便，由於咱們能夠根據不一樣 case 導出不一樣的節點：

注意看上圖，由於有三條分支，因此節點的導出項也變成了三個，咱們能夠根據不一樣邏輯走不一樣的鏈接：

change

用來改變環境變量。環境變量分爲三種，分別是當前節點、流程（畫布）、全局（跨應用）。也就是說，變量能夠存儲在某個節點上，也能夠存儲在整個畫布上，也能夠跨畫布存儲在全局。

訪問參數分別爲 msg.、flow.、global.，設置這些參數後，就像全局變量同樣，任何節點均可以在任何地方使用，比較方便。

好比應用固定了一些 URL 地址，直接把一串字符串寫死在某個 http in 節點裏並不明智，由於後面的 html 或者其它節點裏可能會訪問它，一旦你進行修改，影響面會很是廣，所以最好將其設置爲全局變量，在節點中經過變量方式訪問：

其實在控制檯，能夠看到這三種變量的值：

當咱們利用 change 節點賦值後，能夠經過調試面板查看不一樣做用域全局變量的值：

range

區間映射，將一個範圍的值映射到另外一個範圍。其實經過 function 模塊也能完成，只是由於比較經常使用因此封裝了一個特殊節點。其實用戶也能夠本身封裝節點，具體方式能夠參考 官方文檔。

上圖很容易理解，好比數據分析中歸一化就能夠用這個節點實現。

template

以模版方式生成字符串或 json。

其實本質上也能夠被 function 代替，只是用來寫模版的話有高亮，維護起來比較方便。

內置了 mustache 模版語法，經過 {{}} 方式使用變量。

好比咱們經過 inject 注入一個變量給 template，並經過 debug 打印，流程是這樣的：

其中 inject 是這麼配置的：

能夠看到，將 msg.name 設置爲一個字符串，而後經過 template 訪問 name:

delay

延遲發消息，一個快捷的工具，能夠放在任何輸入與輸出中間，好比讓上面的例子中，inject 觸發後 5s 再打印結果，能夠這麼配置：

trigger

一個消息觸發器，相比 inject，能夠更靈活的設置什麼時候從新觸發。

從配置能夠看出，首先和 inject 同樣發送一條消息，而後能夠等待，或者等待被重置，或者週期性觸發（這樣就和 inject 同樣），其中 「發送第二條消息到單獨的輸出」 和 switch 同樣會多一個輸出口。

而後有重置條件，即 payload 爲何值時重置。

經過這個組件能夠看出來，其實每一個節點均可以用 function 節點實現，只不過經過定製一個節點，能夠用 UI 而非代碼的方式配置，使用起來更方便。

exec

執行系統命令，好比 ls 等，這個在系統後臺執行而非前端，因此是一個至關危險的節點。

咱們能夠在配置中寫入任何命令：

rbe

異常報告節點（Report by Exception），好比說當輸入變化時進行阻塞。

網絡

用於建立網絡服務，好比 http、socket、tcp、udp 等等，由於其它都不經常使用，此次僅介紹 http 服務。

http in

建立一個 http 服務，能夠是任何接口或者 web 服務。

當你把 Method 設置爲 post，鏈接到 http response 就建立了後端接口；當設置爲 get 請求，並鏈接 template 寫上 html 模版，並鏈接到 http response 就建立了 web 服務。

雖然這種方式建立 web 服務難以使用 react 或 vue 框架，不過自定義節點仍是爲其創造了可能性，或許真的能夠把前端模塊化文件定義爲節點相互串聯。

http response

http 返回，只能對接 http in 的輸出，老是與 http in 成對使用。

若是隻用了 http in 但沒有用 http response，就至關於後端代碼裏處理了請求，但沒有調用相似：

res.send("hello word");

來向客戶端發送內容。

http request

與 http in 建立一個 http 服務不一樣，http request 直接發送一個網絡請求並將返回值導入到輸出節點。

視頻中獲取天氣的例子，就用了 http request 發起請求獲取天氣信息：

不難看出，發送請求後，又使用了 function 節點處理返回結果。不過在邏輯編排中仍是指望少使用 function 節點，由於除非有很好的命名，不然難以看出來節點含義，若是 function 處理內容過多或者 function 區塊過多，就失去了邏輯編排的意義。

序列

序列是對數組進行處理的節點。

split

對應代碼的 split，將字符串變爲數組。

join

對應代碼的 join，通常與 split 配合使用，方便處理字符串。

sort

對應代碼 sort，只能根據 key 作簡單的升序降序處理，對於簡單場景比較方便，但對於複雜場景可能還會使用 function 節點代替。

batch

批量接收輸入流後，根據數量進行打包後統一輸出，等於批量打包，能夠按照數量或者時間間隔進行分組：

解析

很容易理解，專門處理上述格式的數據，並按照數據特徵輸出，好比 csv 數據，能夠每行一條消息的方式輸出，或者打包爲一個大數組以一條消息輸出。

固然也能夠被 function 節點代替，那麼解析方式與輸出方式均可以自定義。

存儲

持久化存儲，通常存儲爲文件。

file

輸出爲文件。

file in

以文件做爲輸入，並將文件結果做爲輸出。

watch

監聽目錄或文件的修改。

精讀

看了上面 node-red 功能後，相信你對邏輯編排已經有較爲體系化的認識了。

邏輯編排的目的是爲了讓非研發人羣也能夠快速上手研發工做，所以註定是爲 paas 工具服務的，而邏輯編排到底好很差用，取決於節點功能是否完備，以及各節點之間通訊是否順暢，像 node-red 邏輯編排方案，在完備性上作的較爲成熟，能夠說只要熟練掌握了幾個核心節點規則，使用起來仍是很是提效的。

邏輯編排也有自然缺點，就是當全部節點都退化爲 function 節點後，會存在兩個問題：

• 全部節點都是 function 節點，即使有說明，但內部實現邏輯很是自由，致使邏輯編排沒法起到約束輸入輸出的做用。
• 退化到代碼函數式調用，本質上與寫代碼無異。邏輯編排之因此提效，很大程度上是我要的業務邏輯恰好與節點功能匹配，以低成本 UI 配置的方式實現效率才高。

然而這也是有解決方法的，若是你的業務沒法被現有的邏輯編排節點知足，你能夠嘗試抽象一下，本身梳理出業務經常使用的節點，並用合理的配置封裝，只要經常使用業務邏輯能夠被封裝爲邏輯節點，邏輯編排就還有爲業務提效的空間。

總結

邏輯編排是一種極端，即用 UI 方式描述通用業務邏輯，下降非專業開發人員的上手門檻。經過對 node-red 的分析能夠發現，一個較爲完備的邏輯編排系統仍是能帶來價值的。

然而針對非專業開發人員降本提效還有一種極端，就是徹底代碼化，可是把代碼模塊化、函數庫、工具鏈甚至低代碼平臺建設的很是完備，以致於寫代碼的效率根本不低，這條路走到極致也不錯，由於既然要深刻開發系統，一樣是投入時間學習，爲何學習寫代碼就必定比學習拖拽 UI 效率低呢？若是有高度封裝的函數與工具輔助，效率不見得比 UI 拖拽來的低。

然而 node-red 在建立前端 UI 的模版上還能夠再加強一下，把 template 從節點升級爲 UI 搭建畫布，邏輯編排僅用來處理邏輯，這樣對大型全棧項目的前端開發體驗會更好。

討論地址是： 精讀《低代碼邏輯編排》· Issue #319 · dt-fe/weekly

若是你想參與討論，請 點擊這裏，每週都有新的主題，週末或週一發佈。前端精讀 - 幫你篩選靠譜的內容。

關注 前端精讀微信公衆號

版權聲明：自由轉載-非商用-非衍生-保持署名（ 創意共享 3.0 許可證）