4月9日、テキサス州オースティンのBalderdashがnode.js上で動作するリアルタイムMVCフレームワークであるSailsのバージョン0.8.9を発表した。これは、Railsライクな開発環境をモダンなウェブアプリの世界に持ち込もうとする試みだ。
Railsの誕生から8年たち、BalderdashのチームはMITライセンスのSailsをさらなる進化の一歩として構想している。Railsのリッチな開発体験とリアルタイムウェブの能力を組み合わせようとしているのだ。
InfoQはSailsの作者であるMike McNeil氏に詳しい話を聞いた。
INFOQ:Sails.jsはnode.jsの他のリアルタイムフレームワーク(Meteor, Derby, SocketStream)と比べてどうですか。
Mike:Sails.jsを開発したのは、私が顧客に効率良く安定したNode.jsアプリケーションを提供するためです。既に利用実績のあるツールを使って、ベストプラクティスを構築するのが私たちの方法です。例えば、LearnBoostが作成した2つの素晴らしいフレームワークに依存しています。サーバプッシュにはSocket.ioを使い、ウェブルーティングとテンプレーティングにExpressを使っています。ExpressはNode.jsの最も人気のあるフレームワークです。どのような場合でも、車輪の再発明は避けようとしています。
とはいえ、独自のコンポーネントがないというわけではありません。ORMは独自に開発しました。おそらく、Sailsの最大のオリジナルコードでしょう。また、WebSocketコードの扱い方も独自の方法を採用しました。別のコードベースをメンテナンスしてリアルタイムのメッセージングを処理するのではなく、通常のAPIを処理するのと同じコードで扱うようにしたのです。つまり、WebSockets向けのプロジェクトでもHTTP向けのプロジェクトでも完全にExpressのコードで出来たプロジェクトになるということです。
Balderdashを立ち上げてから初めて、決定を実現することの重要さに気付きました。私たちは1ヶ月かからないうちに、300,000ユーザが利用できるAPI駆動のリアルタイムバックエンドを構築できました。このシステムはBox.net APIを反映していますが、リアルタイムでファイルの更新をブロードキャストできます。
INFOQ:Meteorが一番人気ですが、Meteorとの違いや類似点について教えてください。
Mike:MeteorとSails.jsでは解決しようとしている問題が違います。Meteorは全く新しいリアルタイムウェブアプリケーションフレームワークを作成しようとしています。Sails.jsは開発者が親しんでいるMVCのパラダイムを使って、どのようなアプリケーションでも利用できるリアルタイムAPIを作るためのツールです。
最初に企業と取引したときに学んだのは、Meteorは言うまでもなく、どのようなフルスタックのフレームワークを使うのも難しいということです。Node.jsは証明された技術ですが、顧客にフルスタックのNode.jsを使うように説得するのは難しいです。ましてや、フロントエンドに新しいウェブフレームワークを使わせるのはさらに困難です。
最終的には、プロジェクトのニーズに基づいて、自分たちに適したフレームワークを使うように成ります。それで、結局オープンソースになりました。
INFOQ:Sails.jsは負荷の分散やスケーリングはどうなっていますか。
Mike:データセンターのファイアフォールの後ろにある場合でも、Joyentのようなクラウドプロバイダでも、Modulus、NodejitsuのようなPaaSを使っている場合でも、Sailsの配置は他のNode.jsアプリケーションの場合と同じです。IRCでNodejitsuのSailsのセットアップのサポートについて怒っている開発者がいることは知っています。Sailsの利用者はExpressやSocket.ioアプリの標準的なベストプラクティスに従いたいと思うでしょう。Sailsはセッションとパブサブ/ソケットの保存先としてRedisをサポートします。つまり、必要な分だけSailsサーバをコピーして作成することができるということです。
Sailsを使えば、セッションやソケットストアを簡単にRedisへ保存できます。データモデルに従って、データベースを拡張したいと思う利用者もいるでしょうし、他のアプリと同じように拡張したいと思う人もいるはずです。
INFOQ: angular.js / ember.jsのようなクライアントサイドのエンタープライズフレームワークと組み合わせて使うことはできますか。それとも、Sails.jsはアプリケーションの構造を強制的に決めてしまうのでしょうか。モバイルでバイスには対応していますか。
Mike:Sailsの基本的な設計思想のひとつはデバイスにとらわれないということです。フロントエンドをどのように作るのかについては予想したくありませんし、制限したくありません。ブラウザであれ、ネイティブのモバイルアプリであれ、腕時計であれ、冷蔵庫であれ、データを届けることができます。
これは広く受け入れられる方法です。特に企業ではこのような方法はSOA (service-oriented architecture)と呼ばれます。ほとんどの企業はSOAを構築するのに興味を持っています。というのは、インターネットにアクセスできるデバイスのタイプは減らないからです。
Sailsはフロントエンドをどのように構築するかについて制御しません。加えて、LESS やCoffeeScriptを使う場合に利用できるツールも提供します。PhoneGapアプリやChromeエクステンションにも使えます。BackboneやEmber、Angular、ExtJS、iOSアプリ、Androidアプリのバックエンドを構築するのにSailsを使っている開発者もいます。コントリビュータの中にはもっと面白い使い方をしている人もいます。例えば、Dennis Bartlettはヘッドアップディスプレイを搭載したヘルメットを開発しています。Thom Simmonsはスマートフリスビー向けのAPIをSailsを使って作っています。
INFOQ: 各コレクションで"無償"で使えるJSON APIの利点は何ですか。
Mike: Sailsブループリントはプロトタイプに追加した機能ですが、最終的にはSailsに素晴らしい価値を与えてくれました。しっかりとテストされていて、検索とソートと問い合わせが可能なかっこいいAPIが必要なら、絶対に使うべきです。ブループリントAPIとポリシーを組み合わせることで本当に面白いことができます。何のコードも書かずに、LDAPデータベース(LDAPAdapter)への問い合わせAPIを作成したり、ツイートを検索する(TwitterAdapter)APIを作成したりできるのは、面白いことです。
また、"独自のモデルアダプタ"もとても簡単に開発できます(Sailsのプロジェクトにはアプリ固有のアダプタを配置するアダプタ用のディレクトリがあることがわかると思います)。これはORMで出来るだけ多くのAPI統合を実現するためです。こうすることで、コードをよりきれいに標準化されます。複数人で開発している場合はこれは素晴らしいことです。
INFOQ: Sails.jsには'マイグレーション'という概念はありますか。
Mike:Sailsはモデルをスキーマレスと"スキーマフル"データベースの両方でサポートします。MongoやCouchBaseのようなデータベースを使う場合は、マイグレーションは必要ありません。しかし、構造化されているデータモデルの場合、マイグレーションは必要です。また、サーバが起動したときにどのような挙動が取れるかについてもアダプタ毎に設定できます。
私はJavaのファンではありませんが、Hibernateの自動マイグレーション機能は素晴らしいと思います。Javaの開発者であれば、マイグレーションの設定や、'dbCreate'の概念がHibernateとGrailsから来ているのが理解できるかもしれません。私はGrailsの経験がありますので、Grailsから着想を得ました。Railsに触れたとき、手動でマイグレーションをしなければならないのに驚きました。スキーマではく、データを扱ってマイグレーションを手動でしなければならなかったのです。しかし、これはRailsが発表されてから10年近く立つことを考慮すれば、おかしいことではないと思います。この間、いろいろなことが変化しました。
私たちは異なるコンセプトを実験しています。スキーマベースのデータベースのマイグレーションをプログラマが気にしなければならない技術的な理由はありません。フレームワーク側で対処するための情報は十分にあります。しかし、サーバを再起動したときにテーブルをドロップするというような便利な構成にすることもできます。これは開発の生産性を向上させます。不要なタスクを追加することなく効率的が増すようなマイグレーションの方法についてコミュニティの意見を聞いているところです。
INFOQ: Sails.jsの次の展開を教えてください。
Mike:本当に素晴らしいコミュニティが生まれています。私はSailsが実際に動作しているアプリケーションを支援するプロジェクトとして存続し続けることにコミットするつもりです。最初のスクリーンキャストをリリースしてから2日後、Ted Kulp氏とCarlo de Celico氏がMongoとRedis向けのアダプタを作ってくれました。また、コミュニティの手でこれまでで最大の数のコントリビューションがアダプタやテンプレートエンジンの周辺に行われています。
これまでの機能は、商品として販売されている実際のアプリケーションに導かれて作られました。これはこれからも変わらないと思います。例えば、現在、セッションをCouchBaseに保存する必要があるという顧客を抱えていますが、任意のSailsアダプタ経由でセッションを保存できる機能を開発することで対処します。
顧客から直接要望されていないものの、私がSailsにまだ足りていないと思う最も重要な機能は、モデルの検証と連合です。Express とSocket.ioの場合、このような制約を自分で課すことができます。しかし現時点では、これを実現するための優れたツールはありません。今年の始め、データバリデーションとしてアンカーを構築しました。また、データバリデーションを一貫性のある方法で管理できるタイピングツールを開発しました。このふたつをSailsに統合するのが次のステップです。この春から夏にかけてやってみるつもりです。
また、オプションのブループリント機能を追加するという計画もあるのですが、今の時点では私の胸の内に閉まってあります。