在視覺化程式設計和基於流程的開發領域,一個新專案因其創新的方法解決併發限制而備受關注。由社群成員 Towaway69 開發的 Erlang-RED 旨在用專為併發和訊息傳遞設計的 Erlang 語言替代 Node-RED 的 JavaScript 後端。
將視覺化程式設計與 Erlang 的併發模型相結合
Erlang-RED 利用 Node-RED 直觀的視覺化介面,同時用 Erlang 強大的併發能力替換其後端。該專案解決了 Node-RED 的一個基本限制:JavaScript 的單執行緒特性。透過實現與現有 Node-RED 流程相容的 Erlang 後端,開發者可以獲得真正的併發能力,而不犧牲視覺化程式設計的簡單性。
「這個想法是利用 Erlang 的訊息傳遞和低開銷程序,在 Node-RED 流程中實現真正的併發。同時也將低程式碼視覺化流程程式設計引入 Erlang。」
這種方法對需要高併發的應用特別有價值,如物聯網系統、資料管道或分散式應用。開發者已經實現了大量 Node-RED 的核心節點,包括 http 輸入/輸出、MQTT、檔案操作,以及諸如 switch、join 和 split 等流程控制節點。
Erlang-RED 支援的節點(部分列表)
節點 | 狀態 |
---|---|
catch | 可捕獲選定節點和整個流程的異常 |
change | 支援多種操作,基本 JSONata 支援 |
debug | 支援除錯整個訊息 |
delay | 支援靜態延遲 |
exec | 在生成模式下執行命令,支援超時 |
http in | 適用於 GET 和 POST 請求 |
http request | 基本請求支援 |
mqtt in/out | 應該可以正常工作 |
split | 支援陣列拆分 |
switch | 正常工作 |
template | Mustache 模板正常工作 |
限制:
- 不支援上下文(流程、節點、全域性)
- JSONata 實現有限
- 不支援 JavaScript 函式節點
![]() |
---|
Node-RED 介面的截圖,展示了匯出節點的功能,突顯了 Erlang-RED 所基於的視覺化程式設計環境 |
視覺化程式設計採用面臨的挑戰
社群討論強調了 Erlang-RED 等視覺化程式設計方法面臨的幾個挑戰。一個重要問題是缺乏視覺化版本控制和比較工具。與基於文字的程式碼不同,Git 等工具可以顯示精確的變化,而視覺化流程通常以包含座標的 JSON 儲存,這使得有意義的比較變得困難。
正如一位評論者指出,這為視覺化環境中的協作開發創造了障礙。當節點的座標發生變化(這對邏輯沒有影響)時,這些在版本控制系統中會顯示為程式碼變更。這將語義變化與純粹的視覺變化混合在一起,使程式碼審查和協作比傳統的基於文字的程式設計更具挑戰性。
儘管存在這些挑戰,開發者指出 Node-RED 在解決大型程式維護方面已經相當成熟,透過連結節點和子流等功能,能夠實現程式碼重用和更好地組織複雜應用。
開源與許可哲學的交匯
關於該專案非常規的DON'T DO EVIL許可證,出現了一個有趣的討論。這個受 Douglas Crockford 的 JSONlint 許可證啟發的許可證,引發了關於在軟體許可證中新增哲學宣告的實用性和影響的辯論。
一些評論者指出,非標準許可證可能阻止企業採用並限制貢獻,因為它們通常會在企業環境中觸發法律審查。其他人則讚賞開發者確保其工作不被無償利用的立場。
許可證討論揭示了開源理想與商業現實之間的張力,特別是對於那些希望分享工作同時保持對商業使用方式一定控制權的獨立開發者。
未來方向和類似專案
社群對其他語言的類似方法表現出興趣,提到了用於 Python 的 Py-RED,並詢問其他視覺化程式設計環境。開發者還提到計劃改進文件,增加更多實際案例,並可能建立專案的影片解釋。
對於有興趣探索 Erlang-RED 的人,該專案提供了全面的測試套件和直接整合在 Node-RED 介面中的視覺化單元測試功能。這使開發者能夠確保與原始 Node-RED 功能的相容性,同時透過 Erlang 的併發模型擴充套件功能。
隨著視覺化程式設計的不斷發展,像 Erlang-RED 這樣的專案展示瞭如何結合不同正規化的優勢來克服現有工具的限制,為開發併發系統的開發者開闢新的可能性。