Nodeとフロントエンド − 知っておかなければならない、今と未来の話−

f:id:axross:20150217234404p:plain

というタイトルのスライドを作って社内勉強会で発表した。

フロントエンドエンジニアに限らずNodeは「未来」だと思っていて、とはいえ「未来の技術」だとは思っていない。すでにNodeは身近な存在で、これからのWebにとってなくてはならないリーダー的な役割になると考えている。

背景

前置きとして、弊社はあまりNodeとかに乗り気ではなくて、PHPとかレガシーな技術を好む傾向にある。あまりリスクやコストを払いたくないというのは会社として当然で、Nodeにはそのどちらも少なからずあることは理解している。

ただ、問題なのは、そのリスクやコストが弊社だと高すぎること。サーバサイドエンジニアのほとんど全てがPHPエンジニアで、イベントループ型のサーバーとか、Nodeのような活発なOSSベースの開発とかにあまり理解がない。PHPのような、枯れて安定している技術を「使う」側しかやりたがらない。今後も採用がそれに特化していく「恐れ」がある。

で、そんなんじゃダメだろっていうことで、まずはフロントエンドエンジニア周りからNodeを広めるようにした。今日の発表もその延長線上で、そろそろサーバーサイドの人にも一石を投じたいなと思って、社内チャットで大げさに告知した(された)。

反応

反応はあまりよくなかった。一応既に社内でもNodeサーバー(というかSocket.IOサーバー)でのプロダクトはあるにはあるけど、いかんせんNodeらしくない。

詳しいことはあまり言えないけど、大きいバイナリデータ扱わせようとしたり、Nodeのバージョンやあらゆるパッケージが更新不可能なまま放置されている。

そういう背景もあって、消極的な印象だった。議論も軽くしたけど、終着しなさそうなので適当なところで切り上げるしかなかった。

どうしてNodeを使いたいか

Nodeのメリットが何かと言ったら、イベントループモデルであり、非同期I/Oを持ち、それがJavascriptで扱えるということに収束すると思う。

言語レベル(厳密には違うけど)で非同期I/Oを持ってる言語ってあまりないと思うし、Javascriptでサーバーが書けるってことはすごくエラい。Javascriptが言語として素晴らしいかどうかは別として、クライアントとサーバーの言語を統一できて、受け渡しをするデータの形式としてのデファクトであるJSONとの完全な互換があるのは重要だと思う。

なぜなら、クライアントとサーバーの言語を統一できるということは、2つに分かれてしまったロジックのいくつかを1つにできるということだから。

Isomorphic Javascript

そういう思想や設計をIsomorphic(あいそもーふぃっく)と呼んだりする。WebにおいてはそれがJavascriptで、Nodeで実現できる。

Reactが最近クライアントサイドWAFとして熱いけど、あれはサーバー(Node)でも動く。ReactのComponentを実際に動かして、結果となるDOMをStringで吐き出せる。だから、イニシャルビューで既にデータの入ったDOMが書き出さたHTMLを返せる。検索エンジンのクローラー対策もバッチリだし、何より最初に無駄なXHRが走らない。サーバーからしても嬉しいはず。

バリデーションとか、適当なユーティリティメソッド群とか、あとはモデル(データ構造)とか、そういうのも1つにできる。内容の似ているバリデーションをクライアントとサーバーでそれぞれ違う言語で実装しなくてもよくなるし、データ構造としてのモデルを統一できて、あとはそれを各所で拡張する的なこともできる。JSONに乗せての受け渡しも楽になるし、設計としても気持ちよくなる。

今後

これからも社内ではガンガン推し進めて行く。今度社内でNodeのワークショップをしようと企画していて、まずは導入編みたいなことをして、社内にNodeが当たり前のように存在している状況を作りたい。僕の心が折れなければだけど。

もしよければ、スライドの方も見てみてください。

サーバサイドJavaScript Node.js入門 (アスキー書籍)

サーバサイドJavaScript Node.js入門 (アスキー書籍)

  • 作者: 清水俊博,大津繁樹,小林秀和,佐々木庸平,篠崎祐輔,高木敦也,西山雄也,Jxck
  • 出版社/メーカー: KADOKAWA / アスキー・メディアワークス
  • 発売日: 2014/02/27
  • メディア: Kindle版
  • この商品を含むブログを見る