サーバサイドのアプリケーションエンジニアとして
Nodeの使い道を知るためにNodeのアプリケーションをDDDで作ってみました。
https://github.com/pospome/NodeRealTimeApp
初めてのNode&DDDなので完成度は低く、
自分が未熟なせいで初期の設計方針がDDDとは異なっていたため、
考えていた機能を全て実装せずに開発を終了しました。
これをリファクタリングするよりも失敗を活かして新規で作りたいなと・・・。
なので、アプリケーション自体はあまり参考にならないかもしれません・・・。
Nodeを触ろうと思ったきっかけは
「サーバサイドエンジニアとしてNodeを使ったことないのはダメな気がする」
という気持ちからでした。
詳しくは以下の記事のスライドを見てください。
http://d.hatena.ne.jp/pospome/20150814/1439520677
ということで、Nodeを実際に触ってみて感じたことを書いていこうと思います。
結論から言うと、
PHP,Scala,Go のようなサーバサイドバックエンドとして採用するのは微妙かもしれません。
というのも、NodeがCPU負荷の高い処理に弱いからです。
逆に言うと、CPU負荷がかからなければ問題ないと思います。
ただ、現実では仕様変更や機能拡張によって
CPU負荷の高い処理が追加される可能性が大いにあると思います。
そういったリスクを考慮すると他の選択肢（PHP, Scala, Goなど）を考えた方がいいのでは?
と思ってしまいます。
言語がJSというのも懸念点の1つかもしれませんが、
自分はTypeScriptを利用したこともあり、
それほど辛い印象は受けませんでした。
（コンパイルは面倒ですし、出力されたJSも無視できなかったり、デメリットも当然ありますが）
JSもES2015, 2016 とバージョンが上がっていくに連れて
他の言語と同等の機能が実装されたり、
使いやすくなっていくと思うので、
「言語がJS」という点については後々改善していくのかなと・・・。
なので、それほど問題視はしていません。
（JSに愛着を持っただけかもしれませんが・・・）
ただ、自分のJS(TypeScript)スキルが低いので、
実装スピードと可読性を担保できなかった部分はあるので、
ちゃんと書こうとすると、ある程度の学習コストはかかってしまうと思います。
（とはいえ、これは他の言語にも言えることなので、「Nodeが・・・」とかっていう話ではないですけど。）
で、結局何に使えるのか? というと、
クライアント（アプリ、Webフロントエンド）とバックエンドサーバの間に置くのがいいと思います。
これは以下のスライドの最後の章の説明と同じです。
http://d.hatena.ne.jp/pospome/20150814/1439520677
AWSの API Gateway + Lambda のようなAPIサーバとして利用したり、
クライアント側がWebであれば、isomorphic&サーバサイドレンダリングが可能になります。
APIサーバはマイクロサービスとの相性もいいと思います。
実際に実装してみて、WebフロントエンドもサーバサイドもJSで書けるというのは意外と便利だなと感じました。
結局、Webフロントエンド向けのサーバサイドという印象でしょうか。
サーバサイドエンジニアが知っていて意味が無いとは言いませんが、
メインウェポン（PHP, Scala, Go）というよりはサブウェポンのような感じです。
「知ってると便利」みたいな。
あと、socket.io は使っていて面白いですね。
チャットアプリでも作ると楽しいと思います。
ということで、
サーバサイドNodeの使い道についてまとめてみました。
次は何を触ってみようか考え中です。
