I am mitsuruog | SPAを構築するときに知っておいた方がいい7つの課題

ブラウザでの Javascript の高速化と Backbone や Angular のような JavascriptMVC フレームワークの登場により、以前より SPA（Single page application）が構築しやすくなりました。

さらに、Yeoman に代表される SPA を作成するするための scaffold（土台）が整備されてきましたので、結構さくっと SPA が作れるようになったのも事実です。

さくっと作った SPA がさくさく動かない・・・作ったけど使えない・・・なんてことにならないように、SPA を構築する前に知っておいた方がいい課題について調べてたり考えてみました。

1. パフォーマンス

クライアント側で DOM を作成するため、DOM が大きい場合、DOM 生成に時間がかかりレンダリングが遅くなります。また、フレームワークを使っている関係上、Javascript のライブラリ、ビジネスロジック、テンプレートなど、ダウンロードするファイルサイズが大きくなりがちです。

デスクトップなどネットワークが安定していて CPU パワーがある場合は問題とならないのですが、モバイル端末の場合に致命的となりかねません。これらは、開発時は気づかないが、システムテストなど、実際の端末や環境下で動作させた場合に初めて顕著になる場合があります。

2. メモリリーク

リフレッシュを一切行わないため、Javascript のメモリリークがおきやすい。フロント側で DOM を生成するため、View 構築時にメモリを消費していきます。また、使用しなくなった View を破棄する場合は、フレームワークの作法に則って View を破棄してメモリを開放する必要があります。

それでも、フレームワークの不具合などでメモリが開放されないケースがあります。
(画面数が多い場合、適度に画面遷移してリフレッシュさせましょう。)

3. セキュリティ

ビジネスロジックを Javascript にて実装した場合、誰でもダウンロードして読むことができます。

Web システムでは基本的にフロント側の入力を信用してはいけないので、極力フロント側にビジネスロジックを持たないようにするべきです。フロント側に返すデータはサーバ側で生成し、フロント側は DOM 構築に徹しましょう。

4. フレームワークロックイン

SPA で構築する際は、なんらかの JavascriptMVC フレームワークは必須です。JavascriptMVC フレームワーク同士に互換性などほとんどありませんので、確実にフレームワークにロックインされます。これはある意味仕方がないことです。

フレームワーク選定時に、後々廃れてしまってもフレームワークで学習した知識が他に持ち出せるという基準で選定するのも、人材育成ポリシー的にはありだと思います。

業務系だったら Backbone とか Angular とかやってれば大丈夫だと思います。
(とはいえ、作り捨てるくらい割り切ったほうがいいかもしれません。すごい癖のあるベンダー製フレームワークってのも、それはそれでニッチな市場があると思います。それと心中する気があればですが。)

(2014/11/06 追記)
OpenUI5のことです。当時扱いに困っていたので毒吐いていたようです w

5. 画面設計から UI コンポーネント設計への思想転換

SPA で作る場合、いままでの行ってきた画面単位の設計思想から脱却しなければなりません。SPA は URI をベースに Ajax 非同期通信を行い画面を部分更新していくという点で、静的ではありません、動的で生きています。

まず、FullREST API（GET/POST/PUT/DELETE）にする必要はありませんが、URI とリソース設計をする必要があります。

今まで画面単位で設計していたものを、URI をベースとしたリソースとリソースを表示するためのコンポーネントという単位で設計する必要があります。画面はコンポーネントを組み合わせて作るようなイメージになります。

また、（Backbone など）フレームワークによっては、デフォルトでサーバ側へ要求する URL を生成するものもあり、書き換えるのが面倒な場合、その URL ををベースに設計する必要があります。

6. フロントエンジニア不足

SPA で作成する場合、Javascript の実装量が増えるため、本格的にフロントエンジニアの参画が必須となります。

Javascript を使える Web 技術者はそれなりに多いと思いますが、SPA で構築する際は、フレームワークの理解は必須ですし、ブラウザのメモリ利用状況や細かなキャッシュ制御、ネットワーク、固有デバイスの問題など総合的にフロント周りのトラブルシュートができるエンジニアが欲しいです。
(これは SPA に限ったことではありませんが・・・そこまでできる人少なすぎます。)

(2014/11/06 追記)
SI では今現在も状況変わったいないように思えます。育成にも苦労してます。

これは開発時だけではなく、保守・運用フェーズに移行したあとの方が問題となります。 Struts などで作られている従来の Web アプリケーションは、いわゆるサーバサイドエンジニアのみでサイトを保守・運用できるのに対して、SPA はフロントエンジニア＋サーバサイドエンジニアが必須です。

中小規模の業務系システムにおいて、1 人保守など少ない人員体制を敷いた場合、保守するエンジニアの技術的負担がかなり大きくなると思われます。 SI の場合、できるフロントエンジニアの外部調達はほとんど事実上不可能な状況ですので、開発フェーズからフロントエンジニア育成の視点をしっかり持って計画しないと、後から泣きを見ます。

7. 番外編

7.1 SEO

通常 SPA は、クライアント側で画面を生成するため、プレーンな HTML を返します。

そのため、Web クローラからは、あたかもプレーンなページのように見えます。

当然、Javascript が OFF の環境ではまったく動作しません。
(トップページのページランクがサイト全体に適用され結果的に SEO 的に優位となるという意見もあったり、ちょっとまだ判断するには情報不足。)

(2014/11/06 追記)
sitemap.xmlにサイトのページ構造(記事中ではAJAX indexedと言ってる)を書き出すのがいいようです。 AngularJS and SEO - yearofmoo.com

7.2 認証・セッション管理

認証、セッションなど業務アプリケーションに必要な機能について、Javascript フレームワークと組み合わせた場合のノウハウが蓄積されていない。
(これは自分の調査不足かも。SPA は REST だし、REST は Stateless って話もあるけど、じゃ Stateless で作る場合、サーバ側はどうセキュアに作るのって議論が別にあるはず。)

(2014/11/06 追記)
重要な Ajax 通信時は CSRF 対策のため 1 回ワンタイムトークンを取得してから、その callback で本当のリクエストを行うようにしています。また、認証、セッションについては従来の Web 開発のノウハウが使えると感じています。WebAPI アクセスの正当性についてはJWTを使うことが増えました。こちらに記事書いたので読んでみてください。JWT(Json Web Token)を利用した WebAPI での Credential の受け渡しについて

まとめ

SPA を導入した場合の課題をいくつか挙げてみました。少し否定的なことばかり書いて来ましたが、私自身、フロントエンジニアとして SPA や JavascriptMVC フレームワーク非常に好きです。

サーバ側の WebAPI（ビジネスロジック）の再利用性、テストの容易性やフロント側 UI の大胆な着せ替えが可能になるなど、SPA のメリットは計り知れないものがあります。新規のシステムだけではなく、既存システムの外部 API 追加などで部分的に導入するなど、SPA のメリットを生かす戦略の元での導入であれば大賛成です。

しかし、SI の現場で大規模導入する場合、どうしてもエンジニアのスキルや企業文化的に慎重にならざるを得ないのも事実です。正直、ショッピングカートのような Statefull な Web アプリケーションを Java で作ったとしたら、SPA で頑張って作るより JSF で作ったほうがよほど効率的でメンテナンスも楽です。

今後、業務系 Web アプリケーションにて SPA で構築するかどうか検討するシーンが増えると思いますが、SPA 使い方次第では、毒にも薬にもなるということお忘れなきよう。

p.s

一部の技術好きなエンジニアの声で安易に導入して保守とかで苦労しないよう、自戒の念も込めて書きました。巷では、フロントとサーバの中間層に Node.js を配置するハイブリッドなアプローチもあるようです。こちらも注目していきたいと思います。

こちらに、素晴らしい Reply 記事がありますので、興味のあるかたは一緒にお読みください。

「SPA を構築するときに知っておいた方がいい 7 つの課題」は課題ではない

あわせて読むといいかも

SPAを構築するときに知っておいた方がいい7つの課題

目次