/var/log/messages

Apr 2, 2019 - 4 minute read - Comments - programming

phoenix excersize (3)

今日は以下を確認しています。

色々ポイント高そうなのでエントリ分けるかもしれませんが、以下に控えを。

とりあえず列挙されてる中項目? が以下です。

  • Examining Routes
  • Resources
  • Forward
  • Path Helpers
  • Nested Resources
  • Scoped Routes
  • Pipelines
  • Channel Routes
  • Summary

最初に色々書いてあるナニの要約を以下に。

  • Scope については中項目作ってるのでとりあえずスルー
  • Pipeline についても同様で別途
  • get "/", PageController, :indexget はマクロで match/5 手続きに展開されます
  • def match(:get, "/", PageController, :index, [])
  • 重複した route は先頭マッチで選ばれる

Examining Routes

  • mix phoenix.routes というツールについて
  • 今使ってるやつだと以下な表示
 page_path  GET  /                  Hello.PageController :index
hello_path  GET  /hello             Hello.HelloController :index
hello_path  GET  /hello/:messenger  Hello.HelloController :show

Resources

これ、RoR てきなアレですね。マクロが展開されたら 8 つの match/5 に展開とのこと。他に

  • only という option
  • except という option
  • Phoenix.Router.resources/4 という手続きでカスタマイズができる、という記載あり

Forward

ここ、ちょっとよくわからんな。BackgroundJob.Router.call(opts) した後どうなるか、がよくわからない。別途確認します。

  • Plug.Conn.assign の出力が pipe で渡されてそれが request url になっているのかどうか

Path Helpers

  • Router.Helpers モジュールにヘルパー手続きが動的に定義される模様
  • iex -S mix で色々試せるとのこと

Nested Resources

  • resources は nest させた記述が可能
resources "/users", UserController do
  resources "/posts", PostController
end

みたいな記載で user_post_path ができるようです。以下なカンジらしく、便利ですね。

user_post_path  GET     /users/:user_id/posts           HelloWeb.PostController :index

Scoped Routes

これ、管理権限を例にした記載があります。あるいは /api/v1/images みたいな例の記載もあり。

Pipelines

Phoenix アプリケーションでは default で以下の二点の pipeline が定義される、とのこと。

  • :browser
  • :api

とは言えその前に Endpoint plug について確認を、とのこと。

The Entpoint Plugs

以下が default ということなのかどうか。

  • Plug.Static
    • 静的アセットの提供
    • Logger の前なのでログに記録されない
  • Phoenix.CodeReloader
    • Web ディレクトリ内のすべてのエントリに対してコードの reload を可能にする plug
  • Plug.RequestId
    • リクエストごとに一意な id を生成
  • Plug.Logger
    • request を記録
  • Plug.Parsers
    • request body を parse
    • urlencoded、multipart、JSON (with jason) を解析
    • content-type を解析できない場合、request body はそのまま残る
  • Plug.MethodOverride
    • valid な method parameter を持つ POST を適切な PUT、PATCH、DELETE に変換
  • Plug.Head
    • HEAD を GET に変換してレスポンスボディを削除
  • Plug.Session
    • セッション管理
    • セッションの取得方法を設定するのみ
    • セッションを使用する前に fetch_session/2 を明示的に呼び出す必要がある
  • Plug.Router
    • request cycle に router を plug します

The :browser and :api pipelines

  • :browser はブラウザへのリクエストをレンダリングする経路を準備
  • :api は API 用のデータを生成する経路を準備
  • :browser は五つの plug を持つ

    • plug :accepts, ["html"]
    • plug :fetch_session
    • plug :fetch_flash
    • plug :protect_from_forgery
    • plug :put_secure_browser_headers
  • それぞれ

    • リクエストフォーマットの定義
    • セッションデータを取得して接続で利用可能に
    • flash message の取得
    • 下二点は cross site forgery からの保護
  • :api については plug :accepts, ["json"] のみが定義

  • router はスコープ内で定義された経路で pipeline を呼び出す

  • ネストしたスコープでの使用は非推奨

  • サーバがリクエストを受け付けると

    • リクエストは最初に EndPoint の plug を通過
    • その後、パスと HTTP 動詞のマッチングを試行
    • 最初の route と一致 (GET /) した場合、Router はリクエストを PageController の :index アクションに dispatch する前に :browser pipeline を介して処理 (セッションデータの取得、フラッシュの取得、偽造防止などの実行)
    • リクエストが resources/2 マクロで定義された経路のいずれかと一致した場合、Router は HelloWeb.ReviewController の正しいアクションに dispatch する前に、:api pipeline を介して処理
  • ブラウザの view をレンダリングするだけであれば :api な pipeline 定義は不要

Channel Routes

  • Channel は、Phoenixフレームワークの非常にエキサイティングなリアルタイムコンポーネント
  • Channel は、特定のトピックについてソケットを介してブロードキャストされる着信および発信メッセージを処理

websocket なのかどうか。以下は endpoint.ex の記述とのこと。

defmodule HelloWeb.Endpoint do
  use Phoenix.Endpoint, otp_app: :hello

  socket "/socket", HelloWeb.UserSocket,
    websocket: true,
    longpoll: false
  ...
end
  • endpoint で Phenix.Endpoint.socket/3 の呼び出しで default の動作として websocket と longpoll の両方をサポート
  • 上記では websocket のみを有効にしている
  • lib/hello_web/channels/user_socket.exchannel/3 マクロを使って chennel route を定義
  • RootChannel という channel module と “room:*” というトピックがある場合の定義が以下
defmodule HelloWeb.UserSocket do
  use Phoenix.Socket

  channel "rooms:*", HelloWeb.RoomChannel
  ...
end
  • トピックは単なる文字列識別子
  • ここで使用している形式は、トピックとサブトピックを同じ文字列で定義できるようにするための規約です (“topic:subtopic”)
  • *は任意のサブトピックに一致させることができるワイルドカード文字なので、 “rooms:lobby”と “rooms:kitchen”はどちらもこのルートに一致する
  • 各ソケットは複数のチャネルに対する要求を処理できる

```

Summary

このガイドから外れる重要な点は以下。

  • HTTP動詞名で始まる経路は、match関数の単一節に拡張されます。
  • 「リソース」で始まるルートは、マッチ機能の8節に拡張されます。
  • 唯一の:またはexcept:オプションを使用することで、リソースはmatch関数節の数を制限することができます。
  • これらのルートはどれもネストできます。
  • これらのルートはいずれも特定のパスにスコープ指定できます。
  • スコープ内でas:オプションを使用すると、重複を減らすことができます。
  • スコープルートにhelperオプションを使用すると、到達不可能なパスがなくなります。

phoenix excersize (2) phoenix excersize (4)

comments powered by Disqus