5月24日、25日の二日間にわたり開催されたMicrosoftの技術者向けイベント「de:code 2016」で、日本マイクロソフト赤間信幸氏の「エンプラ系 業務Webアプリ開発に効く！実践的SPA型モダンWebアプリ開発の選択手法」というセッションを聴講しましたので、そのレポートをお届けします。

ただタイトルにもある通り、筆者的にはちょっともやもやする内容でもあったので、HTML5 Experts.jpコントリビューターの酒巻瑞穂さんと、講演の内容をベースとした軽い対談も行いました（後日、エンタープライズWebアプリのあるべきかたちについて、もっと掘り下げた内容の記事も作る予定です。乞うご期待）。

セッションレポート

SPA(Single Page Application)とは

今、Single Page Application(以降、SPAと記載する）が業務アプリケーションでも利用できないかということが話題になっています。復習になりますが、SPAとは以下の様な特徴を持つアプリケーションです。

• 単一ページで機能を提供するWebアプリケーション
  • ページをリロードせずにJavaScriptでWebAPIと通信
  • JavaScript、CSS、HTMLを組み合わせて画面を更新
  • これにより応答性が高く、使い勝手の良いWebアプリケーションを実現する
• Web上では割とSPAは一般的だが、業務アプリケーションでもSPA型の開発ニーズが高まっている

従来型のWebアプリケーションはサーバサイドが中心でした。そのほとんどの処理をWebサーバで行い、クライアントは受け取ったHTML、CSSを使ってレンダリングを行い、若干のJavaScriptを動かすというものでした。SPA型のWebアプリケーションでは、サーバはクライアントの指示に応じてデータを返し、UIの更新等はすべてクライアントで行います

SPA型Webアプリケーション開発の難しさ

このようなSPA型アプリケーション開発は相当のスキルが必要であり時にとてもむずかしいものになります。特に、SPA型Webアプリケーション開発に関するネット上の情報は、低水準からスクラッチで開発するためのものが多い。OSSなどをフル活用して作りこむ、いわばC++開発のような「職人技」の世界であり、ハードルが高いのが現実です。

エンタープライズ系業務Web開発の場合、こうした「職人的開発」はあまり向いていないように思います。

ここでエンタープライズ系開発とオープン系開発のギャップを確認してみましょう。

このような比較から、.NETのような高水準言語での開発に慣れ親しんだ開発者が、SPA開発に取り組むのはハードルが高いといえます。まとめると次の問題が挙げられます。

• 低水準開発の必要性：HTML, CSS, JavaScriptでの開発はC#, .NETでの開発に比べて低水準
• 高すぎる開発自由度：「どう作るか」は自分でゼロから決める必要がある
• ライブラリの選択の難しさ：膨大なライブラリからどれを選べばよいか分からない

そしてSPA型開発では、利用するフロントエンドライブラリによって作り方が大きく変わります。同じ「HTML5」の開発といえど、コードの互換性はほとんどありません。このためライブラリの選択には特に慎重を期す必要があるといえます。

そこで、自分のプロジェクトに合わせた適切なライブラリの選択が必要になるのですが、実際の現場ではこれが非常に難しい。Microsoftからは、クライアントライブラリは（ほぼ）提供されていませんが、世の中にライブラリは星の数ほどあります。

ライブラリを選ぶ際に考慮すべき事項

言語拡張

ここで、ライブラリを選択する際の私なりのやり方をご紹介します。ライブラリの選択では、基本言語仕様、DOM操作、通信処理、CSSに分けて考えてみます。そうすると、DOM操作・通信部分はほぼ必須になるので、jQueryを利用すればいい。基本言語仕様とCSSに関しては、スクラッチの作り込み型Webアプリケーションでは非常に重要ですが、業務Webアプリケーション開発の場合はケースバイケースです。より具体的に言うと、CSSではLess、SASS、StylusなどのCSSプリプロセッサーの選択、altJSでは、TypeScript、CoffeeScriptの選択などが挙げられます。

UIライブラリ

UIライブラリに関しては、低水準UI部品郡と高水準UI部品郡に分けて考えます。低水準UIライブラリには無償のものが多く、高水準UIライブラリは高機能ではあるが、ほとんどの場合有償製品となっています。

設計・実装方法論、フレームワーク

進化が激しくトレンドも頻繁に変わるため、注意が必要です。フレームワークを利用すれば、ロックインも発生します。特にWebフロントエンドの世界では数年と経たずにトレンドが変化します。このため頻繁に手を入れる見込みがない場合には、むやみにフレームワークに依存させるのは危険だと考えます。

各種ツール、ユーティリティ

どのような各種ツール、ユーティリティを利用するかというような考えは、初めてSPA型開発に取り組む場合には、後回しにするとよい。より高い生産性を目指す際には欠かせないツール郡ではあるが、ここまで述べてきた、言語拡張、UIライブラリ、設計・実装方法論、フレームワークなど覚えるべき要素、考えるべき要素が山ほどあります。最初はなくてもなんとかなりますので、必要性を感じたところから段階的に導入していくことをお勧めします。

ライブラリの組み合わせに関する注意

ライブラリは安易に組み合わせないように注意しましょう。ライブラリには必ず寿命がある上、複雑に依存しあっていることも多い。古いライブラリが他のライブラリのバージョンアップの足かせになることがあります。

長期的な保守が重要になる業務Webアプリケーションでは安易にライブラリを組み合わせるべきではないと考えています。

SPAフレームワークライブラリ

商用の高水準UI部品ライブラリは高価ですが、多くはオールインワンパッケージ（=SPAフレームワーク）になっていて、ライブラリの組み合わせ方で悩む必要が少なくなります。

このため、業務Webアプリケーション開発におけるクライアントライブラリの選択は、高水準UI部品の要否で大きく方針が変わります。

OSSライブラリの組み合わせ型開発では、利用できる高水準UI部品が少なめなので、メジャーなライブラリを中心に必要最小限の組み合わせを行います。。SPAフレームワークライブラリ依存型開発では、高水準UI部品が数多く利用できるので、シェア、情報量、日本語サポート、ライセンス費用などを元に選択するとよいでしょう。

サーバ側のページ構築

個人的には完全なSPA型ではなく、うまくサーバ技術を併用した方がSPA型の業務Webアプリケーションは作りやすい。特に.NET開発者の場合、複雑な業務ロジックはサーバ側でC#を使って記述した方が作りやすいことも多いでしょう。実際のSPA型アプリケーション開発では、サーバ側で組み立てなどにASP.NET MVCを併用するといいのではないでしょうか。UI処理の中心はあくまでもクライアントだが、上手に併用しましょう。

編集後記: 講演の内容について対談してみました。

レポートは以上になります。ただ、講演の結論が結局のところ「完全なSPA型じゃないほうがいい」と言っているように思え、少し違和感が残ったのも事実。そこで、同じくセッションを聴講していたコントリビュータの酒巻瑞穂さんと、疑問に感じたところを少し話し合ってみました。私も酒巻さんも、現役でエンタープライズWebに取り組んでいるエンジニアとして、これを機にエンタープライズ×SPAについて整理しておきたいと考えたからです。以下、その対談の内容を編集後記として掲載します。

SPAはつらい？

佐川：講演を聞いて、どんな感想を持ちました？

酒巻：正直、ちょっと違和感残る内容でしたね。

佐川：結論が結局、本格的なSPAは難しいからやめとこう、と言っているようにも聞こえました。

酒巻：私も、メリットが見えないものはがっつりSPAにする必要はない。何もかもSPAにすべきとは思いません。ただ例えば、モバイルの事を考えると、SPAにしていくメリットは大きいですよね。クライアントサイドでのオフライン処理を求められることも多いので、そうなるとSPAで作るほうが自然だったりする。

SPAはセッションをクライアント上で維持できるので、Server Push型のイベントが必要なアプリケーションを作る必要がある場合にも有効ですね。

佐川：SPA開発は職人技という話がありましたけど、ここはどうですか？

酒巻：職人技…かどうかはわかりませんが、開発の自由度は確かに高いですよね。アプリケーションの品質が、プログラマ個人の力量に左右される部分はまだ大きいですね。

佐川：フレームワークがそういう問題解決を担えるはずなんですが、そのフレームワークが多すぎるという(笑) 。講演でも「ライブラリ選択が多すぎる」という問題提起をしていらっしゃいましたね。

酒巻：確かにそれは同意できます。でも、「開発時の選択肢がない」というのは言い換えると「衰退する技術」のようにも思えるので、個人的にはむしろ今の状況は歓迎しています。業務エンジニアとしては社内ルールなどを作って統制する方がいいんじゃないかと。

佐川：それにライブラリの選択も、Yeomanなどのジェネレータやいろんなスターターキットを使えば、かなりの部分楽できますよね。

SPAの設計は悩ましい

酒巻：ただ、講演でも取り上げられていましたが、設計の方法論などについては確かに難しいです。ここはまだ結論がないと言うか、個人的にも難しいところですね。というのもWebの進化がまだ当分先を見てるので「今」の最善はあっても来年の最善はもう判らない。

佐川：設計方法論は、採用するフレームワークによっても大きく変わってくるところですしね。ただ、今のトレンドとしてはUIのコンポーネント化というのは間違いない方向性なので、そこからスタイルを決めていける。ただ、設計方法論を語った書物はあまり見られないのも事実で、これはWebの進化が早すぎるためではないかと。

しかしSPA設計の話って、「サーバでやるか、クライアントでやるか」って話になりがちですよね。ただ、MVC的なものをどちらかに寄せなければならないという話ではない。基本的には、UIを更新する処理はクライアントに寄せるというほうが筋が良いと思います。

この話はSPAをどうするかという話ではなく、もう少し広くWebアプリケーションをどうやって作るかの話です。SPAでもMPAでも議論としては同じで、SPAにすべきかそうすべきではないということになる。 そういう意味でも、SPAを採用すべき勘所とか、Webアプリケーション全体の中のSPAの位置付けについて、先ほどの講演でもっと聞きたかった。

酒巻：個人的には、ちょっと古い内容でしたね。「DOM操作はjQuery」と言っていたが、個人的にもうあまりやりたくない(笑)。

佐川：そうそう、個人的には4年くらい前の感覚に思えました。その頃とはWebアプリケーション開発のやり方そのものが変わっている。もちろん（Webアプリケーションではなく）Webサイトを作るときにわざわざReact.jsとかAngularを利用しなくてもいい。そういう時はjQueryでもいいと思います。こういうものは当たり前ですが、適材適所で考える必要があって、それこそマネージャやアーキテクトの腕の見せどころなのではないでしょうか。

最後に

ここのところ、確かにエンタープライズでSPAの導入が多くなってきました。 一方でまだまだ事例が少ないこと、開発経験のあるエンジニアが少ないため導入しようとしてもなかなかプロジェクトとして進められないという現状もあります。この記事が、エンタープライズWebアプリの開発に少しでも寄与できたなら幸いです。

この記事は、「de:code2016」のセッションレポート、日本マイクロソフトエバンジェリスト物江修氏による「モダンWeb:たった今と、ほんの少し未来のはなし」です。講演内容を再現していますが、ニュアンス等伝えきれない場合があるかもしれません。ご了承ください。

モダンWebとは

昨今、様々なところで「モダンWeb」という言葉を聞くが、その定義は曖昧で意味するところの範囲が広範囲に及んでいるためではないかと考える。多くの場合、「モダンWeb」という文脈で語られている内容は次の４つの事柄で語られている。

• モダンなWebシステム
• モダンな開発手法
• モダンな標準機能
• モダンなアプリケーション

単にモダンWebアプリケーションと言った場合にはこれらいろいろな意味に捉えることが多いが、このように四つに分けることができる。このセッションでは、アプリケーションを開発するのに必要な「モダンなWeb標準の機能」、「モダンなWebアプリケーション」に関して触れる。

なぜ「モダンWeb」が話題になっているのか

第一に挙げられることは「時代の要求」。具体的には以下の3つが挙げられる。

• Web技術の進化
• コンテンツのリッチ化
• クライアントの多様化

Web技術で作るリッチなUIは昔から存在していたが、以前はFlashなどのプラグインを利用したいわゆるRIA(Rich Internet Applications)のほうが優勢だった。その後、Ajaxでデータを取得し、そのデータを使って部分的なUIの更新が可能になり、jQuery UIなどのUIライブラリによる開発生産性の向上、そしてHTML5の登場によって、プラグインで行っていたことがWebの標準技術だけで作ることが可能になった。これがWeb技術の進化である。

そしてスマートフォンから始まったFlashの衰退が進み、今までFlashで行っていたような要求をWebコンテンツ側にやってくるようになり、コンテンツのリッチ化が始まった。

スマートフォンを始め、PCブラウザー以外の様々なものがインターネットに繋がり、クライアントが多様化した。

この「クライアントの多様化」はサーバーサイドの形態にも影響を与え、その影響が、Webブラウザー上で動くアプリケーションにも影響を与えたという状況になっている。具体的にどういうことなのか。

黎明期のWebアプリケーションは、リクエストされたページを単純にレスポンスするというもの。ちなみに一番最初のWebサーバーはティム・バーナーズ・リーが作った「CERN Httpd」で、1991年にニュースグループで公開されたが、翌年に作られた「NCSA Httpd」ではCGIがサポートされ、動的ページが作れるようになった。ご存知の通り、このサーバーサイドで処理をして、処理結果をページで返すWebアプリケーションは広く使われている。

さらに、新しいクライアントとして携帯電話が現れる。NTT Docomoから始まった携帯電話は、それまでWebのクライアントというと、PCブラウザかゲーム機くらいで、いずれも机に座って使うようなものだった。

しかし、携帯電話は持ち歩き、行動に必要な情報を得るためのツールとして機能するモビリティという考え方が生まれた。

今までとは利用用途が異なる、サーバーではデバイスに応じた専用のコンテンツを作る必要があるなどコンテンツを作っていくには困難な状況だった。

やがて、スマートフォンに代表されるスマートデバイスが現れます。これらは、PCブラウザー用のコンテンツを同じ様に処理することができたので、わざわざ専用のコンテンツを用意しなくても済む。問題は、画面サイズに応じて表示を切り替える必要があり、同時期に出てきたHTML5関連技術であるCSS3を使ったレスポンシブWebデザインで、こうした技術を吸収することができた。

さらにスマートフォンは、サーバーサイドの処理にさらに大きな変化をもたらした。

Webアプリケーションの登場です。サーバにリクエストを投げるが、必要とするのはページではなくデータでした。この影響を受け、Webサーバーに必要な技術は、データを返す「API」が重要になった。

現在では、クライアントデバイスの性能とWebブラウザーの機能も数段上がり、処理性能ではネイティブで作られたアプリケーションと同等なことができるようになった。

SPA(Single-page Application)

単一ページによるWebアプリケーションであるSPAの特徴は、以下が挙げられる。

• 画面遷移はDOM操作
• ページのリフレッシュは不要
• リッチなエクスペリエンス

SPAにするメリットもいくつかある。例えば、サーバーサイドを「サービス化」することによって、多様化していくクライアントにも対応できるようになる。つまり、サービスをどこにでも提供できポータビリティを上げることができる。

現在のようにクライアント技術の進化が劇的に早い（言い換えると、陳腐化する速度も早い）状況下でもSPAは有効だ。クライアントとサーバーのロジックを物理的に別けることで保守性を上げることができるから。さらに分業においては、サーバーサイドを開発する人間、クライアントサイドを開発する人間で、やるべきことに集中できるということが挙げられる。

プログラミングスタイルの変化

SPAの登場によつてプログラミングのスタイルも少なからず変化している。Ajaxなどの非同期処理を行う場合、処理の単位はサーバーサイドの動作と必ずしも一致せず、処理の順番やタイミングもまちまちになる。それらを適切にハンドリングして画面に描画する必要がある。

さらに、ユーザーアクションの開始が、いわゆるPull型（サーバにリクエストするという意味で）だったが、WebRTCやWebSocketsの登場にによって、突発的に開始されるPush型（サーバからクライアントに通知する）可能性もある。

非同期処理の完了であるが JavaScriptではイベント通知で行われる。また、今まではサーバーロジックで行われていた処理をクライアントで行うケースも出てくるので、1つの完結する処理を行う場合、複数回サーバーとやり取りする必要がある。よく「コールバック地獄」ということに陥る。

不規則に発生するイベントを適切にルーティングしつつ、状態を把握し、かつ処理全体を制御する仕組みが必要で、こういった制御を行うために、JavaScriptのライブラリやフレームワークが様々な機能を実装し提供している。

そして、最新のモダンブラウザーがサポートしつつあるECMA Script2015や2016にも、こうした機能が標準で用意されようとしている。つまりイベントのフロー制御方法は

• Promise(ES2015)
• async/await(ES2016)
• Generator/yield(ES2015)

Promiseは非同期処理を抽象化したオブジェクトでPromiseパターンで非同期処理を行う。async/awaitは、Promise とGeneratorの糖衣構文で、そのGenerator/yieldは、反復子 (イテレータ )の生成元で、実行環境を維持したま中断・再開が可能となる。

SPAでは画面のレンダリングも従来のサーバーサイドの処理をメインしたものとは異なる。

SPA以前のサーバーサイドでページが生成されるタイプのWebアプリケーションでは、画面データの成形もサーバーサイドで行われていましたが、SPAではその部分をクライアントサイドで行うことになる。

素直に書くなら、エレメント一つひとつのインスタンスを取得して、各々データをセットする所謂「Glue code」を書く（”グルー”とは糊のこと）ことになる。だが、これだとエレメント変更に関わるUI仕様があるたびにコードまで修正する必要がありメンテナンスが大変だし、いちいちデータを入れるためだけのコードを書くということ自体が非効率。

データバインディング

そこで出てきたのがUIへのデータバインドです。 マークアップにUIとデータの関係を記述しておくと、JavaScriptフレームワークがよしなにデータをセットしてくれるという仕組みです。 こうすることで、データと画面、いわゆる ModelとViewの関係を1:1に紐づけ、構造的には明確に分け部品化することが可能になった。

“バインド”とあるように、ModelとViewの関係を保持します。つまり、モデルもしくはビューに変更が発生した場合、その変更が一方向、あるいは双方向に反映されます。Modelの変更のみかViewに反映されるのが1Wayバインドで、双方向に変更が伝わるのが2Wayバインドです。

まとめるとモダンなWebアプリケーションとは

• SPA
• リアクティブな動作
• M-V-Whatever

少し先のWebアプリケーションの技術的コンセプト

ここからは、ここ数年提唱されているWebアプリケーションの技術的コンセプトについて紹介します。

• Web Components
• Progressive Web Apps
• WebAssembly

Web Components

まずは「Web Components」です。これはWebをコンポーネント化する仕組みで、2013年のGoogle I/Oで紹介された。実は、Webをコンポーネント化するという仕組みは、これが最初ではなく、マイクロソフトも1998年にHTMLコンポーネントというものを提案したし、Mozillaも2001年にXBLと2007年にXBL2というのを提案した。

このコンポーネント化のメリット、目的について

Webのアプリケーションは、他のソフトウェア・アプリケーションと同様に複雑になり、今ではリリース製品の開発に大勢が協力して取り組むことは珍しくなくなった。少しでも効率化を図るには、関係者やシステム間の重複が最小限になるように開発作業を分割する正しい方法を見つけることが重要になる。そのための方法としてコンポーネント化がある。複雑なシステムでも、機能を分割していけば、単純化することができる。全体をある程度の機能単位に分割する、つまりはコンポーネント化だ。

Web Componentsの目標は、HTML、CSS、JavaScriptの関連グループを分離し、単一ページのコンテキスト “内” で共通関数を実行することで、複雑さを軽減することだ。

この Web Components は、複数の API を組み合わせるか、それ単独を使用して実現する。 しかし、すべての Web ブラウザーがその API をサポートしているわけではないので、Polyfill 用のライブラリーが用意されています。

そしてこちらがWeb Componentsを構成する要素です。

• HTML Templates
• Shadow DOM
• Custom Elements
• HTML Imports

現在のサポートの状況はこのようになっています。

※ 既定では動作しない

Progressive Web Apps

これはモバイル Web アプリ向けのコンセプトで、具体的には、高性能のモバイルWebブラウザー向けにネイティブアプリケーションのようなUXを提供しようというも。去年の「Chrome Dev Summit」のキーノートで発表され話題になったものだ。今年の４月に行われた「Google Developers Summit Tokyo 2016」でも2日のテーマになっていたくらい力を入れている。

Progressive Web Appsに求められる体験をまとめると次の様なもの

• ネイティブアプリケーションのようなUX
  • オフラインサポート: Service Worker
  • プッシュ通知: Web Notifications/Push API
  • ホームスクリーンにアイコンの追加: Web App Manifest
  • バックグラウンド: Service Worker
  • 高速でなめらかなインターフェース: CSS3 Animation

Service Workerは、JavaScriptで実装されているローカルのプロキシ、あるいはApplication Cacheの改良版として利用できる。 いままで Web ブラウザーからサーバーにコンテンツをリクエストする場合、サーバーになげてそれを返していたのが、その間にカスタマイズ可能な Service Worker というのが入って バックグラウンドで動いているので、タブを閉じてもブラウザを終了しても動作しているので、プッシュ通知もうけとれるとこと。httpsでしか動作しない。

Progressive Web Appsを実現する技術のサポート状況は

WebAssenbly

WebAssenblyは、コンパイル済みのバイナリをWebブラウザ上で直接動作させる仕組で、Microsoft、Google、Mozilla、Webkitプロジェクトのメンバーで共同開発されていて足並みが揃っている。

JavaScriptよりもポータブルでロード時間や実行に対するパフォーマンスに優れたアプリケーションを作ることが可能だ。asm.jsの次のステップとしている。

2016/3/14〜16の間にMicrosoft、Google、Mozillaの3社が3DゲームAngry botでの検証結果を各ブログで公開している。

WebAssemblyの実装状況は

ハイブリッドアプリケーションとしての利用

Webアプリケーションが苦手とするところは

• ストアのエコシステムを利用しない
• Webブラウザからはどうしてもアクセスできないハードウェアリソース

そしてこれらの Web アプリケーションのは、ハイブリットアプリとしてパッケージすることにより、ターゲットとなるプラットフォームのリソースや、ブラウザーからはアクセスできないハードウェアの機能を使用できるようになる。 また、アプリストアのエコシステムを利用することができる。

Webフロントエンドの開発リソース

インタラクティブなコンテンツを作ることができるようになったので、開発は非常に大変なものになった。

• JavaScript
  • ライブラリ
  • フレームワーク
  • エンジンテンプレート
  • altJS
• CSS
  • フレームワーク
  • プリプロセッサー
• HTML
  • 軽量マークアップ
• パッケージマネージャ
• タスクランナー
• モジュール管理

Richになったことで多くのライブラリが提供された結果「Chaos」になったのか？と思いがち。そして、ライブラリ/フレームワークの選定として考える必要がある。

• ブラウザサポート
• ベンダーサポート
• 情報
  • ドキュメント
  • 書籍類
• 学習コスト
• 開発生産性
• 機能範囲
• ロックイン
• 運用コスト

特にこの中のロックインですが、ロックインは決して悪いものではなく、優秀なベンダーと一緒になってやっていくこと、コミュニティの力を借りることでむしろ良い状況も作れる。運用コストに関しては、便利なんだけどお金がかかるというものについては考えもの。

標準技術は不変

結局、Webブラウザで動作するのは、HTML、CSS、JavaScriptであり、ブラウザがサポートしていない機能は動かない。技術はあくまでも「手段」でり、そうした技術に対する勉強は大事だが、手段であって目的ではない。目的は、ユーザに対して良いプロダクトを提供すること。たとえば、YouTubeはFlashで作られていたが、HTML5に変わったことに気づいた人はいない、そういうものが良い。

そして、WebはApplicationのプラットフォームになる。どんどん低レベルなAPIを実装することになる。結果、デスクトップと同じ様なアプリケーションを作っていける。こうした変貌は「変化」ではなく「拡張」である。

Appleショックにより禁じ手となったFlex、Silverlight、JavaアプレットなどのプラグインベースRIA製品の代替として、SPA(Single-page Application)が注目を集めています。HTML5の高度なオフライン機能を大規模開発で利用する際にも重要な役割を担う技術です。

しかしながらその実装方法には、ベンダ製品からOSS製品まで、思想も実装もバラつきがあります。何をもって正しいとするのか、どのような判断基準により選定するのかも、難しいという状況ではないでしょうか。

2014年1月27日に開催されたhtml5jエンタープライズ部による「第7回エンタープライズ×HTML5ナイトセミナー」。会場はKDDI様品川イーストワンタワーで行われました。クライアントからサーバまで様々な角度からSPAに対し、メスを入れたセミナーのレポートです。来客者のほとんどがエンタープライズ業界の方ということを考えると、SPAに対する業務アプリケーションエンジニアの関心の高さが伺えます。そしてエンタープライズ領域でも、HTML5が本格的に利用され始めた証だと言えるでしょう。

Single-page Applicationの特徴と難しさ

「いま、なぜSPAなのか」を題材としたセッションでは、筆者である私（佐川夫美雄）が、歴史的背景や技術進化を踏まえたSPAの概要、そのために必要な技術などについて話しました。RIAの衰退とHTML5の正式勧告により、これからの業務アプリケーションはSingle-page Applicationでの構築が当たり前になります。では、Single-page Applicationとはどのようなものでしょうか？どのようなことを考えればよいのでしょうか？ (スライド)

RIA(Rich Internet Application)に求められたものとして

• 表現力の高さ
• デスクトップアプリケーションと同等なUI（ユーザインタフェース）
• UX（ユーザエクスペリエンス)

があります。

RIAはアプリケーション利用者に対し高い評価を得ましたが、2010年のAppleショックにより衰退の方向へ向かいます。具体的には2010年にSteve JobsがFlashを激しく批判したことに端を発します。プロプライエタリ(Proprietary Software)なFlashよりオープン性のあるHTML5を推進するようになりました。2011年にはMicrosoftがWeb開発者に対してSilverlight戦略を後退させ、AdobeもモバイルFlashの開発を中止しました。そして2014年HTML5正式勧告です。この流れにより、HTMLでWebアプリケーションを作る方向に向かいました。

HTML5を利用すると、RIAと同等なユーザビリティが実装可能となります。その解がSPAなのです。SPAの基本的な要素は以下です。

• 単一ページによるWebアプリケーション
• ページはDOMの操作により切り替えを行う
• サーバとのやりとりはAjaxやWebSocketにより行う

DOMの操作によりページを切り替えるので、ほとんどの処理をブラウザで行うことになります。基本的にサーバとはデータのやり取りのみを行います。

では、SPAで業務アプリケーションを開発するために、必要となる技術要素は何でしょうか？

• JavaScriptフレームワーク
• altJS
• CSS Preprocessor
• 開発環境
• 通信技術
• Webアプリケーションなどのバックエンド技術
• そしてHTML5

JavaScriptフレームワークは、既に数十種類あります。開発要員、案件を考慮し適切なものを選ぶ必要があります。altJSは利用すべきです。現実的な問題として、業務アプリケーションエンジニアのほとんどが、jQueryエンジニアとなっています。JavaScriptコーティング規約を覚えさせるより、ある程度altJS(CoffeeScriptやTypeScriptなど)で否応がなしにルールを作るのも、プロジェクトマネージメントのひとつと言えます。

CSS3により、表現力豊かなサイトが作れるようになりました。そのためCSSを記述する量が圧倒的に増えました。そのためにもCSS Preprocessor(Sass+CompassやLess、Stylusなど)を使うべきです。

altJSやCSS Preprocessorは、コンパイルが必要です。またJavaScriptやCSSを圧縮するために、コマンドを打つ必要があります。開発環境も見直すべきで、最近ではYeomanやSencha cmdがあります。

Single-page Applicationを構築するときに、いくつかの問題に遭遇します。しかし、このほとんどは新しい問題ではなく既に我々が経験したものであり、一つひとつ冷静に対応する必要があります。

html5jエンタープライズ部スタッフでもある、株式会社クレスコの小川充さんのブログ「SPAを構築するときに知っておいた方がいい7つの課題」を、題材として考えたいと思います。

• パフォーマンス
• メモリリーク
• セキュリティ
• フレームワークロックイン
• 画面設計からUIコンポーネント設計への思想転換
• フロントエンジニア不足

パフォーマンスは、Sencha Touchの開発チームがHTML5で高速に動作するFacebookを開発したことで方向性は出ています。彼らはHTML5でサクサク動くFacebookアプリを作って見せたSencha Touch開発チーム。開発のポイントは、以下の3つがあります。

• DOMツリーを分離して小さく
• TaskQueueで不必要なレイアウト処理を停止
• 入出力処理はWebWorkersで止めない

アプリケーションを使い続けた結果、メモリーリークが原因で画面がフリーズするという問題は発生します。対策としては、地道に残っている参照にnullを入れ、ガベージコレクションの対象にします。この内容は「大規模UIをJavaScriptで実現するためのテクニック、サイボウズkintone開発の現場から。デブサミ2012」の引用です。

セキュリティについてですが、業務アプリケーションはほとんどhttpsで動作させます。ログイン画面ですらhttpsです。そして業務アプリケーションは基本的にプライベートネットワークでしか動かしません。セキュアな環境はSSL-VPNなどを使用し、比較的簡単に手に入れることができると言えます。

• 被害減少のためにはサーバ側でのチェック
• HTTP 認証でログアウト処理

上記に挙げたことが必須になります。

フレームワークロックインが不都合なら、おれおれフレームワークを作りますか？こういう議論ではないです。我々は構築する業務アプリケーションに最適なJavaScriptフレームワークを選択する必要があります。しかし、採用したフレームワークが永久に最適である保証はどこにもありませんので、柔軟な対応が必要です。

画面設計からUIコンポーネント設計への思想転換は必要です。実装するアーキテクチャに対応するプロセスや考え方が必要になります。フロントエンジニアは不足しているとは思えませんが、SPAを構築したことのある経験者が少ないということです。

jQueryのみの経験だけでは難しいところが多くあります。その対応の一つとして、altJS(CoffeeScript/TypeScript)やCSS Preprocessor(Sass+Compass/Less/Styles) を利用することも必要になります。

このように、Single-page Application(SPA)を開発するための技術要素は多くあります。backbone+Yeoman、Angular+YeomanなどのフルOSSでの開発は、ギークなエンジニアが在籍するシステムインテグレーターでは可能かもしれません。ほとんどの場合そうでないことが多いと思います。特にシステムインテグレーターでない企業ではフルOSS開発は難しいところがあります。ぜひ、html5jエンタープライズ部のセミナーに足を運んで頂き、技術動向や意見交換などに役立てていきたいと思います。

Senchaに関しては、米Sencha社のオフィシャルトレーニングパートナーでもある株式会社ゼノフィでSPAを構築するほとんどの部分のサポートを受けることができます（Senchaは開発環境も含めたオールインワン提供です）。

SPAを実現するために必要な通信技術

「SPAを実現するために必要な通信技術」と題して、NTTコミュニケーションズの仲裕介さんから通信プロトコルの解説、SPDY、WebSocket、WebRTCの概要について、講演して頂きました。内容としてはアカデミックなお話ではありましたが、業務系フロントエンジニアが知るべき通信技術、特にSPAを開発する上では欠かせないもののひとつです。 （スライド）

SPAのメリットのひとつに「サーバサイドとクライアントサイドをより疎結合にできる」ということが挙げられます。通信技術の役割としては、非同期通信を活用することで疎結合が可能になります。

具体的には

• AjaxやCometを利用した非同期通信
• WebSocketを利用した非同期通信

が挙げられます。

現時点では、我々がアプリケーション開発を行う場合、HTTP1.1上でAjaxを使用するというのが一般的と言えます。そして近い将来ですが、クライアント同士のサーバレス通信、つまりブラウザ同士のリアルタイム通信（WebRTC：Web Real time Communication）も実現可能となります。

また、次世代通信プロトコル(HTTP2.0、SPDY)を業務アプリケーションに使用することで、システムのレスポンス向上が期待できます。

SPDYの特徴は、以下が挙げられます。

• HTTPヘッダーの圧縮
• １つのTCコネクションで複数のストリームを扱える
• TLSの拡張仕様であるNext Protocol Negotiationを利用
• サーバプッシュ機能で通信効率化
• ストリームには優先度をつけることが可能
• 対応するためにWebコンテンツへの変更が不要
• 採用実績が豊富
• 効果が発揮できないサイトも有る

Internet Explorer11(windows8.1)はSPDY3対応なので、業務アプリケーションとしてはこれからの技術ではありますが、近い将来エンタープライズでも使われる技術であると言えます。SPDYのpushの必要性は、「この画像が必要」となるということは「このコンテンツも必要となる」であろう。クライアントにリソースを効率的にキャッシュさせるために使われます。

SPDYはドメイン毎にコネクションを張るため、複数のドメインから画像などのリソースを取得する場合は、SPDYを使ってコネクションをまとめても、処理速度が上がらないということもあり得ます。また、効果的にチューニングできるように設定・設置する必要があります。

双方向通信実現のためにWebSocketを使用します。WebScocketの場合は、プログラマブルにpushすることができることや、一つのコネクションで複数のコネクションをはるオーバヘッドをなくすことができます。

WebSocketの特徴は以下です。

• クライアント側、サーバ側での実装が必要
• TLSにてメッセージを暗号化するWSSが利用可能

WebSocket対応のサーバモジュールはSocket.IO、Apache Tomcat 7、Apache-websocket、GlassFish 3.1、Jetty 7、cowboyなどが存在します。NTTコミュニケーションズでは、Jetty 7を使った大規模なWebSocketを使ったシステムを構築しています。

WebRTCはPeer Connectionを行う通信アーキテクチャです。一対一でクライアント同士が通信を行う場合、事前にお互いのIPとポート番号が必要となりますので、シグナリングと呼ばれる仲介サーバが必要になります。

WebRTCの特徴は以下です。

• Signaling
• MediaChannel
• DataChannel
• NAT越え（ICE/STUN/TURN）
• 開発ライブラリはもちろんSkyWay

SPAをうまく構築するための技術要素の根幹は、HTML5です。なので、HTML5をはじめとした新しい技術を活用する必要性が必然に出てきます。HTML5の技術進歩に伴い、通信技術もかなりの速度で進歩しています。SPDYやWebSocketはもう十分に使える技術です。WebRTCなどは今後1～2年の近い将来の話ではありますが、間違いなく利用可能となりますので、今から技術動向を調べ、今後の業務アプリケーションに活かしていきたいと考えております。

Vert.xとSockJSによるスケールアウト

株式会社ゼノフィの代表取締役小堤一弘さん、さくらインターネット株式会社の横田真俊さんからは、「Vert.xとSockJSによるスケールアウトWebSocketサーバー構築」というタイトルで講演して頂きました。（スライド）

SPAに必要なインフラとはなにか？それは

• Webサーバ
• データベースサーバ
• ファイル共有サーバ
• ロードバランサー
• HA構成

ですが、これはいままでのWebアプリケーション構成と変わりありません。非同期通信もAjaxの経験があるので、やはり問題となるところが見つかりません。ただ、WebSocketを利用するシチュエーションでは話が異なります。特に1,000人という単位、10,000人以上の利用者でスケールする場合はどうすればいいのか？ということを考える必要があります。

理論的な資料やサイトはありますが、実際にこういった環境を構築経験した技術者はどれくらいいるでしょうか？やはり経験が重要なので、手を動かす必要があります。経験がないと、思わぬトラブル／設計ミスをし、デスマーチに至るということになります。そして、インフラを担当しているアーキテクチャ担当者と話を進める上でも、フロントエンジニアであろうとも知識としては必要となります。

まとめると、SPAでWebSocketやWebRTCを利用しない限り、今までのWebアプリケーションインフラとは大差ありません。しかしWebサーバに比べ、WebSocketサーバを利用したスケールは、まだまだ経験が足りず、試行錯誤が行われています。

今回デモで使用するVert.xは、JVM上で動作するノンブロッキング・非同期サーバフレームワークです。これはNode.jsの影響を受け作られていますが、Node.jsとは異なる哲学で作られています。様々な言語で書けるサーバサイド技術であり、Node.jsと比較すると処理速度が速いことが挙げられます。

(上記グラフのオリジナルはこちらです)

特徴を整理します。

• ポリグロット：アプリケーションをJavaScript、Ruby、Python、Groovy、Javaなど様々な言語で記述でき、これらこれら複数のプログラム言語を交ぜて１つのアプリケーションを作ることが可能です。
• シンプルな同時平行性モデル：シングルスレッドとして、すべてのコードを書くことができる。マルチスレッド・プログラミングの多くの落とし穴から解放してくれます。そして非同期プログラミングモデルです。
• イベントループ：イベントループによりVert.xインスタンスがサーバ上で利用可能なCPUコアにスレッドの数と一致するスレッドを立て稼働します。そのためCPUコアの活用が可能となります。
• イベントパス：アプリケーション・コンポーネントと簡単に通信することができ、クライアントとサーバにまたがる分散イベントパスを持ちます。このイベントパスを使って簡単にリアルタイムWebアプリケーションを作成することができます。

SockJSは、Socket.ioのようにWebSocketが使えない環境でもエミュレーションし、抽象レイヤーになるものです。Sock-clientは様々なブラウザにWebSocketをはじめ、Streaming/Pollingで対応しています。

(github.com/sockjs/sockjs-clientより)

エンタープライズ系エンジニアが、Vert.xを利用するのは容易であると考えています。Javaでサーバサイドが記述できるためだからです。そして、Hazelcastによるインバウンドバススケールアウトは、容易にかつ無停止でスケールすることが可能です(Hazelcastは、Javaベースのキャッシュとクラスタ、そしてデータ配信のソリューションです)。

また、SockJS Serverを内蔵しており、実装しやすく、WebSocketのインフラを容易に構築できます。実用的でもあり、現状多くの企業で利用されています。一台あたり5,000〜6,000件のアクセスを処理し、スケールを取るのが一般的です。

デモは「さくらのクラウド」を利用して行われました（デモンストレーションに関しては、セミナーのみの限定公開です）。いつものように（？）さくらインターネットの2万円分のクーポン券を頂きました。

SPAに必要なJavaScriptフレームワーク

「SPA に必要なJavaScriptフレームワーク」というタイトルで、html5jエンタープライズ部の酒巻瑞穂さんから講演して頂きました。今回のテーマはJavaScriptフレームワークの中から、backbone、AngularJSそしてSencha Ext JSについてです。（スライド）

Single-page Applicationのpageとは、そもそも何でしょうか？SPAでアプリケーション開発する場合、pageとviewの概念を知ることが重要です。pageはいくつかのviewを取りまとめたものです。具体的には、pageとはほぼ決まっている固定部分のことであり、view（コンテンツとも言う）は使用するユーザや状況によって変わる部分のことを言います。

pageをviewに分割することで、再利用性とパフォーマンスを向上させます。そしてviewがやるべきことは以下です。

• 描画(UI)
• UIとBLSの同期
• BLS
• ルーティング
• 状態管理
• リソースアクセス

SPAにおけるサーバとクライアントの役割を整理します。従来型のWebアプリケーションとの違いは、UIの処理、状態を定義するのはサーバでした。

ここで整理した事項は、view単位で処理が行われます。こうするとviewで行う処理そのものが増え、しかもいくつかのviewを合わせたpageはレイヤーの整理をしなければ、到底実装不可能になります。そして、これだけ多くのことを考えJavaScriptでコーティングしないといけません。jQueryのみで実装しなさいというのはカオスになり、デスマの世界へ入り込みます。そのためにもJavaScriptフレームワークを使用し、構造的整理をしなければなりません。

backbone、AngularJS、そしてSencha Ext JSについて次の観点で解説しました。

• DOMへのアプローチ
• ルーティング
• 状態管理
• ビジネスロジック
• モデルとビューの同期
• 外部リソースへのアクセス方法

比較については、それぞれのフレームワークを、なるべく近い土俵であるMVP・MVCパターンで構築した例を挙げます。
どのような特徴があるのか、以下の表にまとめてみました。

並べてみると、以下のような特徴が見えてきます。

AngularJS
依存性注入による、定形なソリューション構築を容易にする仕組み。
宣言的UIの容易な構築、暗黙的データバインディングのModel/Controllerとの疎結合による、UIの変更を受け入れやすい仕組みがあります。

Bakcbone
MV～パターンを提供するにあたり、必要最低限な機能のみが標準で提供されます。それ以外は自由に選択、拡張できる汎用性フレームワークでの縛りが緩く、使用するライブラリや目的に応じて、MVCもMVPも選択肢として取り入れることが可能です。

Sencha Ext JS
UIからロジック、通信まで、HTML5アプリケーション開発で必要な機能が、ほぼフレームワークで提供されており、強い堅牢性を持ちます。しかしながら、目的に応じた柔軟性も合わせ持っています。

最後に、まとめとして大まかな違いを示します。

最近ではMV*議論をすることにあまり意味がないのでは？という指摘もあります。議論よりも触ってみるというのが重要と思います。

最後に

懇親会で行われたLTは以下です。

• WebSocketを利用したSPA事例とデモ@stakezakiさん
• MVC5+Bootstrapで作るSPA with Office365アカウント(+Google, FB, Twitterアカウント) 野呂清二さん
• セミナー告知 小島 勝茂さん

今回のセミナーではSingle-page Application(SPA)に特化したものでしたが、周辺技術も含めた内容のため、かなり濃いものとなりました。2014年はHTML5が本格的に利用される年です。どのようにすればHTML5技術を活用でき、そこに潜む技術はどういうものかが明確になったのではないかと考えています。数年前までの技術革新とは比べ物にならないほど多くの技術が利用可能であり、しかも実現性のある技術が「乱立」しています。一つひとつの技術を冷静に精査し、業務アプリケーションを構築するという意味合いにおいて、自分たちの置かれている状況や環境を冷静に見つめ直す時期ではないかと思います。

今回のセミナーが、エンタープライズを愛するすべてのエンジニアの糧になればと考えております。html5jエンタープライズ部は様々なテーマ今後もセミナー、ハンズオン、カンファレンスなどを行って行く予定です。「先進性より安定性」「日本+モダンWeb」「国内から世界へ」をキーワードに活動の場を広げていきたいと考えております。乞うご期待！