ページ編集

Sails v0.11へのアップグレード

要約;

v0.11には、多くの小さな改善と、コアの内部クリーンアップが含まれています。最大の変更点は、SailsコアがSocket.io v1を使用するようになったことです。

これによる既存プロジェクトのコードへの影響はほとんどありませんが、いくつかの重要な違いと新しい機能に注意する必要があります。それらを以下にリストしました。

相違点

Socket.io / Sails.io ブラウザクライアントのアップグレード

古いv0.9のsocket.ioクライアントは動作しなくなるため、sails.io.jsクライアントをv0.9またはv0.10からv0.11にアップグレードする必要があります。

そのためには、sails.io.jsクライアントを削除して、新しいクライアントをインストールします。sails.io.jsクライアントが従来の場所`assets/js/dependencies/sails.io.js`にあると仮定して（つまり、移動または名前変更していない場合）、これを行う新しいジェネレーターをバンドルしました。

sails generate sails.io.js --force

onConnectライフサイクルコールバック

要約;

`config/sockets.js`から`onConnect`関数を削除してください。

`onConnect`ライフサイクルコールバックは非推奨になりました。新しいソケットが接続されたときに何かを実行する必要がある場合は、新しく接続されたクライアントからリクエストを送信してください。`onConnect`の目的は常にパフォーマンスの最適化（サーバーとのこの最初の追加のラウンドトリップを行う必要性を排除すること）でしたが、その使用は混乱や競合状態につながる可能性があります。どうしてもサーバーのラウンドトリップを排除する必要がある場合は、ブートストラップ関数（`config/bootstrap.js`）で`sails.io.on('connect', function (newlyConnectedSocket){})`にハンドラーを直接バインドできます。ただし、これは推奨されていません。真の運用パフォーマンスの問題に直面していない限り、上記の方法で「接続時」のロジックを使用する必要があります（つまり、ソケット接続後にクライアントから最初のリクエストを送信します）。ソケットリクエストは軽量であるため、アプリケーションに具体的なオーバーヘッドを追加することはなく、コードをより予測しやすくなります。

onDisconnectライフサイクルコールバック

`onDisconnect`ライフサイクルコールバックは、`afterDisconnect`に非推奨になりました。

以前`onDisconnect`を使用していた場合、`session`を変更してから、手動で`session.save()`を呼び出していた可能性があります。v0.11では、ほとんど同じように機能しますが、`afterDisconnect`は追加の第3引数（コールバック関数）を受け取ります。このようにして、`afterDisconnect`ロジックが完了したら、提供されたコールバックを呼び出すだけで、Sailsはセッションに加えた変更を自動的に永続化できます。最後に、予想どおり、`session.save()`を手動で呼び出す必要はもうありません。これは、通常のルート、アクション、またはポリシーにおける`req.session`と同様に、自動的に処理されます。

要約; `config/sockets.js`内の`onDisconnect`関数を次のように名前変更してください。

afterDisconnect: function (session, socket, cb) {
 // Be sure to call the callback
 return cb();
}

`config/sockets.js`内のその他の設定

Socket.io v1の多くの設定オプションが変更されているため、`config/sockets.js`ファイルをそれに合わせて更新する必要があります。

• アプリケーションで`config/sockets.js`のオプションをカスタマイズしていない場合は、ファイルを削除するかコメントアウトして、Sailsのデフォルトを使用できます。それ以外の場合は、新しいSailsソケットのドキュメントを参照して、設定が有効であり、予期しない問題を回避してください。
• スティッキーセッションをサポートしていない環境（Herokuなど）で複数のサーバーにスケーリングする場合は、`config/socket.js`とクライアントの両方で`transports`を`['websocket']`に設定する必要があります。スケーリングに関するドキュメントで詳細情報をご覧ください。
• カスタム`authorization`関数を使用してソケット接続を制限していた場合は、`beforeConnect`を使用する必要があります。`authorization`はSocket.io v1で非推奨になりましたが、`beforeConnect`（Engine.ioの`allowRequest`オプションにマップされます）は同じように機能します。
• socket.io v1に直接渡されたその他の低レベルのソケット設定を使用していた場合は、新しい設定オプションが詳細に説明されているsailsjs.comのリファレンスページを確認してください。

「ファイアホース」

ソケットでのテスト用の「ファイアホース」機能は非推奨になりました。それが何を意味するかわからない場合は、心配する必要はありません。基本的な使い方はしばらくの間機能しますが、すぐにコアから削除されるため、アプリケーションでは使用しないでください。これは、次のメソッドにも適用されます。

• sails.sockets.subscribeToFirehose()
• sails.sockets.unsubscribeFromFirehose()
• sails.sockets.drink()
• sails.sockets.spit()
• sails.sockets.squirt()

「ファイアホース」を復活させたい場合は、TwitterでMikeに知らせてください（別々のフックとして復活させることができます）。

サブフォルダ内の設定ファイル

Sailsの`config`フォルダ内のファイルは互いに優先順位がなく、`local.js`、`env`サブフォルダ、`locale`サブフォルダを除いて、ファイル名とサブフォルダは単なる整理のために使用されるという意図でした。しかし、以前のバージョンのSailsでは、サブフォルダに設定ファイルを保存すると、ファイル名が`sails.config`にキーとして追加されるため、`config/foo/bar.js`に設定を保存すると、その設定は`sails.config.bar`の下に名前空間化されます。これは意図しないものであり、1）ディレクトリ名が無視される、2）ファイルを移動すると設定キーが変更されるため、混乱を招く可能性があります。これはv0.11.xで修正されました。サブフォルダ内の設定ファイルは、ルート`config`フォルダ内のファイルと同じように扱われます。何らかの理由で古い動作に依存している場合は、`.sailsrc`ファイルで`dontFlattenConfig`を`true`に設定できますが、代わりに`module.exports`に目的のキーを設定して、自分で設定を名前空間化することを強くお勧めします。たとえば、`module.exports.foo = {...}`です。issue #2544で詳細をご覧ください。

WaterlineはBluebirdを使用するようになりました

v0.11から、WaterlineはプロミスにBluebird（qの代わりに）をサポートするようになりました。`.exec()`を使用している場合は影響を受けません。`.then()`を使用している場合のみです。https://github.com/balderdashy/sails/issues/1186で詳細情報をご覧ください。

新機能

Sails v0.11には、知っておいてほしい新しい機能も含まれています。

ユーザーレベルのフック

フックは、NPMから直接インストールできるようになりました。

つまり、ターミナルで1つのコマンドでフックをインストールできるようになりました。autoreloadフック（@sgress454作成）を例に挙げると、バックエンドコードの変更を監視するため、コントローラー、ルート、モデルなどを変更するたびにサーバーを停止して再起動する必要がなくなります。

autoreloadフックをインストールするには、次のコマンドを実行します。

npm install sails-hook-autoreload

これは可能なことの1つの例です。ご存知かもしれませんが、フックはSailsで最も低レベルのプラグイン可能な抽象化です。これにより、開発者はリフトプロセスにアクセスし、イベントをリッスンし、カスタム「シャドウ」ルートを挿入し、一般的に`sails`ランタイムへの直接アクセスを利用できます。Sailsでよく使用されている機能のほとんどは、実際には1年以上前から「コア」フックとして実装されています。これには以下が含まれます。

• blueprints （ブループリントAPIを提供します）
• sockets （socket.io統合を提供します）
• grunt （Grunt統合を提供します）
• orm （Waterline ORMとの統合を提供し、プロジェクトのアダプター、モデルなどをインポートします）
• http （HTTPサーバーを提供します）
• その他16個

独自のフックの書き方については、新しく改善された「Sailsの拡張」ドキュメント（https://sails.dokyumento.jp）をご覧ください。

Socket.io v1.x

Socket.io v1.0へのアップグレードは、Sails自体によって提供される抽象化レイヤーを使用している場合、アプリケーションレベルのコードに実際には影響を与えません。`sails.sockets.*`ラッパーメソッドやそれ以上のもの（リソースフルなpubsub、ブループリント）などです。アプリケーションで基礎となるsocket.ioメソッドを使用している場合、またはSocket.io v1.0で何が変更されたのかを知りたいだけの場合、Guillermoとsocket.ioチームによる完全なSocket.io 1.0移行ガイドを確認してください。

ますます高まるモジュール性

Socket.io v1.0へのアップグレードの一環として、コア`sockets`フックを別のリポジトリに移動しました。これにより、socket.ioインタープリター用のモジュール化されたフック固有のテストを作成することができ、保守、カスタマイズ、オーバーライドが容易になります。これにより、フックを独自のペースで成長させることができ、関連する問題を1か所にまとめることができます。

今後数か月で、他のフックをSailsコアリポジトリから取り除くことの利点と欠点をテストすることを検討してください。これにより、Sailsコアは軽量で高速になり、拡張性が向上し、コア依存関係が少なくなり、ほとんどのアプリケーションの「リフト」時間が短縮され、`npm install`が高速になります。

テスト、「仮想」リクエストインタープリター、および`sails.request()`メソッド

`sockets`フックをコアから取り除く過程で、リクエストを解釈するロジックが正規化され、現在はSailsコア内に配置されています。その結果、`sails.request()`メソッドははるかに強力になりました。

このメソッドを使用すると、サーバーをポートにリフトせずに、Sailsのリクエストインタープリターと直接通信できます。これは、SailsがSocket.ioからの着信メッセージを、使い慣れた`req`と`res`ストリームを持つ「仮想リクエスト」にマッピングするために使用するメカニズムと同じです。

`sails.request()`の主なユースケースは、高速実行の単体テストと統合テストを作成することですが、マウントされたアプリケーション（または「サブアプリケーション」）へのプロキシにも便利です。

たとえば、アプリケーションのルートの1つをテストする方法の例（mochaを使用）を以下に示します。

var assert = require('assert');
var Sails = require('sails').Sails;

before(function beforeRunningAnyTests (done){

  // Load the app (no need to "lift" to a port)
  sails.load({
    log: {
      level: 'warn'
    },
    hooks: {
      grunt: false
    }
  }, function whenAppIsReady(err){
    if (err) return done(err);

    // At this point, the `sails` global is exposed, although we
    // could have disabled it above with our config overrides to
    // `sails.load()`. In fact, you can actually use this technique
    // to set any configuration setting you like.
    return done();
  });
});

after(function afterTestsFinish (done) {
  sails.lower(done);
});

describe('GET /hotpockets', function (){

  it('should respond with a 200 status code', function (done){

    sails.request({
      method: 'get',
      url: '/hotpockets',
      params: {
        limit: 10,
        sort: 'price ASC'
      }
    }, function (err, clientRes, body) {
      if (err) return done(err);

      assert.equal(clientRes.statusCode, 200);
      return done();
    });

  });
});

`config/env/`サブフォルダ

v0.10.xでは、`config/env`フォルダを追加しました（@clarkorzのおかげです）。ここでは、適切な環境でのみロードされる設定ファイルを追加できます（例：本番環境の場合は`config/env/production.js`、開発環境の場合は`config/env/development`など）。v0.11.xでは、環境ごとにサブフォルダ全体を指定できるようになりました。たとえば、`config/env/production`に保存されたすべての設定ファイルは、環境が`production`に設定されている場合、他の設定の上にロードされ、マージされます。`config/env/production`フォルダと`config/env/production.js`ファイルの両方が存在する場合は、`config/env/production.js`の設定が優先されます。そして、常に`local.js`は他のすべてのファイルの上にマージされ、`.sailsrc`がすべてを支配します。

ご質問は？

いつものように、アップグレード中に問題が発生した場合、または上記のメモが理解できない場合は、お知らせください。できる限りの説明をさせていただきます。

最後に、8月のv0.10リリース以降にプロジェクトに貢献してくれた皆さんに、継続的なサポートと励ましに感謝します。膨大な数の課題、プルリクエスト、ドキュメントの調整、質問がありますが、私たちが一緒に取り組んでいることを知ることが常に役立ちます :)

ありがとうございました。

-@mikermcneil、@sgress454、@particlebanana