2年間の開発サイクルを終えて、多くの変更が加わったNode-REDがついに、バージョン1.0に到達した。1.0での主要な新機能の中には、新しくなった非同期メッセージパッシングモデル、新しい補完API、デフォルトでのメッセージクローニングなどが含まれている。ビジュアルエディタも改良された。
産業用IoTソリューション構築の容易化を目的としてIBMが開発したNode-REDは、オープンソースのビジュアルプログラミング環境である。物理デバイスやクラウドシステム、データベース、APIなどを表現するノードを結合することで、複雑なシステムを構築することが可能だ。各ノードは、いずれかの入力ノードからメッセージを受信し、それを処理した上で、出力ノードに転送する。結果的に構成された全体のフローが、システムによって実行される処理を構成するものになる。Node-REDには、HTTP/UDP/TCP/MQTTメッセージの送受信、コマンドの実行、ファイル処理など、さまざまな共通的なタスクを処理するノードが含まれている。ノードのデバッグやメッセージのマルチプレクサ、メッセージバッファなど、複雑なロジックの構成を単純化するノードも用意されている。さらに多くのノードが、Node-REDライブラリで提供されている。
(Node-RED Wedサイトより引用)
完全非同期なメッセージパッシングモデルに移行するということは、すべてのノードが同期的動作を持つ現在の状態から移行して、非同期と同期のノードの混在という統一性のない状況を発生させるということになる。開発者として必要なのは、既存のフローがノードの同期的動作に依存しないようにすることだ。これまでのバージョンでは、フロー全体を非同期ノードで構成した場合、すべてのメッセージがJavaScriptイベントループの一回のパスでフローするようになっていたが、Node-RED 1.0では、各ノードが自身の入力メッセージを処理して、メインイベントループへのコントロールを放棄するようになった。イベントループの次のステップでそのメッセージが処理されるのか、あるいは別のメッセージが処理されるかは、実行時の内部キューでどちらが先に到着するかによって決まる。完全な非同期メッセージパッシングへの切り替えは、コードをフローにプラグインすることでメッセージのルーティングパスをカスタマイズ可能にするという、Non-REDのロードマップにある将来的な機能のひとつを実現するための前提条件だった。さらに完全非同期ノードのシーケンスでは、予測できない時間スパンでイベントループを専有する可能性がある。この可能性を除外するために、タイムアウトを使用して、システムが制御できない状態に陥ることのないようにコントロールし、システムに入力される各メッセージが正常な処理時間を確保できるようにする必要がある。
新たな非同期メッセージパッシングモデルに関連して、ノードがメッセージの処理完了を通知するための新しいAPIが用意された。簡単に言うと、ノードが新たなメッセージを受信した時、そのメッセージ用のsendとdoneコールバックも同時に受け取ることで、どのメッセージが処理されたのかを正確にトラッキングできるようにする、というものだ。これに伴って、出力のないノードが処理を完了した時にトリガすることの可能なCompleteノードも導入された。既存のノードはすべて、段階的に新たなAPIに移行する必要があるが、Node-REDランタイムが当面は旧APIのサポートを続けるため、急ぐ必要はない。
最後に注意すべき点として、非同期メッセージパッシングの導入に伴って、デフォルトですべてのメッセージがクローンされるようになった。これは、メッセージの重複を極力回避しようとしていた以前のモデルから、大きく方向転換したものだ。新たな動作がパフォーマンスに影響するのは事実だが、複数の非同期的変更が原因でメッセージが破損することはなくなり、メッセージの正確性が保証されるようになる。
最後に、Node-REDビジュアルエディタパレットが再構成され、より直感的な使用が可能になった。Twitter、Email、Feedparserなど、多くのノードが削除されている。サブフローの構成機能はJSONエディタとともに改善されて、新規ユーザにも使いやすいものになった。
Node-REDは、macOS、Windows、Linuxなどの主要なOS上の他、IoTデバイスや産業機械でも動作が可能だ。Dockerイメージを使用すれば、簡単に実行することができる。