ハクソク

世界を動かす技術を、日本語で。

HNを表示: Node-REDに触発されたErlangのための視覚的フローベースプログラミング

374日前原文(github.com)

概要

  • Erlang-RED は、Node-REDのNodeJSバックエンドをErlangで置き換える実験的プロジェクト。
  • Erlang の並行処理・メッセージパッシング性能を活かし、Node-REDの低コード・視覚的フロー構築の利点を融合することが狙い。
  • Node-REDの既存フローコードとの 高い互換性 を目指すが、JavaScriptで書かれたfunctionノード等は未サポート。
  • テスト駆動開発 で進行し、ユニットテストや視覚的テストが統合されているのが特徴。
  • Docker・Heroku・Fly.io など多様なデプロイ手段をサポート。

Erlang-RED：Node-REDバックエンドをErlangで再実装する実験

プロジェクトの目的と背景

  • Node-REDの NodeJSバックエンド を、 Erlang による100%互換（functionノード等除く）実装に置き換えることを目標とする提案。
  • Node-REDは 拡張性・可読性・使いやすさ に優れる一方、NodeJSが シングルスレッド である点が課題認識。
  • Erlangは マルチプロセス・並行性 に優れ、 メッセージパッシング を前提とした設計であるため、Node-REDのフロー構築と親和性が高いと判断。
  • Erlangの 難解な文法 を、Node-REDの 視覚的・低コード なフロー設計で補完することを目指す発想。

開発戦略

  • テストフロー駆動開発 （flow driven development）を採用し、Node-REDのフローと同等の動作をテストで保証する方針。
  • テストフローは 別リポジトリ で管理し、保守性とNode-REDとの連携性を確保すること。
  • アーキテクチャは ノード間の相互依存 が多く、設計図は複雑になる傾向がある点を認識しつつ進行。

サポート中のノード・機能

  • catch ：例外キャッチ（グループ未対応）
  • change ：多くのオペレータ対応、基本的なJSONataもサポート
  • complete ：一部ノードで利用可能
  • csv ：RFC4180準拠、カンマ区切りのみ
  • debug ：メッセージ全体のみ対応、プロパティ単位不可
  • delay ：静的ディレイのみ、動的ディレイ未対応
  • exec ：spawnモードでのコマンド実行・kill・タイムアウト対応
  • file in ：/priv配下のファイル対応
  • function ：Erlangコードのみ対応、タイムアウト・複数出力未対応
  • http in/request/response ：GET/POSTのみ、一部制限あり
  • inject/join/json/junction/link/markdown/mqtt/noop/split/status/switch/template/trigger ：各ノード基本機能を部分的にサポート
  • Contexts（flow/node/global） ：未サポート
  • JSONata ：Erlangで部分実装

Elixirとの連携

  • Elixirヘルパー をerlang-red-elixir-helpersリポジトリで管理し、ErlangノードからElixirノードも利用可能。
  • Elixirコードの直接利用も可能だが、基本はErlang構文を優先。
  • Earmark 等のElixirライブラリもErlangノード経由で参照可能。

ビルド・テスト・開発

  • ビルド ：rebar3 get-deps && rebar3 compileで依存取得とコンパイル
  • テスト ：rebar3 eunitでユニットテスト実行
  • 開発 ：rebar3 shell --apps erlang_redで開発シェル起動
  • エディタ起動 ：open -a Firefox http://localhost:9090/node-redでNode-REDエディタ表示

Docker・デプロイメント

  • Docker開発 ：リポジトリをクローンし、ボリュームマウント・ポート指定でErlang-REDを起動すること
  • リリースビルド ：rebar3 as prod release -n erlang_redでリリースパッケージ作成
  • Fly.io ：Dockerfile.flyとシェルスクリプトで簡単にデプロイ可能
  • Heroku ：コンテナスタック利用、Dockerfile.herokuで指定フローのみ実行（エディタ無効化も可能）

テスト・ユニットテスト・視覚的テスト

  • ユニットテスト ：Node-REDのエクスポートダイアログに「Create Test Case」ボタンを追加し、テストフローを視覚的に管理・実行
  • assertノード ：メッセージ到達でテスト失敗、属性テスト等で正確な検証を実現
  • 視覚的ユニットテスト ：テスト結果を一覧・個別実行・失敗箇所をデバッグパネルに通知し、フロー実装との互換性を担保

コントリビューションと関連リポジトリ

  • Erlangコード・Node-REDテストフロー の貢献を歓迎、Elixirコードは専用リポジトリで管理
  • 各テストフローは1機能に特化し、assertノードで検証すること
  • ユニットテストフロースイート はNode-RED/Erlang-RED両方で実行可能、FlowHub.orgで管理
  • JSONataサポート はErlangパーサーで部分的に実装、必要に応じて拡張可能
  • BEAM VM 上で動作するため、Erlang/Elixir等様々な言語の統合が視野

FAQ・コミュニティ

  • 質問・議論は Erlang Forum や Node-RED Forum で受付
  • 詳細や議論は各種ドキュメント・フォーラム参照

追伸

  • Erlang-REDは、Erlangの 軽量プロセス・メッセージパッシング の利点をNode-REDのフローに活かすことを目指すプロジェクト
  • HNコミュニティからの フィードバック を歓迎

Hackerたちの意見

これいいね！例のセクションをもうちょっと上に移動させたらどうかな？見た目がすごく良くて、システムがどんな感じかをより良く伝えてくれると思う。ノードベースの環境ではこれが重要だよね。

└

一例として、私がErlang-REDを使って作ったウェブサイトがあるんだ[1] でもまだ初期段階だから、良い例はまだ思いついてないんだ。Erlangコミュニティからいくつかの例をもらって実装したいんだけど、もしアイデアがあればぜひ連絡してほしいな！[1] https://red-erik.org

これには何年も興味があったんだ。他に似たようなプロジェクト知ってる？他の言語をターゲットにしてるやつとか。プログラミングのこのアプローチの主な問題点は何？大きなプログラムは扱いづらいの？

└

Py-Redっていうのは知ってるよ。Pythonで同じことをしようとしてるやつだね。Node-REDをフロントエンドにして、他のものをバックエンドに使う感じ。似たようなものは聞いたことないな。視覚的なフローベースのプログラミングの主な問題はツールだよね。視覚的な比較やバージョン管理をするための良いツールがないんだ。GitHubみたいなのは、エディタで見えるフローコードをレンダリングできないし。Node-REDの場合、フローを定義するJsonは比較できるけど、すぐに意味がなくなっちゃう。意味的な変更が視覚的な変更と混ざっちゃうから、ノードのx,y座標が変わったって、コードの論理には意味がないんだ。だから、コードの共有や共同開発が視覚的には難しいけど、ツールが不足してるからなんだよね。テキストプログラミングの時代も、SourceForgeやGitみたいなものがあったけど、今の視覚的コーディングと同じ問題があったよ。Node-REDには大きなプログラムをメンテナンスしやすくするための機能がたくさんある。フロー間をジャンプできるリンクノードみたいなものもあって、コードの再利用もできる。繰り返しのコードをカプセル化して、どこからでも参照できるサブフローもある。それがNode-REDを選んだ理由でもあるんだ。最も成熟していて、よくメンテナンスされているローコードの視覚的フローベースプログラミングツールだと思う。他にもn8nみたいな大きなものもあるけど、Node-REDの汎用性には欠けてるね。Node-REDを使ってウェブサイトを作りながら、RaspberryのインストールでLEDも制御できるんだ。Node-REDはめっちゃ柔軟だよ。

└

Unreal Blueprintが多分一番人気だね。かなりカスタマイズされたC++フレームワークの上にあるカスタムシステムだよ。ビジュアルスクリプティングはすごく生産的になり得るけど、これらの視覚的スクリプトはテキストにきれいに戻せないことが多いから、数十年分のツールを捨てちゃうことになるんだ。マージもうまくいかないことが多いし。

└

これはフローベースのプログラミングじゃなくて、ビジュアルプログラミングに関係してるんだ。PythonでホストされたLispインタプリタを修正して、JSON風のLisp - JLISPを読み込めるようにしたんだ。LispよりもウェブフロントエンドがJSONを出力する方がずっと簡単だからね。それから、この言語を中心にしたシンプルなローコードUIを作ったよ。エディタは、CADソフトのタイムラインみたいに左から右にLisp関数の呼び出しを整理してあって、個々の操作をクリックすると引数を編集できるんだ。システムを紹介するビデオはこちらだよ https://youtu.be/3Tf3lnuZcj8 編集可能なノートブック（読み込みが遅いけど、WASMでPythonを実行するよ） https://marimo.io/p/@paddy-mullen/jlisp-in-buckaroo 近いうちに静的にエクスポートされたJupyterノートブックを作るつもり。

└

まあ、こんな問題に関するページもあるよ； https://scriptsofanotherdimension.tumblr.com/ https://blueprintsfromhell.tumblr.com/ そして一番の問題は、強い制約が画面/ディスプレイのサイズなんだよね --- 一つの画面に収まらないコードの塊は追いかけるのが難しくなるし（次はどっちにスクロールすればいいの？）、モジュールを宣言するのが当然だと思ったら、結局は逃げようとしてたテキストの壁にぶつかることになる --- 各単語がきれいなボックスに包まれて、線で飾られてるだけなんだ。私の考えでは、アルゴリズムはどう見えるのかという質問に対する答えがまだないってことだね。それはさておき、できるときはこのスタイルで作業してるよ。よく使うのは： https://www.blockscad3d.com/editor/ でデザインをざっくり作ったり、もっと複雑なプロジェクトには： https://github.com/derkork/openscad-graph-editor を使ったりしてる --- ただ、その後者は通常、私が作業している特別なライブラリを使ってるけどね： https://github.com/WillAdams/gcodepreview

└

ここにいくつかの提案があるみたいだけど、nodescript.devを試してみるのもいいかも。これもnodejsベースだし。ちなみに、私はこのプロジェクトにちょっと関わってるんだ。

昨夜、Erlangの代わりにFLENGを使ってこんなの作ろうと思ってたんだ ;) Node-REDからインスパイアを受ける人が増えてるのがすごく嬉しい！絶対にこれで遊んでみるよ！

└

FLENG[1] - すごい、「Prologから派生した低レベルの並行論理プログラミング言語」って、Erlangと同じ系譜だから簡単に置き換えられそうだね。 ;)

Erlangのコースや本をおすすめしてくれる人いる？

└

learn you some erlangっていうのをよく見かけるんだけど、これはいいオンラインリソースみたいだね。その著者は「Erlang in Anger」って本も書いてるし、BEAMの本もあって、ErlangとBEAM仮想マシンについて深く掘り下げてるよ。Erlangを始めたばかりだから、あんまり詳しいことは言えないけどね！視覚的にコーディングする方が好きだな :)

└

代わりにElixirを考えてみるのもいいかも。文法が簡単だし、機能や目的はErlangと同等だと思う（あくまで個人的な意見だけど）。それに、LiveView（ノートブック）や良いウェブスタック（Phoenix）みたいな他の便利なものもたくさんあるし。

ハイヴマインドは同じことを考えてるね。

最近Node-REDを見たんだけど、これも面白いね。これらはクールだと思うし（NodeJSよりErlangの方が好きだけど）、こういうことに特化したコードベースのシステムってあるのかな？ただコードを書くことはできるけど、特にイベント駆動のシーケンシングやアクションの問題を解決するためのDSLやライブラリがあればいいなと思ってるんだ。

└

私の知る限りでは、Node-REDのDSLに最も近いのはフロー設定を保存するためのflows.jsonフォーマットだね。ノードIDとワイヤーで定義されたグラフ/フローの定義を持つ非常にシンプルなオブジェクトの配列形式なんだ。それに対してミニマリストなインタプリタを作るのは結構簡単だよ。また、Node-REDは10年以上も続いている非常に安定したソフトウェアなんだ。今日のflows.jsonファイルを使っても、Node-REDの初期リリースで動かすことができるから、フォーマットは後方互換性があって、簡単に拡張できるんだ。> イベント駆動のシーケンシング/アクションの問題。フローベースのプログラミング[1]は厳密にはイベント駆動ではなくて、NodeJSではメッセージの概念がなくてイベントだけだからそう実装されてるんだ。Erlangは独立したプロセス間でメッセージを渡すから、私の意見ではFBPにより適していると思うよ。[1] https://jpaulm.github.io/fbp/index.html

└

Benthosの子孫のどちらか、BentoかRedPanda Connectをおすすめします。設定駆動型で、変換DSLがあって、ドキュメントも良いです（RedPanda ConnectのドキュメントよりBentoのドキュメントの方が好きです）。それに、Benthosは消費したメッセージを上流にackしないことを明示的に拒否しているので、下流でackされない限りメッセージを落とすことはありません。明示的に指示しない限りはね。

└

ReativeXライブラリ（例えばRxJS）もカウントされるんじゃない？ 何か特定の機能を探してるの？

└

それにflogoもあるよ https://github.com/TIBCOSoftware/flogo

Node-REDは並行処理を説明するフローを作成するための素晴らしいツールだけど、NodeJSがシングルスレッドなのは残念だね。じゃあ、最初からマルチプロセスのものを使えばいいんじゃない？それは素晴らしい！でも、今これをやっているから、マルチプロセスやErlangじゃなくて、もっとメインストリームな言語で、より良いライブラリエコシステムを持っていて、マルチスレッドに特化したものがあればいいなと思う。Rustが思い浮かぶけど、もっと良いものがあるかもしれないね。比較的成熟したRustベースのビジュアルフロープログラミング言語ってある？

└

マルチプロセスやErlangじゃなくて、もっとメインストリームな言語で、より良いライブラリエコシステムを持っていて、マルチスレッドに特化したものがあればいいなと思う。Rustが思い浮かぶけど、もっと良いものがあるかもしれない。Goも良い候補だね。

└

マルチプロセスやErlangじゃなくて、正直言うと、Erlangを選んだのはシンタックスが好きだからだし、次にニッチだからなんだ。フローベースのプログラミングはニッチで、ビジュアルFBPはもっとニッチ、Node-REDはさらにニッチで、Erlangはニッチ - まさにニッチの連鎖だね ;) Elixirを見てみて、これはErlangにRubyのシンタックスを加えたもので、大きなコミュニティもあるよ。また、意図としてはフローエディタを使うことで、ユーザーはそれがErlangやNodeJSだとは知らないようにするつもりなんだ。Node-REDと互換性を保つことを目指しているから、フローは実際に互換性があるんだ。だから、どの言語が使われるかはある程度関係ないんだ。Erlangを選んだのは、メッセージベースでフローベースのプログラミングに適しているからで、フローベースのプログラミングは独立したプロセス間で不変オブジェクトを渡すことが全てだから...それがErlangの本質だよ。

└

これって（願わくば！）Erlangプロセスを使ってるみたいだけど、OSプロセスとは混同しないでね。

└

JVMベースのものもその要件に合いそうだね。でも、見つからないな。

└

マルチプロセッシングやErlangじゃなくて、もっとメインストリームな言語で、ライブラリエコシステムが良くてマルチスレッドに焦点を当てたものだったらいいのに、Rustが思い浮かぶけど、もっと良いのがあるかもしれないね。なんでマルチプロセッシングをやめて、各スレッドに数MBの大きなスタックを持ち、同じヒープに書き込むマルチスレッドに移行するのか、ちょっと理解できないな。逆に後退してる気がする。> Rustが思い浮かぶけど、もっと良いのがあるかもしれないね。興奮はわかるけど、同時にこれがミームになりつつあるのも感じる。つまり、「なんでRustで書き直さないの？」っていうコメントがどのリポジトリや「show HN」投稿にもついてくるのがね。昔のnodejsみたいな感じだよね：「なんでnodejsで書かないの？それはウェブスケールだよ！」問題は、しばらくすると逆効果になって、そういうことだけで人々がRustから逃げるようになるんだよね。

└

より良いライブラリエコシステム 参考までに、Erlangの標準ライブラリはそこそこ「バッテリー同梱」って感じだよ。Cとの相互運用性もそんなに悪くないし。[1] [0]: https://www.erlang.org/doc/apps/stdlib/api-reference.html [1]: https://www.erlang.org/doc/system/tutorial.html

ビジュアル環境に関しては、このツールがどんなものかを示す画像がもっとあると思ってた。

└

試してみたいならライブデモがあるよ！私にとっては、ビジュアル部分よりもErlangの部分に重点を置いてるかな、基本的にNodeREDだしね。[1] https://ered.fly.dev/node-red

サンプル画像はREADMEの一番上に移した方がいいよ。大事なことを埋もれさせちゃダメだよ。

あなたたちのサイトやNode-REDのサイトでイライラするのは、用語を使う前に定義しないところだよ。「フロー」とか、これって何？プログラム？用語集を維持してほしいな。

└

なるほど、ちゃんとあるみたいだね、https://flowfuse.com/node-red/terminology/, https://nodered.org/docs/user-guide/concepts、だからリンクしてほしいな。