読者です 読者をやめる 読者になる 読者になる

そろそろBackbone.jsでの開発について一言いっておくか(・ω<)

何かなりゆきで Backbone.js Advent Calendar 2012 の9日目を書くことになった。というわけでbackbone.jsです(・ω<)

backbone.jsはクライアントサイドのMVCフレームワークですが、いわゆる既存のサーバサイドフレームワークでいうとこのMVCとは少し違います。まあその辺について書かれたエントリは色んな所に転がってるのでググってくれ(・ω<)

さて、backbone.jsを導入することによってWebアプリの開発がどう変わるのかもう一度整理しておこう。

サーバサイド、フロントの分業の確立(・ω<)

  • 従来型のサーバサイドMVCでの開発スタイルだと、できあがったマークアップをサーバサイドのプログラマがテンプレ化し、動的部分を実装していく。ただ、マークアップも開発しながら変わってゆく。テンプレを作る側に十分なマークアップに疎ければ、微妙なデザイン崩れを起こしてしまったり。逆にテンプレートに対してHTMLコーダーが手を入れる場合、サーバサイドのテンプレートエンジンに慣れていないと難しい。これがbackbone.jsによって、サーバサイドはJSONAPI開発に専念でき、デザインとテンプレートはフロントサイドのコントロール下に置かれるため分業が促進され、各々の役割は明確になりやすい。

フロントサイドが享受する恩恵(・ω<)

  • 従来型だと、フロントサイドのエンジニアもサーバサイドの環境を用意する必要があった。システムによっては諸々のミドルウェアの導入が必要だし、サーバサイドでトラブった場合はフロントの開発が止まることだってあるだろう。backboneでの開発であれば、最低限のものとしてAPI仕様とJSON仕様が決まっていれば十分開発が可能で、基本的にサーバサイドの環境に足を引っ張られるということはない。ローカルにapacheかnginxをインストールするくらいだ。
  • プレゼンテーションロジックはJSで実装でき、テンプレートへのインプットもJSONであるためフロントエンジニアにとって扱いやすい。フロントがサーバサイドの言語を意識する必要はない
  • 無秩序に行われがちだったJS開発に新しいスタイルを提供する。ロジックやViewのコンポーネント性を高め、UIは最適化されやすくなる。クライアントMVC無しの開発は、某Pのつく言語のカオスな開発ヽ(`Д´)ノ と同じと言ってもよい。

サーバサイドが享受する恩恵(・ω<)

  • テンプレートを意識する必要がなくなるので、テンプレートの学習コストを気にする必要がなくなる。
  • Controller層がスリムになり、レスポンスがJSONなのでテストの書きやすく、検証が容易になる。
  • サーバサイドをJavaで構築しているアプリなら恩恵はさらにある。Javaは非常に高速であり、文字列処理も優秀であるが、ことテンプレートエンジンの性能についてはPのつく言語やRubyの後塵を拝している。言語としての速さがテンプレートエンジンを使ったhtml出力の性能に直結していない(JSP、Velosity、FTL等)のだ。サーバサイドからのテンプレートの排除によって、Javaにとっては非常に追い風だ。むしろPのつく言語の有意性なんてテンプレートエンジンくらいなので、Pのつく言語を卒業する理由づけの一つにできるだろうw
  • ついでにScalaのことを言っておくと、PlayのScalaテンプレートはHTMLコーダーには優しいとは言えないが、APIでJSONを返すだけであればScala導入の敷居も下がるだろう。lift-jsonやunfilteredの出番もありそうだ。


こんなところだろうか。では、この特性を活かすための開発の戦略はどうだろう。

API仕様書を用意せよ(・ω<)

  • このbackboneでの開発において、フロントサイドとサーバサイドの橋渡しとなるのは「API仕様」に他ならないので用意する。フォーマットはなんでも構わないが、Excelやgoogleスプレッドシート等、チームに合わせた共有のしやすい方法を選ぶとよい。サーバサイドのプログラムのメタデータをリバースして、仕様書を作るというのもありだろう。
  • フォーマットの項目として以下のようなものがあると良い。
    • APIエンドポイント
    • 機能、処理概要
    • HTTP method
    • リクエストパラメータ。必須項目や、データ型があれば良い。
    • JSONレスポンスのサンプル。jsonlintとかで予めフォーマットしたものを貼り付けておくと親切。
    • その他特記事項

サーバサイドをうまく巻き込め(・ω<)

  • これまでサーバサイドでやっていた役割をフロント側で担うことになるが、だからといってフロント側が独立して好き勝手に開発していいわけではない(サーバサイドも同様だ)。双方が認識すべき最低限の指針を用意しておこう。ただし、指針はプロジェクトによっても違うし、対象がPCのブラウザアプリなのかスマホのブラウザアプリなのかによっても変わってくる。
  • スマホアプリのようにフロント側のパフォーマンスが重視される場合は、サーバサイド側に協力を仰げる体制を作っておこう。このケースの場合、APIリクエストの数やJSONのフォーマットについてはフロント側の要望が優先されるべきだ。つまり、サーバサイドにフロント側のチューニングに関して理解のある担当者を置くことが重要だ。
  • JSの機能実装やテンプレートの実装はこれまでサーバサイドでやってきたことなので、サーバサイドのリソースをフロントにアサインさせることの敷居は非常に低い。backbone.jsは非常にシンプルな構造になっており(github見てね)、1日あれば十分戦力化できるだろう。よって、リソース配分は柔軟に対応できる。
  • アプリがCRUD的なり定型的なものであれば、多くのコードは自動生成することができるだろう。これもbackbone.jsによって定型化されやすくなったというのが非常に大きい。


書き出せばまだまだありそうだが、こんなところにしておこう。Backbone.jsはまだまだ新しいフレームワークだが、導入もしやすく、決してめちゃくちゃ先鋭的なものでもないので、今導入しても決してリスクは高くないし、無謀な冒険ではないことを強く推しておこう。てか、高速に良いものを作りたいのであれば導入すべき。絶対(・ω<)。