昨日まで開催されていた「IVS CTO Night & Day」でのとある一幕。100人もしくはそれに近い人数の、有名ドコロWebサービスなCTO達が集まる中、挙手制のこんな感じのアンケートがあった。
フレームワーク使ってますか？それとも独自？
印象的だったのは「独自だぜ！」という人が割合としてかなり少なかったこと。その件について個人的な見解を書いてみます。ちなみにこちらはWebアプリエンジニア養成読本 Advent Calendar 2014の9日目の記事です。
フレームワークと言っても色々な解釈の仕方があります。種別で言えば「Webアプリケーションフレームワーク」が一番に焦点が当たるところなんですが、それに内包される、もしくは、独立して「O/R Mapper」のようなフレームワークもあります。粒度やレイヤーで考えないといけない。なので、今回の質問に回答する場合、どこの層でフレームワークを使っているのか？オリジナルなのか？を定義しないと答えにくいかもしれません。ただこの件を追求するとエンドレスな議論になりそうなんで、一旦休止。
僕の場合は「比較的」という意味合いで「独自だぜ！」の方に手を上げたのですが、Webアプリケーションフレームワークを使っているところもあれば、独自にWebアプリ層を組んでいるサービスもあります。また、今の自分が置かれている状況だと、開発者の人数が非常に少ないので、僕個人が使いやすいという判断で技術導入をしている理由で、フレームワークを利用するかどうかにこだわる必要はあんまないっす。会社の規模がある程度大きく、技術者がも多ければ、フレームワークを使うことでAPIを含め、共通のしきたりを素早く共有出来るでしょう。その場合、既存のフレームワークを使うのは効率的です。
ここで、中間まとめ。つまりフレームワークを使うかどうかに関しては
- どのレイヤーについてのフレームワークかどうかを意識する
- 開発チームの規模によって判断基準が異なる
- アプリケーションの性質によっても同様
かと思います。また、初心者が学習すると言った目的の場合は一旦フレームワークを使ってみてその機能がどう挙動するか、感覚をつかむとう意味もありそうっすね。
参考として、僕が今でやっている試みを紹介します。ちなみにバックエンドの言語は「Perl」を全面的に使っています。
当初はアプリケーションレベルでモデル層をWeb層から切り離す程度の施策をしていて、モデル単体のテスタビリティをあげつつ、Web以外のCommand Line Interface=CLIからの呼び出しにもモデルを利用可能にしていました。それ前提でWeb層ではCatalystやMojoliciousと言ったWebアプリケーションフレームワークを活かします。また、DB周りは特殊で、参照系は独自のライブラリ、更新系はDBIx::Skinnyという非常に薄いO/R Mapperとも言えないほどのモジュールを使います。サービスの性質上、やはりSELECTが多いので、そこをオプティマイズする形です。結果として
- DBアクセス機能 / DBI＋α
- クエリビルダー / SQL::Maker
- inflateもしくはdeflate / 自分で書いたフィルター
- アプリケーションでのキャッシュ / Cache::Memcached::Fast
を組み合わせた一つのアプリ専用のライブラリが出来ました。これが「独自のライブラリ」ってやつです。ちょいとダーティなコードになっていますが、うまく機能しています。
それに加えて現在では、モバイルアプリも含めた各サービスごとにそれぞれHTTPをしゃべるWeb層をつくって個別にアクセスするのではなく、一つの、もしくはMicroservices的に複数のAPIサーバのようなものを立ち上げ、フロントエンドが要望に応じてそれぞれから情報を取得したりポストする構成にしています。例えば、コアのロジックはJSONRPCをプロトコルとして、今まで書いたモデル層を生かして、サービスとして立ち上がっています。Webをつくるにしても、一度そこのMethodを叩くような設計です。このアーキテクチャにより
- JSONRPCサーバの結合的なテストさえ通ればある程度品質は保証される
- ロジックの出力がJSONで扱えるのでテストが容易
- フロントエンドはモバイルも含め、どんな言語でも、どんなフレームワークでも実装してOK
となります。今回のテーマである「フレームワークを使うべきか？」という視点で考えると、コアのロジックサーバは僕がJSON::RPC、OAuth::Lite2、Router::Boom、及びPlackで組んだアプリケーションになっていて、責任もって管理する。ちなみにこれらは単体ではフレームワークとは言えないにしろ、各種ライブラリをPerlらしくグルーとしてつなげたものになっています。他のフロントに関しては実装する人によって、好きなフレームワークを使ってもいいですよ、という体制が組める。フレームワークを使った方が「素早く開発出来る」パートーナーがいた場合には有効でしょう。
まぁこうやって振り返ると「フレームワークなんて使わず全部オレオレだぜ！」とも言えず、やはりハイブリッドにやっています。CTO Night & Day の当日、はてなのCTOであるstanakaさんが話していた通り、何かあった時のために「中身を見て理解し、解決出来る」ようなフレームワークなどを選定するのも重要だと思いますし、先ほどまとめた通り、選定基準は千差万別です。ユーザーのことを意識してサービスを考えるように、サービスの開発に関わる内部についてもそれに関わる開発者や自分自身を意識して「今後」制作しやすいようにアーキテクチャを組むことが求められるのでしょうね。