目次


多忙な Java 開発者のための Sails.js ガイド

Sails を使用して基本的な Web アプリを作成してデプロイする

ローカル開発環境で Sails を使用して開発が行えるようにし、作成したアプリを Bluemix にデプロイする

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: 多忙な Java 開発者のための Sails.js ガイド

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:多忙な Java 開発者のための Sails.js ガイド

このシリーズの続きに乞うご期待。

デリカテッセンのチーズのセクションで、世界中から取り寄せられたチーズの数々が並べられた見事な陳列に圧倒されたことはありますか?贅沢な悩みとは言え、どのチーズを買って家に持って帰るかを決めるとなると、かなり迷ってしまいます。

チーズのあまりにも豊富なセレクションに圧倒されてしまうという事態は、「選択肢のパラドックス」を表す完璧な例です。「選択肢のパラドックス」とは、「選択肢がないのは困ったことだが、選択肢が多すぎるのも同じく困ったことで、選択肢が多すぎるために消費者が選択するのを完全に諦めて何も選択しないこともあり得る」という人間の行動原則を表す言葉です。

Node.js のフレームワークやライブラリーを探し求めている開発者は、まさしくこれと同じ問題に直面しており、ネットワーク上での豊富な選択肢に戸惑っています。Node.js 関連の数多くの選択肢の中からどのフレームワークやライブラリーを選べばよいかを判断するのは難しい場合がありますが、Node.js のフレームワークを導入する方法を知ることや、最適な選択肢を判断する上でどの要素を参考にすればよいかを知ることは、なおのこと困難な可能性があります。

Sails.js という選択肢

豊富な選択肢がある中で、他のいくつかの候補の中から苦労して選び抜いて、決定したのが Sails.js です。Sails を気に入った理由は、Node.js ならではの機能を維持しながらも、Rails フレームワークを大成功に導いた考え方を一部採用している点です。具体的には、Sails は階層型の開発と「設定より規約」というパラダイムを採用しています。この 2 つは、Rails や同様のフレームワークによって広まった開発手法です。さらに、Sails は他のいくつかの Node.js パッケージを主要コンポーネントとして統合しています。つまり、このフレームワークを学ぶには、必ずしもゼロから始める必要はありません。もう 1 つの利点としては、Sails.js のドキュメントは常に改善が進められていることも挙げられます。これは、オープンソース・プロジェクトで私が重要視している点です。

この第 1 回のチュートリアルで焦点を当てるのは、Sails の階層型開発手法です。今後のチュートリアルでは、Sails での「設定より規約」というパラダイムや、その他のコーディングに関する便利な点を紹介します。

新たな MVC

このように従来型の MVC アーキテクチャーを再構成したことで、アーキテクトと開発者がアプリケーション・サーバーに長年求めていた、ビジネス・ロジックと検証の一元化、そして複数のクライアントに共通のインターフェースという仕組みがまさに実現されます。

Sails の階層型開発アプローチは、従来の多くの Web 開発者が期待するものとは異なります。実のところ、Sails は新種のフレームワークの 1 つであり、MVC を一新して Web アプリケーション開発に期待されるものを再定義しています。従来の MVC アーキテクチャーでは MVC コンポーネントはサーバー上に置かれますが、Sails ではモデルとコントローラーをサーバー上に置き、それとは別にビューをクライアント層に置きます。Sails では「ビュー」をより汎用的な概念として捉えており、ビューを HTML にすることができる一方で、iOS または Android のネイティブで作成されたモバイル・アプリケーションにすることもできます。

Sails はサーバーからクライアントに HTML を送信するのではなく、データのみを (通常は JSON 形式か XML 形式で) 送信します。クライアント (モバイル・アプリケーション、または AngularJS のようなクライアント・サイドの JavaScript フレームワークを使って作成されたシングル・ページの Web アプリケーションのいずれか) は、サーバーから送信されたデータを使って、クライアントのルック・アンド・フィールに最も適した方法で表示します。ほとんどのクライアントでは、データを表現するフォーマットは JSON になります。それは、シングル・ページの Web クライアントやモバイル・クライアントは、その多くが JavaScript を使用して作成されていて、JSON を簡単に利用することができるためです。ただし、必要に応じて XML などの別のデータ表現フォーマットを採用するのも難しいことではありません。

このように従来型の MVC アーキテクチャーを再構成したことで、アーキテクトと開発者がアプリケーション・サーバーに長年求めていた、ビジネス・ロジックと検証の一元化、そして複数のクライアントに対する共通のインターフェースという仕組みがまさに実現されます。サーバーは単に、クライアントが認識できる表現でデータ要素を送信するだけでよいというこのアプローチは、従来のビジネス・ロジックとデータ検証を、HTTP エンドポイントを介して行う容易な手段となります。

HTTP API のサンプル・アプリケーション

私が「HTTP API」と呼んでいる、この新しいアーキテクチャーは、RESTful スタイルと似ていますが、実際には REST ではありません。少なくとも、Roy Fielding 氏による REST の定義には当てはまりません。REST は、アプリケーションの状態を伝える主な手段として、ハイパーメディアの交換に頼っています。すなわち、HATEOAS (Hypertext As The Engine Of Application State) の原則です (この頭辞語は、これまでに考案された頭辞語の中で、おそらく最悪のものでしょう)。しかし HTTP API システムは、モデルが単純化されるのと引き換えに、REST がもたらす柔軟性と「汎用クライアント」を使用できる性質をある程度放棄しています。

REST システムとは異なり、HTTP API クライアントには通信相手のシステムに関する演繹的な知識が必要です。つまり、期待される結果と使用可能なエンドポイントをあらかじめ知っておかなければならないとうことです。これは REST アーキテクチャーに反することですが、単純化のために払う価値がある代償だと私は思います。

HTTP API では、クライアントとサーバーとの間の通信はすべて HTTP 上で行われます。サンプル・アプリケーションでは、JSON をデータ交換フォーマットとして使用し、標準的な HTTP 動詞でアクションを指定します (読み取りは GET、挿入は POST、更新は PUT、削除は DELETE で表します)。また、認証データなどの帯域外情報を伝えるメカニズムとして、HTTP ヘッダーも使用します。ただし、状態データは (従来の REST 設計に反して) サーバー・サイドに保管します。交換する状態データのフォーマットは例外なく JSON です。これらのデータは、このシステムに固有のものと見なされます。

HTTP API サンプルのコンシューマー (例えば、モバイル・アプリケーション、シングル・ページの JavaScript アプリケーション、さらには保管されているデータにアクセスする必要がある他のサーバーの場合もあります) は、送られてくる JSON タイプを認識します。これは、送られてくる情報をどのアプリケーションでも「検出」できることを示唆する、より REST に準拠したハイパーテキスト/HATEOAS 中心の仕組みとは対照的です。さらに重要なことに、コンシューマーはデータの送信先や取得元の HTTP エンドポイント、あるいはデータに変更を加えられる HTTP エンドポイントを認識します。

Sails.js を評価する中で、私は時間をかけて Sails.js をいろいろと実験したので、難しい話は抜きにして早速 Sails の要領を学びましょう。

必要となるもの: 前提条件とセットアップ

ここからは、読者が REST の原則と用語、そして RESTful アーキテクチャーについてある程度理解しているものとして説明を進めます。HTTP の狂信者である必要はありませんが、HTTP をそのまま直接使って GET リクエスト、POST リクエストなどを送信するのに慣れていることを前提とします。送信中の HTTP リクエストを調べるという考えに恐れをなして欲しくないためです。

また、JavaScript、Node.js、および npm (JavaScript のコードおよびライブラリー用のパッケージ・マネージャー) の知識があることも前提とします。任意の開発マシンに Node.js がインストールされていること、Node.js アプリケーションをローカルで実行する方法を知っていること、そして npm-install を使いこなせることも必要です。いわゆる「モダン JavaScript」(具体的には、Douglas Crockford 氏の著書『JavaScript: The Good Parts』やこの本から派生した数多くの書籍またはチュートリアルで説明している JavaScript) に関する本を読んでおくと役に立ちますが、Sails を使い始める上で実際に必要となるのは JavaScript の実用的な知識だけです。

開発環境については、お使いのマシンの Node.js が最新バージョンであること (このチュートリアルを作成している時点で、私のマシンでレポートされるバージョンは 0.12.7 です)、最新バージョンの npm (私が使用しているのはバージョン 2.12.1 です) がインストールされていることを確認してください。Node.js コミュニティーが各バージョンの後方互換性を維持しようとしているのは明らかですが、ここで作成するコードがかなり古いバージョンの Node.js で動く保証はないので、用心するに越したことはありません。

Sails.js と MongoDB をインストールする

Sails.js を使用するために必要となる唯一のインストール作業は、例えば npm install -g Sails.js のようなコマンドを実行することで、Sails.js を npm キャッシュにグローバルにインストールすることだけです。

インストールが完了した後は、新しいユーティリティー・コマンド sails を使用できるようになります。npm と同じく、sails は Node.js 用に JavaScript で作成されたコマンド・ライン・ユーティリティーです。このユーティリティーはある種のシングル・ソース・ユーティリティーとして機能し、例えば新規アプリケーションを作成する、アプリケーションを実行する、デバッグ・ループでアプリケーションを実行する、アプリケーションの新規コンポーネントを生成するなど、Sails.js フレームワークでさまざまな役割をこなします。npm で Sails.js をインストールする際には、必ず -g オプションを使用してください。このオプションを使用しなければ、Sails.js は現在のプロジェクト・ディレクトリーだけにインストールされますが、このユーティリティーをどうしてもグローバルにしなければならないレア・ケースの 1 つとして、今回はこのオプションを指定する必要があります。

Sails.js フレームワークがダウンロードされてインストールされるのを待っている間、開発環境に MongoDB がセットアップされていることを確認してください。セットアップされていない場合、ターゲット・プラットフォームに適切なインストールをダウンロードするには、この待ち時間が絶好のチャンスとなります。

Sails.js が使用するのは MongoDB バックエンドだけではありません。実のところ、Sails.js はそのままの設定ではディスクをベースとした軽量のフォーマットを使用します。この設定は、本番で使用するにはお勧めできませんが、このチュートリアルのような例には快適に機能します。このシリーズで MongoDB が活躍するようになるのはまだ先の話ですが、今のうちにセットアップしておけば、MongoDB を使用する段になったときに良かったと思うはずです。

差し当たり、以上が基本的なセットアップです。このチュートリアルの後のほうでローカル・アプリケーションを Bluemix クラウドにデプロイするときに、Cloud Foundry のインストールBluemix へのログインが必要になります。

インストールを確認する

Sails.js のインストールが完了したことを確認するには、コマンド sails version を実行します。

このチュートリアルを作成している時点での Sails.js の最新バージョンは 0.11.0 です。上記のコマンドによってエラー以外の何かしらが出力されたら、Sails はインストールされて使用できる状態になっています。

Sails.js による「Hello, world!」の作成

伝統的に、プログラマーが新しい言語や環境について学ぶ際に一番初めに行うことは、その対象言語で可能な限り単純なプログラム、つまり「Hello World」アプリケーションを作成することです。幸いなことに、Sails では新規アプリケーションを作成するときに、基本的なアプリケーションの scaffold として Hello World が生成されます。そのため、これを利用して、Sails インフラストラクチャーが動作していることを確認することができます。このチュートリアルでは、アジャイル開発ストラテジーに従って「release early, release often (早い段階から頻繁にリリースする)」というストラテジーの一環として scaffold をクラウド (この場合、Bluemix) にデプロイします。

基本的な Sails.js アプリケーションを作成する

新規 Sails.js アプリケーションを手に入れるのは、かなり簡単なことです。デフォルトで scaffold として生成されるのは、サーバーで生成された HTML がクライアントに返される、より従来型の Web アプリケーションであることに注意してください。このような Web アプリケーションはそれ単独で役に立つものの、ここではクライアントにとらわれない HTTP API アプリケーションを作成することが目標なので、クライアントをサーバーに偶然縛り付けてしまう「手落ち」がないようにしたいと思います。そのための最善の方法は、プロジェクトのどこにもクライアント・コンポーネントがない状態でサーバーを構築することです。Sails.js では、--no-frontend オプションを使用してデフォルトの構成を設定するだけで、この目的を果たすことができます。

--no-frontend オプションを使用する場合のマイナス面は、scaffold が動作していることを視覚的に確認する手段がないことです。その確認は、アプリケーションを Bluemix にデプロイするときに行うことにします。この第 1 回のチュートリアルで作成するのは、見栄えの良い HTML フロントエンドの scaffold を使用したアプリケーションですが、以降のチュートリアルは、フロンドエンドの要素なしでアプリケーションがビルドされたという前提で進めます (それによる違いは、生成される views ディレクトリーに取り込まれる内容だけなので、さして大きな問題ではありません)。

前置きはこれで十分なので、早速 Sails アプリケーションを作成しましょう!

開発マシン上でコードを配置したいディレクトリーから、sails コマンド・ラインで new コマンドを発行してアプリケーションに名前を付けるために、sails new hello-sails を実行します。

上記のコマンドを実行すると、Sails は一瞬考えてから、「Created a new Sails app 'hello-sails'! (新規 Sails アプリ 'hello-sails' が作成されました!)」というメッセージで応答します (何も出力されない場合は、Sails.js インストールに何かしらの問題があることが考えられます)。アプリケーション名から推論されるターゲット・ディレクトリー内に、Sails.js によっていくつものディレクトリーとファイルが配置されているはずです。これらのディレクトリーとファイルの大部分を、このシリーズを通して詳しく探る予定です。今回は Sails アプリケーションの基本のみを説明します。

通常、(誰もいじらなければ) scaffold には問題がないことを前提にして問題ありませんが、アプリケーションをローカルで実行する方法を知っておくと役立つので、salis lift を指定して hello-sails を実行してみましょう。

図 1. Sails.js をローカルで実行する
デフォルトの Web アプリケーションがローカル・マシン上で実行中であることを確認する、Sails.js 出力のスクリーンショット
デフォルトの Web アプリケーションがローカル・マシン上で実行中であることを確認する、Sails.js 出力のスクリーンショット

きれいな出力だと思いませんか?色を使うのが好きという私の個人的な好みに加え、かなり印象的な ASCII アートの表示になっています。さらに重要なことは、scaffold として生成されたアプリケーションを Node.js がローカル・マシンのポート 1337 で正常に実行していることが、この小さな ASCII 絵画によって確認されたことです。ブラウザーでこのアプリケーションにアクセスすると、メインの Sails ホーム・ページおよびドキュメントへのリンクを記載した、デフォルトの Sails.js Web ページが表示されます。

Sails.js をクラウドにデプロイする

ローカル・マシン上で実行するのと、コードを本番サーバー (または、本番同様のサーバー) にデプロイするのとでは話が違います。そこで登場するのが、クラウドです。このシリーズでは、Bluemix をクラウド・ホストとして利用します。Bluemix は Node.js ベースのアプリケーションをホストするために簡単に使用できるプラットフォームなので、この選択は適切だと思います。

さらに、Bluemix は Cloud Foundry をベースとしているので、Cloud Foundry クライアント (cf) をまだインストールしていない場合は、この機会にインストールしてください。このクライアントを実行するマシンは、Sails.js コードをホストしているのと同じマシンにすることをお勧めします。

クライアントのインストールが完了したら、cf--version を実行してインストールを確認します。このチュートリアルを作成している時点で、エコー出力されたバージョンは 6.12.2 でした。

前述のとおり、アプリケーションを Bluemix にデプロイするには、Bluemix ログインも必要になります。資格情報を取得した後、Bluemix にログインして、ローカル hello-sails ディレクトリーから Bluemix クラウドにコードをプッシュしてください。

リスト 1. cf で Bluemix にログインする
Teds-MBP15:hello-sails ted$ cf login
API endpoint: https://api.ng.bluemix.net

Email> ted@tedneward.com

Password> 
Authenticating...
OK

Select an org (or press enter to skip):
1. developerWorks
2. ted@tedneward.com

Org> 1
Targeted org developerWorks

Targeted space Ted Neward


                   
API endpoint:   https://api.ng.bluemix.net (API version: 2.27.0)   
User:           ted@tedneward.com   
Org:            developerWorks   
Space:          Ted Neward

cf ツールには、デプロイメントに使用する API エンドポイントも知らせる必要があります。対象の API エンドポイント (api.ng.bluemix.net) を cf が見つけることができない場合には、コマンド cf api api.ng.bluemix.net を実行することにより、エンドポイントを手作業で設定することができます。

2 つの有用なファイル

Bluemix にログインして API エンドポイントを設定したら、cf push を使用して scaffold として生成された Sails.js アプリケーションをクラウドにデプロイします。アプリケーションを適切にデプロイするために Cloud Foundry が必要とするパラメーターはほんの少しですが、これらのパラメーターを繰り返し入力せずに (だんだん面倒になってきます)、マニフェスト・ファイル (manifest.yml) を作成してください。マニフェスト・ファイルには、Bluemix クラウド上で使用するアプリケーションの名前、サブドメインに使用するホスト名 (アプリケーション名と異なる場合)、実行用に予約する RAM の容量などを含めます。

以下に、単純なマニフェスト・ファイルの例を示します。

---
applications:
- name: tedneward-sailsIntro
  host: tedneward-sailsIntro
  memory: 256M
  command: node app.js

Cloud Foundry が認識するもう 1 つの有用なファイルは、.cfignore です。このファイルには、クラウドにプッシュしないローカル・アプリケーションのファイルまたはディレクトリーのリストを含めます。とりあえず、その情報は将来参照するために、ファイルに記載しておくだけにとどめます。

これで、すべての準備が整いました。後は、cf push を実行してプッシュの処理を行わせるだけです (コマンドからの出力は、かなりの長さになることがあります。このコマンドはコードをパッケージ化、アップロード、アンパックしてから、クラウド・インスタンス上にインストールしなければなりません。つまり、クラウド・インスタンス上で npm install が実行されるため、大量の結果が出力されます。したがって、ここでは最初の 20 行と最後の数行だけを表示します)。

リスト 2. Bluemix に対する cf push
Using manifest file /Users/ted/Projects/sails-intro/code/hello-sails/manifest.yml

Updating app tedneward-sailsIntro in org developerWorks / space Ted Neward as ted@tedneward.com...
OK

Using route tedneward-sailsIntro.mybluemix.net
Uploading tedneward-sailsIntro...
Uploading app files from: /Users/ted/Projects/sails-intro/code/hello-sails
Uploading 31M, 11773 files
Done uploading               
OK

Stopping app tedneward-sailsIntro in org developerWorks / space Ted Neward as ted@tedneward.com...
OK

Starting app tedneward-sailsIntro in org developerWorks / space Ted Neward as ted@tedneward.com...
-----> Downloaded app package (24M)
-----> Downloaded app buildpack cache (18M)

-----> IBM SDK for Node.js Buildpack v2.5-20150902-1526
       Based on Cloud Foundry Node.js Buildpack v1.5.0
-----> Creating runtime environment
       NPM_CONFIG_LOGLEVEL=error
       NPM_CONFIG_PRODUCTION=true
       NODE_MODULES_CACHE=true
-----> Installing binaries
       engines.node (package.json):  unspecified
       engines.npm (package.json):   unspecified (use default)
       
. . .

App tedneward-sailsIntro was started using this command `node app.js`

Showing health and status for app tedneward-sailsIntro in org developerWorks / space Ted Neward as ted@tedneward.com...
OK

requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: tedneward-sailsIntro.mybluemix.net
last uploaded: Mon Oct 5 01:36:54 UTC 2015
stack: lucid64
buildpack: SDK for Node.js(TM) (ibm-node.js-0.12.7)

すべてのコンポーネントが正しくアップロードされてインストールされていれば、Bluemix クラウド上の新しいサブドメインを確認できるはずです (私の例でそれに該当するのは、http://tedneward-sailsIntro.mybluemix.net です)。新しいサブドメインは、HTTP GET / リクエストに応答して、Sails.js のサンプル hello ページを生成します。

まとめ

scaffold は準備できたので、サンプル・アプリケーションの拡張および改善を始めることができます。これまでに行った作業のおかげで、新しいセグメントを完成するたびに新しいコードを Bluemix クラウドにデプロイすることができます。「always be shipping (常にリリースする)」という原則、別の言い方をすれば「release early, release often (早い段階から頻繁にリリースする)」という原則を忘れないでください。他の開発者たちが使用できるようにコードをサーバーに毎回プッシュすれば、他の人によってバグが発見されたり、自分が正しい方向でコードを作成していることを確認したりするなどの機会が作り出されます。十分に確立されたクラウド基盤を使用すれば、作業の大半をあらかじめ完了できるので、アプリケーションをリリースするのが簡単になります。単純な cf push によってプッシュされた最新バージョンの Sails アプリケーションは公開され、HTTP クライアントに発見されて使用されるのを待つだけです。

次回のチュートリアルで特集するのは、Sails.js モデルです。Sails.js モデルについて学ぶうちに、ブループリントまたは Sails Blueprint API と呼ばれる Sails の膨大な規約も理解できるようになります。その発想の基となった Rails と同様、Sails では「設定より規約」というパラダイムを支持しています。これはつまり、モデルを作成すれば、大量の構成ファイルやコードを作成することなく有用な機能をそのまま利用できることを意味します。

現状では scaffold に過ぎませんが、今後数回のチュートリアルで形になってくるこのサンプル・アプリケーションは、最終的にブログ・エンジンになります。ただし、一捻りされていて、このエンジンを従来型のサーバー・サイド Web アプリケーションとしてではなく、HTTP API として作成します。HTTP API は、必要となるすべてのテクノロジーをバックエンドにパッケージ化し、クライアント・サイドのコードは、誰かが作成するフロントエンド・ツール次第で決まるようにしておきます。

ひとまず、休憩の時間です。このフレームワークの名前にちなんで、「さようなら」とは言わずに「良いご旅行を」と言ってお別れしましょう。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Web development, Open source, Mobile development, Cloud computing
ArticleID=1024580
ArticleTitle=多忙な Java 開発者のための Sails.js ガイド: Sails を使用して基本的な Web アプリを作成してデプロイする
publish-date=01072016