シングルページアプリケーション（SPA）は、いま注目を集めているWebアプリケーションのアーキテクチャです。
vte.cxでもSPAを推奨しており、ReactやAngularなどを自由に使用することができます。
実際にAngularJSで構築した事例もあります。
しかし、大規模プロジェクトにおいてSPAを採用す場合にはよく考える必要があると思っています。
今年、ある大規模プロジェクト（開発者50人以上、1年間）に携わったのですが、SPAを採用することはどうしてもできませんでした。
今日はこの話をしていきたいと思います。
#一応、様々なフレームワークを検討してみた
Reactは個人的に興味のあるフレームワークで、ぜひ使ってみたいと日頃から考えてはいますが、デザイン(HTML、CSSを含む）を別会社に外注しているので無理でした。別会社にJSXを書いてとは到底いえません。
AngularJSであれば実績もあったので提案すれば採用されたかもしれません。
しかし、私はそれも提案しませんでした。
それは、よくいわれるSEOの問題じゃなく、主に学習コストの理由からでした。
- 開発者のスキルがそれほど高くなく、SPAの開発経験者もいなかった
- 第一次フェーズの納期が数ヵ月と短かった
- シングルページを複数人が共有して開発する方法がわからなかった
#新技術はリスク要因として捉えられることもある
エンタープライズな案件で優先されるのは納期と品質です。
世の中を見てもSPAの大規模な事例は少なく、数人で数ヵ月とか、それぐらいの規模がほとんどです。
数人ならまだしも何十人もの開発者をゼロから教育する余裕はありません。
一番恐れたのは新しい技術を消化できずに手が止まってしまうことでした。
十分な開発期間があり、新しい技術に精通した技術者がいて、常にフォローしてくれるような環境であればまだ考える余地はあったかもしれません。しかし、開発期間は数ヵ月しかありません。フォローできるスペシャリストもいません。
納期を考えると、新しい技術のメリットを取るよりも新たなリスク要因を排除すべきだと思いました。また、同じ理由でTypeScriptも、ES2015やES2016+も採用していません。
#jQueryで普通のWebアプリケーションという選択肢
開発者の皆さんは、jQueryであれば経験があるといいます。ここはオーソドックスにjQueryを採用するしかありませんでした。
つまり、SPAをあきらめ、普通のWebアプリケーションにせざるを得なかったのです。
(つД｀)・ﾟ
jQuery不要論が叫ばれているのは知っています。
多分、それはエンタープライズの現場を知らない人がいっているのでしょう。まだまだjQueryは必要なのです。今は2016年です。
異論のある方は、まず2016年にJavaScriptを学ぶとこんな感じを読んでみてください。
バックエンドに戻ることにするよ。こんなに多くの変更やバージョンやエディションやコンパイラやトランスパイラを僕には扱えないよ。こんなのにずっとついていくなんて考えられないよ、JavaScriptのコミュニティは狂ってる。
それでも反論できる者のみ石を投げてください。
ちなみに、vte.cxでは、npmとgulpは使っています。
#いかに並行に開発して生産性を高められるかの方が重要
一方で、開発者にいかに効率よく作業してもらうかが重要になります。
短納期ですが人数はたくさんいるからです。
SPAを諦めたおかげで画面単位に分けることは簡単にできます。
なので、ここはシンプルに画面単位で担当割りをすることにしました。
それに、SPAではないものの、サーバはAPIを提供する疎結合なアーキテクチャーになっています。つまり、サーバ側では画面のレンダリングを一切行わず、静的なコンテンツを返すか動的なデータをAPI経由で返すだけです。
各画面担当者はクライアント側だけで実装できるため、他の画面担当者のことを気にせず並行で開発を進められます。
ところで、今回、採用してよかったと思ったのはGitlabです。
各担当者がfeatureブランチを切り、テストが終わったものをdevelopブランチにマージ、リリースはmasterブランチから行うという、いわゆるgitフローが徹底されるようになりました。
このgitフローによって、複数人による同時並行開発が混乱なく進められたのは大きかったと思っています。
#vte.cxによる並行開発の実際
ただ、サーバ側のAPIがFIXできていないといろいろと問題になりますし、各自が自由にAPIにアクセスできる開発環境も用意してあげないといけません。
そこで、vte.cxの登場です。
vte.cxではマルチテナントになっており、各自が独立したサービスを立てることができます。また、サーバサイドJavaScriptによりAPIのモックを作成できます。
vte.cxでは、HTMLやCSS、JavaScriptといったフロントエンドのコードと一緒に、サーバのコード(JavaScript)も同時にDeployします。実体は/serverフォルダにJavaScriptファイルがあるだけです。
一方で、フロントエンドのローカル開発環境では、いちいちサーバにデプロイする必要はありません。gulp serveコマンドでローカルproxy環境を起動するだけです。
APIはproxyによりリモートサーバのモックAPIにつながるので、サーバサイドの本番環境と同じ動作を期待できます。
フロントエンドの画面ではJavaScriptでモックAPIに対してリクエストするように実装していきますが、フロントエンドのローカル環境では手元のJavaScriptなどを更新したらすぐに画面を確認できるのでサクサク開発できます。実際の開発については、【vte.cx入門】2.ローカル環境でHTMLを編集するを参照してください。
これは、RailsやPHPなどのサーバサイド言語を使わないで、APIモックだけで開発できるvte.cxの環境だからこそ実現できる世界です。
この高い生産性、サクサク感に慣れたらもう元には戻れません。
ということで、また明日。