はじめに

Node-REDが手になじんでしまうと手放せなくなります。Node-REDの開発はもちろんのこと、過去の経緯でほかの言語で開発する際にも設計の確認で使うこともあります。なぜ、こんなに手になじんで、ちょこちょこっと始められるのか考えてみました。

シームレス

ソフトウェア開発でシームレスという言葉を最初に聞いたのは、オブジェクト指向分析が話題になった時でした。
1980年代に話題になった構造化分析/設計では、データフロー図で分析したモデルをプログラムの構造図にする際に、中心となる処理を引っ張り上げて機能モジュール間に無理やり上下関係を持たせるなどしていました。工程間でモデルが異なることで分析(What)と設計(How)で溝ができ、あと戻りが難しい開発方法でした。
オブジェクト指向分析は、分析と設計で同じモデルを用いることで、分析と設計がシームレスに移行できるという点が売りの一つでした。オブジェクト指向設計は実装への移行も容易でした。安定したクラス構造が見つかれば、全行程の作業をシームレスにできました。
「データは機能より安定している」という意見もあるようですが、作業のきっかけとしてはすぐれているもののデータだけを考えていてもなかなかアイデアはまとまりません。システムにはどのような機能が必要で、どんな順序で処理するか、その中でデータはどのように扱われるか、それらを総合的に考えなければ、イメージを固めて、実現可能性を確認することはできません。

問い

　新しいシステムのアイデアが思い浮かんだとき、あなたはどんなメモを書くでしょうか？

よくある答え

　スマホがあって、サーバーがあって、対象データを保存して、他のユーザや機器が参照するそんなイメージでしょうか。スマホからサーバーへ認証情報を送ると、現在の状態が示されて、スマホのUIで入力した情報がサーバに送られる。業務フロー、シーケンス図、ユースケース図、ユーザーストーリ、そんな感じの記法で書きませんか？
　さて、実現可能性を確認したいので少し実装を考えだすと、データを洗い出してクラスを考え出すのでしょうか。全体のイメージができているならそれも可能でしょう。でも新しい業務なら画面遷移も考えたいのでペーパープロトタイピングで画面遷移を考えて、これが抜けていたとか、この情報が最初にいる、などと間違いに気づいて、データ構造が徐々に安定していくでしょう。
　このように、業務フローやシーケンス図から開発が始まり、システムへの理解が段階的に進みます。

Node-REDなら

　業務フローやシーケンス図を描き始めたタイミングで実装を始められます。
「いやいや、そんなことはないでしょう」そう思われるのも無理はありません。しかし、簡単にできてしまいます。
　スマホから呼び出されるAPIをひとまず作成してグローバルデータを返すようにします。これにはhttp inノードとhttp responseノード、データの取り出しにチェンジノードがあれば良いので3ノードでできます。グローバルには何か入れておかないといけないのでJSONで設定したデータを起動時にセットします。起動時のタイミングをインジェクトノートで出力し、テンプレートノードにJSONで設定、チェンジノードでグローバルに入れるようにします。これでサーバ側の実装は終わりです。合計6ノードでできてしまいます。
　画面遷移を確認する場合は、簡単にWeb画面が作成できるDashboardを使ってスマホのテスト画面が作れます。一覧の画面を作ると、意外な勘違いがが見つかったりします。

データ構造は後から考えても良い

　上の問いへの別解で、型のゆるい言語、あるいは抽象度の高いクラスを使っていきなり実装を始めるという方もおられるでしょう。機能間のインタフェースを明確にしないことで、処理に集中できます。
Node-REDはノードと呼ばれるモジュールの入出力はmsgオブジェクトに統一されています。まずはmsgがどのような順で、どのように流れるかを考えることができます。実装を進めていく中で不足する属性があれば、上流のどこかで準備します。どこで準備するかを考えることが、どのように処理するかを考えることになります。
　もちろん、わかっているデータ構造はあらかじめ実装して構いませんし、プログラムが大きくなるなら早めにデータ構造を考える方が良いでしょう。できたつもりで進めていって、問題が出てくれば追加すればよいのです。

データストレージも後から考える

　とはいえ、データベースなどのデータストレージはよく考えないといけないので、アイデアを確認する際の障壁になりがちです。まずは別にサーバーを立てないことで、容易に始めることができます。
　もっとも簡単な方法がグローバル変数もしくは（タブ内で参照可能な）フロー変数の利用です。javascriptのオブジェクトを保存できますので、属性名で疑似ハッシュとして用いることができます。使ってはいけない属性名があることと、メモリの消費に注意すれば便利に用いることができます。グローバル変数やフロー変数はコンテキストデータのメニューから参照や削除ができますので、意外と便利です。
　少し複雑な検索もしたいのであれば、SQLiteやNeDBが簡単です。RDBやドキュメントDBのようなことができますので、ひとまず動かして考えるのには便利です。ある程度システムの全貌が見えてきて複雑な検索やサーバー間でデータ共有を検討する際にサーバーを立てると良いでしょう。

どこまでシームレスに使えるか

　とりあえず動くようになってから仕様を徐々に固めます。機能拡張やDBなどストレージの確保をすると、徐々に本格的なシステムになるでしょう。Node-REDは実運用で使われている例も多いので、品質保証をすれば、そのまま本番に使うことも可能でしょう。ただし、Node-RED単体では冗長化やアプリ間のデータ共有の仕組みはないので、外付けする必要があります。
　あとは開発規模の問題です。Node-REDは高機能なモジュール（ノード）が多いので、あまり大きくならないかもしれません。しかし、アイデアを整理する際のデータ構造を元に始めると、処理の都合で似て非なる属性がどんどん増えることがあります。これは危険な兆候です。「どうだっけ」と少しでも不安に感じたら、データ構造を見直してください（プロのためのNode-RED再入門）。

おわりに

　Node-REDの手になじむ感じを整理してみました。他にもいろいろ特徴があるので、ぜひ使いこなしてください。