最近は、WebAPI や AWS のようなクラウドサービスが普及してきて、バックエンドのサーバーがなくても、Web サービスが公開できるようになってきました。

今回は AWS の**S3 にある Static Website Hosting 機能**を使って AngularJS で作成した SPA(Single page application)をホスティングさせてみました。

割と S3 でのサイト公開は簡単なので楽勝かと思いきや・・・  
いろいろまじめに考えると手こずるものですね。



## S3 での SPA 公開

S3 でのサイト公開は非常に簡単です。次の 3 ステップで即公開できます。  
(「S3 サイト公開」などで検索するといくつか記事がヒットすると思いますので参考にしてください。)

- S3 上に Bucket を作成する。
- AngularJS で作成した SPA をアップロードする。
- Bucket の Static Website Hosting を ON にする。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-s3-cloudfront-1.png)

Static Website Hosting を ON にすることでアクセス可能な URL が取得できます。  
アクセスした際に「`AccessDenied`」エラーになる場合は、アップロードしたファイルの`Permissions`が**Everyone アクセス可能**になっていないことが多いです。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-s3-cloudfront-2.png)

しかし、この**Everyone アクセス可能**状態はあまりいい状態ではありませんので、CloudFront を利用します。  
(後で紹介しますが、S3 は CloudFront 経由のアクセスのみ有効にする設定を推奨します。)

> S3 の Everyone アクセス可能は Apache の設定漏れで、ファイル一覧が見えてしまっている感覚に似ていて落ち着きません w

他にも、S3 で公開した場合に問題になりそうな部分について紹介します。

## S3 での SPA 公開で問題になりそうなところ

S3 の Static Website Hosting 機能はお手軽で非常に魅力を感じるのですが、Web アプリケーションを想定した場合、次のような問題がありそうです。

- アクセスを`HTTPS`に限定できない。
- URL に「`/`」を指定した場合、S3 上のフォルダを参照してしまいエラーとなる。(結果「`/index.html`」まで含める形に・・・)
- 「`/`」以外の URL(「/hoge」とか)でアクセスした場合に`403(access denied)`エラー(2015/01/20 追記)
- 他にもあった気がするが、忘れた。

という訳で S3 のみのお手軽ホスティングは、コーポレートサイトのような静的コンテンツ向きな気がします。

## CloudFront の利用

そこで利用するのが CloudFront です。いろいろ探していたら、こちらの記事が参考になりました。ありがとうございます！

[[CloudFront + S3]特定バケットに特定ディストリビューションのみからアクセスできるよう設定する ｜ Developers.IO](http://dev.classmethod.jp/cloud/aws/cloudfront-s3-origin-access-identity/)

手順としては次のような形です。

- CloudFront 上に Distributions を作成
- Origin Domain Name に S3 の Bucket を指定
- Restrict Bucket Access で「Yes」を設定して S3 へのアクセスを制限

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-s3-cloudfront-3.png)

これで CloudFront 経由で S3 へアクセスすることができますが、SPA をホスティングするに当たって追加で以下の設定をしました。

### General > Default Root Object

`Default Root Object`に「index.html」を設定します。これで「`/`」でアクセスした際に、エラーにならず「`index.html`」を呼び出すことができます。

しかも、デフォルトの(\*.cloudfront.net)ドメインであれば SSL 証明書までついてきます。  
まじで至れり尽くせりです。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-s3-cloudfront-5.png)

### Behaviors > Viewer Protocol Policy

新しい Behavior を作成して`Viewer Protocol Policy`にて`Redirect HTTP to HTTPS`を選択します。これで HTTP でアクセスされた場合に、HTTPS にリダイレクトすることが可能です。  
(あまりこだわりなければ`Path Pattern`は`Default (*)`1 つで事足りるはず。)

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-s3-cloudfront-4.png)

## CloudFront 利用上の注意点

CloudFront を利用すると幸せになれるのですが、1 点注意点があります。それは**キャッシュ**です。

CloudFront の本質は CDN なので、コンテンツをキャッシュします。しかもデフォルトでは**24h キャッシュを保持**するので、S3 上にアップロードしたファイルは最大 24h 変更されません。

### Invalidations を利用して Cache をクリア

CloudFront には Invalidations というキャッシュクリアをする仕組みがあるので、これを使って CloudFront に対してキャッシュのクリアを指示します。  
(ただ、5〜10 分くらいかかります。リアルタイムではないです。)

CloudFront で Distributions を選択すると「`Invalidations`」というタブがあるので、ここで「`Create Invalidation`」ボタンをクリックします。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-s3-cloudfront-6.png)

クリアするファイルを指定する必要があるので、例えば「`/index.html`」とか入力します。  
私の場合、フロントのリソースは結合＆minify＆バージョニングして最適化してしまうので、普段は`index.html`だけで十分です。

あとはキャッシュがクリアされるまで気長に待ちましょう。

## まとめ

「S3 ＋ CloudFront」を使うことでお手軽に AngularJS で作成した Web アプリケーションをホスティングすることができました。しかも勝手にスケールするし、クラウドサービス偉大過ぎます。

### しかし、上には上がいる！

今回の「S3 ＋ CloudFront」はまだ**大関**構成なようですね。個人的には頑張ったと思うのですが。。。orz  
こちらの記事を読むと、この上の「S3 ＋ CloudFront ＋ Route53」**横綱**構成があるようです。

[AWS における静的コンテンツ配信パターンカタログ（アンチパターン含む） ｜ Developers.IO](http://dev.classmethod.jp/cloud/aws/static-contents-delivery-patterns/)

もっと稽古します。

> (2015/01/20 追記)  
> `/`以外の URL でアクセスした場合に`403(access denied)`エラーになるのですが、CloudFront Distributions の Error Pages 設定で、403 エラーの場合のエラーページを`/index.html`にすることで回避することができましたー。  
> うぇーーーーい！！って無理矢理感が半端ない w

AngularJSで作ったSPAをAWS上の「S3＋CloudFront」でお手軽ホスティングして、クラウドサービスってやっぱ素晴らしいなと思った話

先日、HTML5j エンタープライズ部のメンバーと最近気になっていた Flux アーキテクチャについて味見してみました。
巷の AngularJS のサンプルは ES6 で書かれたもの多いので、実務でも使える ES5 で書きなおしてみました。

- デモはこちら [Angular Flux ES5](http://mitsuruog.github.io/angular-flux-es5/)
- コードはこちら [mitsuruog/angular-flux-es5](https://github.com/mitsuruog/angular-flux-es5)



Flux の概要については[@albatrosary](https://twitter.com/albatrosary)さんのブログを参照してください。

[What’s Flux? - albatrosary's blog](http://albatrosary.hateblo.jp/entry/2014/10/22/131302)

## 雑感

フレームワークの書き方が一通りわかると、次はもっと効率的に書くにはどうするかとか考え出します。
Backbone の時もそうだったのですが、SPA でフロント側を作った場合、model の変更を複数ある view 側にどう伝えるのがいいか、悩んで手が止まります。
(Backbone の時はグローバルの Mediator を通して model の変更を通知してました。当時の残骸はこちら[mitsuruog/SPA-with-Backbone](https://github.com/mitsuruog/SPA-with-Backbone))

AngularJS の場合は`shared services`を使うか、`$rootScope.$broadcast`を使うことが王道かなと思います。
個人的には`shared services`の方が小さくて好みです。

[AngularJS - Angular JS で複数のコントローラ間でモデル（状態や値）を共有する方法 3 種類 - Qiita](http://qiita.com/sunny4381/items/aeae1e154346b5cf6009)

Flux アーキテクチャを使った場合は、Angular way にならないので、これはこれでありかなと思いました。
ただ、Observer の制御を間違えるとメッセージパッシングが無限ループしだして死にます。(参加メンバーはもれなく無限ループを体験していました w)

## まとめ

Angular の場合は、無理して Flux 使うより`shared services`の方がコードは読みやすくなると思います。
そろそろ SPA のアーキテクチャについても、かなり出尽くした感がしますね。

話題のFluxアーキテクチャをES5のAngularJSで書いてみた

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

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

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



![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/spa.png)

### 目次

## 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](http://sap.github.io/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](http://www.yearofmoo.com/2012/11/angularjs-and-seo.html)

### 7.2 認証・セッション管理

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

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

## まとめ

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

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

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

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

### p.s

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

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

[「SPA を構築するときに知っておいた方がいい 7 つの課題」は課題ではない](http://albatrosary.hateblo.jp/entry/2014/01/15/121608)

**あわせて読むといいかも**

- [2013 年は SPA の年・・・になるといいなぁ - new takyam();](http://new.takyam.com/entry/2012/12/30/2013%E5%B9%B4%E3%81%AFSPA%E3%81%AE%E5%B9%B4%E3%83%BB%E3%83%BB%E3%83%BB%E3%81%AB%E3%81%AA%E3%82%8B%E3%81%A8%E3%81%84%E3%81%84%E3%81%AA%E3%81%81)
- [Pros and Cons of Having a Single Page Website – Professional Dubai Web Design Blog by Insight Soft in UAE](http://blog.insightsoft.ae/a-single-page-website/)
- [Isomorphic JavaScript: The Future of Web Apps - Airbnb Engineering](http://nerds.airbnb.com/wp-content/files_mf/1384225374isomorphicjs.png)
- [Advantages and disadvantages of building a single page web application - Programmers Stack Exchange](http://programmers.stackexchange.com/questions/144717/advantages-and-disadvantages-of-building-a-single-page-web-application)

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

先日めでたく 1.0.0 をリリースした Backbone.js ですが、よくも悪くも「どう作るか」について、作成者側の思いで自由にできるため、始めの取っ掛かりとして、どう作ればよいかと言うことで結構悩む方も多いかと思います。

そこで、同じように悩んでいる人になんらかのヒントを与えられればと思い、シングルページアプリケーションを題材にチュートリアルを作成して公開してみました。
また、私が Backbone.js でアプリケーションを作成する上で、特に View について注意するポイントを幾つか紹介します。



何かの参考になれば幸いです。

### このエントリでお伝えしたいこと。

1.  Backbone.js のチュートリアル作りました。
2.  Backbone.View を扱う際に注意するポイントについていくつか紹介します。

## チュートリアル

早速ですが、Backbone.js でシングルページアプリケーションを作成するチュートリアルの紹介です。

このチュートリアルでは、よくある Tweet 検索アプリケーションを作成しています。

[https://github.com/mitsuruog/SPA-with-Backbone](https://github.com/mitsuruog/SPA-with-Backbone)

次からは、View について注意するポイントを幾つか紹介します。

## 1. 異なる View 間の連携はイベントベースで行う

Backbone.js でアプリケーションを作成する場合、いつくか View を分ける場合が多いのですが、次のようにトップレベルの View にて、他の View のイベントをハンドリングして処理を振り分けるコントローラ的なロジックを実装している例を時々に見かけます。

アプリケーション自体が比較的大きくない場合は、この実装方法でも大丈夫だと思います。
しかし、規模が大きくなり関係する View が増えた場合、コントローラのロジックが肥大化して View のサイズが大きくなる要因となりますので、私はあまりおススメしません。

```js
initialize: function () {

  //他のViewのイベントをハンドリングしてレンダリングする
  this.someView.on('chage:some', this.render);

},

render: function(){

  //他のViewへレンダリング指示
  this.anotherView.render();

}
```

Backbone.js には`Backbone.Events`というカスタムイベントをバインドしたり、発火させたりできる強力な仕組みが備わっていますので、これを使いましょう。
実装する際は、`Backbone.Events`を`_.extend()`して使います。

```js
//Backbone.Eventsのクローン
_.extend(mediator, Backbone.Events);

//イベントの発火
mediator.trigger("change:some", param);

//イベントのハンドリング
mediator.on("change:some", this.behavior);
```

このように View 間の連携をイベントベースで行うことの忘れてはならないメリットは、View 間の不要な依存関係を排除することで、各 View にてイベントを起点にユニットテストを行うことが出来ることです。

## 2. レンダリングはデータの変更を先に行う

レンダリングに際しては、順序に一貫性を持って行います。

> ユーザの操作 →Collection や Model の変更 →View のレンダリング

チュートリアルの検索ボタンクリックから検索履歴表示部分を例としてお話すると、次のような流れになります。

1.  検索ボタンをクリックする。
2.  検索キーワードを Collection に追加（データの変更）
3.  検索履歴 View をレンダリング

```js
initialize: function () {

  //他のViewからのModel追加依頼
  mediator.on('add', this.addSome);

  //Collectionのaddイベントをハンドリングしてレンダリング処理を呼び出す
  this.listenTo(this.collections, 'add', this.render);

},

addSome: function (some) {
  //CollectionにModelを1件追加する
  //追加した場合、addイベントが発火する
},

render: function () {
  //レンダリング処理
},
```

このように、ユーザの操作からレンダリングする間にデータの変更を挟むことによって、やってしまいがちな、ユーザの操作とレンダリングが 1 つになった、テストしにくいスパゲッティ function の作成を抑止できます。

## 3. その他、細々したこと

その他、知っておいたほうがいいポイントを紹介します。

### 3-1. Collection や Model のイベント監視には.listenTo()を使う

View が管理する Collection や Model のイベントハンドリングには従来`.on()`を使用してきましたが、0.9.9 以降は`.listenTo()`を使います。

```js
//.on()を使ったバージョン
this.collections.on("reset", this.render);

//.listenTo()を使ったバージョン
this.listenTo(this.collections, "reset", this.render);
```

これは、`.on()`でバインドしたイベントが（Model などを）`.remove()`した際に、アンバインドされずメモリリークを起こしてしまうためです。

### 3-2. initialize で\_.bindAll(this)を使う

1.のようにイベントベースで実装を進めた場合、結構ストレスに感じるのが javascript 特有の`this`の問題です。View の`initialize()`で`_.bindAll(this)`することで、View の中の this がすべて View 自身を指し示すようになるので、実装が楽になります。

```js
initialize: function () {

  bindAll(this);

  //なにかの処理

},
```

## 最後に

私が考える Backbone.js でのアプリケーション方について一通り説明しました。

最近のフロント系勉強会の動向を見ていても、Backbone.js はかなり注目されているクライアント MVC フレームワークの 1 つだと感じています。
また、先日 Backbone.js の 1.0.0 リリースしたこともあり、これから 2 ～ 3 年でネットサービス系を中心に普及期に入ると思います。  
これから始める方にとって、このエントリの内容が有意義なものであることを願っています。

**（余談）**  
このチュートリアルは、SI の中規模の開発案件にて Backbone.js を採用しよう夢見ていた時期があり（諸事情にて断念・・・orz）、大勢のエンジニアで Backbone.js を使った場合、どのようにガイドを作成したら均一に作れるか思索したものの残骸です。

Tag: spa

AngularJSで作ったSPAをAWS上の「S3＋CloudFront」でお手軽ホスティングして、クラウドサービスってやっぱ素晴らしいなと思った話

話題のFluxアーキテクチャをES5のAngularJSで書いてみた

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

Backbone.jsともっと仲良くなるためのヒント