SPAとサーバサイドについて

SPA(Single Page Application)でサーバサイドをどうすべきかについて述べたいと思う。

MEANじゃダメな理由

今、MEANが注目されている。

MEAN(MongoDB, Express, AngularJS, Node.js)スタックが優れている理由 - Mozilla Open Web Day in Tokyoを終えて

MEAN(MongoDB, Express, AngularJS, Node.js)は、JavaScriptフルスタックのアーキテクチャで、データモデルとしてクライアントからDBまで一貫してJSONを使うという点でシンプルな設計が可能となっている。

業務ロジックにおけるO/Rマッパの割合は40%といわれるが、それが不要となって単純なJSONオブジェクトのやり取りだけで済んでしまうのは大変画期的だといえる。

しかし、MongoDBには、RDBMSでは一般的なトランザクション機能がサポートされておらず、スキーマレスという性質が品質面で悪い影響を与えている。Node.jsには、いわゆるコールバック地獄に陥りがちという問題がある。これらは業務アプリを開発するうえでは致命的な欠点にならなくもない。

ここにMongoDBのアプリ開発についてポイント突いた記事がある。

MongoDBでECサイトを実運用する3つのテクニック
1. トランザクション問題を回避する
2. スキーマをしっかりと設計する

これはMongoDBでもうまく設計すればECだって作れるよという内容のものだが、裏を返せばそれだけ大変な目に合いますよということだ。

ECサイトを構築運用してきた私の経験からいえば、これは、(乂´д｀) No way! である。

ReflexWorksによる解決案

MEANは、要は、AngularJSによるSPA(Single Page Application)を中心にしたものであって、サーバサイドについてはJSONを返すREST APIが実装できれば何でもいいはずだ。

クライアント・サーバーの両方で実行できるisomorphic とまではいかないにしても、一貫してJSONやJavaScriptを扱え、かつO/Rマッパが不要であればそれで十分である。

ReflexWorksはMongoDBと同様にドキュメント指向であり、以下のような特長をもつ。

• XMLやJSONなどの構造化データの読み書きができる。
• ACIDトランザクションをサポートしており、シンプルなTransaction ScriptパターンでAPIが実行される。
• AngularJSのMV*アーキテクチャーと相性がよく、ModelとViewに集中して開発ができる。
• アプリケーションで定義するソフトスキーマを採用、項目の追加が容易である。

詳しくは、12/10 のセミナーで説明するので、興味ある方はぜひご参加下さい。

「AngularJSとReflexWorksで始めるSPA開発 ～もうサーバー側で悩まなくて大丈夫～」

参加申し込み => compass

SPAの優れた開発生産性

SPAでは、JavaScriptでJSONデータを処理し、ページを再読み込みせずに動的にページを更新する。

ユーザーが操作するたびにサーバーにリクエストを投げてHTMLを生成するよりも、クライアントだけで動的に画面を更新するほうが早くて効率的である。また、ユーザーの操作に応じてインタラクティブに動くリッチクライアントを実現できる。

パフォーマンスやSEO対策で問題があるといわれるが、業務アプリにおいては、ビューのパフォーマンスが問題になることは稀であり、SEO対策についても今年の年末にSPAのURLをGoogleがクロールするようになるという。（生まれ変わるAngularJSより）

むしろサーバサイドでのHTMLの事前レンダリングから解放されるメリットの方が大きく、特に開発生産性については相当なアドバンテージがあると考えられる。

Yeoman、Bower、Gruntなどのビルドツールやapi-mockなどを利用すればサーバサイドのことは意識しなくてよい。

毎回サーバにデプロイする必要がなく、ファイルの変更を監視してブラウザのリロードをかけたりできるので、開発者はストレスなく開発できる。

さらに、CircleCIやTravisCIによる自動テスト＆デプロイも利用可能である。

サーバサイドでレンダリングはオワコン

たまにAngularJSとサーバサイドの両方にビューの機能を持たせる話を耳にするが、早く諦めてサーバサイドはAPIだけにすることをお勧めする。さらにスマホ向けAPIも共通にできればアーキテクチャーとしては大変スッキリする。

でもこれはLAMPを得意とする開発者にとっては苦痛を伴う環境の変化になるだろう。

ふとデジャブ感におそわれたので調べてみたら、８年前の2006年11月に書いた記事が見つかった。

楽をするために苦労を厭わない人たち - Seasarカンファレンス(秋) -

「しかしWeb2.0の主役になれなかったからといって、今更、LAMPの生産性に追いつこうと思っても、とうてい無理に思える。
（中略）Webアプリケーションをサクサク作るっていわれても、本当にそのようにできるのか。私はJavaで作るWebアプリという発想そのものが疑問符「？」である。LAMPの台頭で、それがもう否めない時期にきているのではないか。」

このときJava全盛でEoDとかいってたのを覚えているが、結局はRoRをはじめとするLAMPの生産性にはかなわなかった。しかし、８年経った今はこう言い換えることができる。

「LAMPがSPAの生産性に追いつこうと思っても到底無理に思える。私はLAMPで作るWebアプリという発想そのものが疑問符「？」である。SPAの台頭で、それがもう否めない時期にきているのではないか。」

８年前のLAMPが今のSPAといえなくもない。

最後に

ここまで一気に書いてから rebuild67a を聞いた。

どうやら、AngularJSが嫌いという人が増えているとのこと。

困ったな。