Skip to content

Instantly share code, notes, and snippets.

@shinout
Last active August 29, 2015 14:24
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save shinout/5ad8021ccc49dc37eb11 to your computer and use it in GitHub Desktop.
Save shinout/5ad8021ccc49dc37eb11 to your computer and use it in GitHub Desktop.

smoking_cessation_domainの使い方の手引き

ドメインFacadeをつくる

domain = require('smoking_cessation_domain').createInstance
    baseURL: 'http://localhost:3000/api'
    sessionId: 'xxxxxxxxxx'
    debug: true

baseURL

ええと、baseURLとは何だ?

データを格納するサーバーの場所を与える必要がありますので、そのREST APIを定義している場所になります。 ローカルにloopbackサーバーを立ち上げる場合は上記の様に指定し、 devや本番サーバーに接続する際には

https://dev-mbaas.cureapp.net/api

などと指定します。

あとからbaseURLを設定する

domain = require('smoking_cessation_domain').createInstance baseURL: ''

こうしておいて

domain.setBaseURL 'localhost:3000/api'

という風にセットできます.

REST APIを知る必要はないのか?

知る必要はありません。 そのあたりのマッピングは base-domain-loopback が担当しています。

sessionId

sessionIdって何のセッション?

これは、loopbackサーバーのセッションです。

何の値をいれればいいのですか?

  • guestユーザー: 何もいれなくていいです.
  • 普通のユーザー:自分のセッションをいれないといけません
  • adminユーザー: admin用のセッションをいれないといけません

guestユーザーや普通のユーザーだとできることが限られてしまい, loopbackサーバーから

Authorization Required

とか言われて怒られるので、基本的には、アプリサーバーからloopbackに接続するときには admin用のセッションを入れる必要があります。

admin用のセッションは誰がどこで決めているのでしょうか

loopbackが、起動時に、configをみて、決めています. loopbackを起動するスクリプトをみると

require('loopback-with-admin').run(models, config)

などと書かれているかと思いますが,このconfigに

config =
    admin:
        accessToken: 'xxxx'

とやっておくとこのaccessTokenがセッションidです.

いろんな理由によって、loopback側ではaccessTokenと表現し、 smoking_cessation_domainではsessionIdといっています。

configが設定されていない場合, loopback-with-adminのデフォルトaccessToken値

(you must set access token)

が使われています.

admin用のセッションを、あとから教えてもらう
require('loopback-with-admin').run(models, config).then (lbInfo) ->
    console.log lbInfo.getAccessToken()

このlbInfo.getAccessToken()の値をsessionIdに入れれば間違いありません.

あとからsessionIdを入れる
domain.setSessionId sessionId
devやprodのsessionIdはどうなっているのか

ここには書きませんが、しかるべき場所に設定されています. もしくは聞いてください.

REST APIを叩いてデバッグとかしたいんですが

どうぞしてください。 なお、 もしlocalにloopbackを立ち上げた場合

http://localhost:3000/explorer

に、APIをちょっと簡単にたたくためのツールがありますので、みてみてください。 そこに accessTokenを入力する場所があるので、sessionIdというべきものを入れてください

debug

debugはtrueにしとくべき?

しておくと、ひとまずはいろんな情報がでていて安心はすると思います。 特に、loopbackと接続する部分のログがあるので、データの取得や保存が行われるときにどんなREST APIがたたかれているかが わかるでしょう。

domainFacadeってシングルトンなの?

ではないです。つまり

domain1 = require('smoking_cessation_domain').createInstance baseURL: 'localhost:3000/api'
domain2 = require('smoking_cessation_domain').createInstance baseURL: 'localhost:3000/api'

console.assert domain1 isnt domain2 # 通る

なので、domainを使う側が常に同じdomainFacadeをみるように頑張る必要があります.

domain.coffee

module.exports = require('smoking_cessation_domain').createInstance
    baseURL: 'http://localhost:3000/api'
    sessionId: 'xxxxxxxxxx'
    debug: true

などとして

domain = require('./domain')

とすればいいです.

doctor siteなどはエレガントな方法で環境変数によって見に行くloopbackを変えるなどの設計をしています.

モデルを作る

Hospital = domain.getModel('hospital')
hospital = new Hospital(name: 'xxxx')

もしくは

hospital = domain.createFactory('hospital').createFromObject
    name: 'xxxx'

どう違うんですか?

new だと、依存するサブモデルを作ってくれませんが createFromObjectだと、依存するサブモデルも作ってくれます

つまり...

class Hospital extends Entity

    @properties:
        name: @TYPES.STRING
        foo:  @TYPES.MODEL 'foo'

たとえばこんなModel定義になっていたとすると このfooというのが、「依存するサブモデル」なんです.

このfooが

class Foo extends Entity
    n: @TYPES.NUMBER

というModel定義だった場合、

new をすると
Foo = facade.getModel('foo')
foo = new Foo(n: 123)

Hospital = facade.getModel('hospital')
hospital = new Hospital(foo: foo, name: 'xxx')

と、fooプロパティにはしっかりfooクラスのインスタンスを与えてあげないといけません.

createFromObjectを使うと
hospital = facade.createFactory('hospital').createFromObject
    foo: n: 123
    name: 'xxx'

これで、hospital.foo もFooクラスのインスタンスになってくれます.

sessionIdとaccessTokenはどう違うのか

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment