Phoenix v1.3からのディレクトリ構成をもう一度調べる
はいこんにちは。
Phoenix v1.3.0-rc.0がリリースされました。前リリースからの大きな変更として、Phoenixプロジェクトのディレクトリ構成がガラッと変わります。新たな構成に対応したジェネレータは、phoenix.*
ではなくphx.*
というタスクになっています。ついで感がありますが、phoenix.server
やphoenix.routes
もdeprecatedになり、phx.server
、phx.routes
になっていくようです。
以前v1.3以降でどんな構成になるのか調べたのですが、改めて調べておきましょう。
phx.new
まずはv1.2以前のphoenix.new
と、v1.3から入るphx.new
でつくられるプロジェクト構成を比較してみます。Phoenixのリポジトリをcloneして、installer
ディレクトリの中で以下のコマンドを発行。Phoenixのリビジョンは1.3.0-rc.0
タグのついた4d608bf
です。
$ mix phoenix.new app_with_phoenix_new $ mix phx.new app_with_phx_new --dev
phoenix.new
に--dev
つけたら--dev projects must be generated inside Phoenix directory
と怒られたのですが、ディレクトリ構成が見たいだけなので--dev
無しで。つくられたディレクトリをtree
で見るとこんな形式。一部省略してあります。
app_with_phoenix_new ├── README.md ├── config ├── lib │ ├── app_with_phoenix_new │ │ ├── endpoint.ex │ │ └── repo.ex │ └── app_with_phoenix_new.ex ├── mix.exs ├── priv │ ├── gettext │ └── repo ├── test │ ├── channels │ ├── controllers │ ├── models │ ├── support │ ├── test_helper.exs │ └── views └── web ├── channels ├── controllers ├── gettext.ex ├── models ├── router.ex ├── static ├── templates ├── views └── web.ex
app_with_phx_new ├── README.md ├── assets │ ├── brunch-config.js │ ├── css │ ├── js │ ├── package.json │ ├── static │ └── vendor ├── config ├── lib │ └── app_with_phx_new │ ├── application.ex │ ├── repo.ex │ └── web │ ├── channels │ ├── controllers │ ├── endpoint.ex │ ├── gettext.ex │ ├── router.ex │ ├── templates │ ├── views │ └── web.ex ├── mix.exs ├── priv │ ├── gettext │ └── repo └── test ├── support ├── test_helper.exs └── web ├── channels ├── controllers └── views
以前書いた
web
がlib
配下に入るmodel
という概念がなくなる
はそのままのようですが、加えて、これまでweb/static
配下にあったcss
、js
や、package.json
、brunch-config.js
がまるっとトップレベルのassets
に移っています。見慣れないapplication.ex
というファイルがありますが、これは上の例だとapp_with_phoenix_new.ex
に当たるもので、名称が変更されるようです。全体的にディレクトリ構成とモジュール名の対応関係がキチンとしていて、生成されたlib/app_with_phx_new/web/page_controller.ex
ではAppWithPhxNew.Web.PageController
モジュールが定義されていました。
defmodule AppWithPhxNew.Web.PageController do use AppWithPhxNew.Web, :controller def index(conn, _params) do render conn, "index.html" end end
ただ、よく見るとweb.ex
が入る場所が一段深くなっていて、lib/app_with_phx_new/web/web.ex
となっています。ここはモジュール名とファイル配置の対応が取れていませんが、Elixir ForumのJoséのコメントによると、意図したものであるようです。
phx.gen.json
次はphx.gen.json
を試してみます。まずはhelp
から。
$ mix help phx.gen.json mix phx.gen.json Generates controller, views, and context for an JSON resource. mix phx.gen.json Accounts User users name:string age:integer The first argument is the context name followed by the schema module and its plural name (used for resources and schema). The above generated resource will add the following files to lib/your_app: • a context module in accounts.ex, serving as the API boundary to the resource • a schema in accounts/user.ex, with an accounts_users table • a view in web/views/user_view.ex • a controller in web/controllers/user_controller.ex • default CRUD templates in web/templates/user As well as a migration file for the repository and test files for generated context and controller features. ## Schema table name By deault, the schema table name will be the plural name, namespaced by the context name. You can customize this value by providing the --table option to the generator. Read the documentation for phx.gen.schema for more information on attributes and supported options. Location: _build/dev/lib/phoenix/ebin
これまではmix phoenix.gen.json User users name:string age:integer
のように、スキーマのモジュール名とテーブル名、テーブル構造を引数に与えていましたが、Accounts
という第一引数が増えています。help
にある例をそのまま実行してみます。
$ mix phx.gen.json Accounts User users name:string age:integer * creating lib/app_with_phx_new/web/controllers/user_controller.ex * creating lib/app_with_phx_new/web/views/user_view.ex * creating test/web/controllers/user_controller_test.exs * creating lib/app_with_phx_new/web/views/changeset_view.ex * creating lib/app_with_phx_new/web/controllers/fallback_controller.ex * creating test/accounts_test.exs * creating lib/app_with_phx_new/accounts/user.ex * creating priv/repo/migrations/20170302235526_create_accounts_user.exs Add the resource to your api scope in lib/app_with_phx_new/web/router.ex: resources "/users", UserController, except: [:new, :edit] Remember to update your repository by running migrations: $ mix ecto.migrate
引数に与えたAccounts
がどこに効いているかというと、lib/app_with_phx_new/accounts/user.ex
のようにuser
のひとつ上の名前空間になっています。テーブル名も、特に指定しないとaccounts_users
となるようです。また、コンソールに出ていませんが、しれっとlib/app_with_phx_new/accounts/accounts.ex
も作られていました。このAccounts
モジュールはいわゆる「境界づけられたコンテキスト」のひとつで、他のモジュール、例えばUserController
は、User
モジュールに定義した関数を使ったり、Repo.all(User)
のようなことはせず、このAccounts
モジュール経由でユーザの操作を行うようにしましょうね、という意図があるようです。生成されたファイルの中を見ても、UserController
のindex
アクションでは、Accounts.list_users
を使ってユーザ一覧を得るようになっていました。User
モジュールはスキーマ定義があるだけでほぼ空っぽで、テストもUser
ではなくAccounts
モジュールのものが作られています。
ただ、生成されたAccounts
モジュールの中に以下の関数が定義されており、少々やりすぎではという印象でした。Accounts
モジュールが太っていきそうなので、自分ならこれは今まで通りUser
モジュールに移します。
def AppWithPhxNew.Accounts do ... defp user_changeset(%User{} = user, attrs) do user |> cast(attrs, [:name, :age]) |> validate_required([:name, :age]) end end
defmodule AppWithPhxNew.Accounts.User do use Ecto.Schema schema "accounts_users" do field :name, :string field :age, :integer timestamps() end # ここにchangeset/2を書きたい end
なお、lib/app_with_phx_new/web/controllers/fallback_controller.ex
という馴染みのないものがありますが、ちょっとここでは深掘りしません。
まとめ
ざっくりまとめると、
ということをフレームワークが緩く強制するということのようです。
ニポポタマスを支える技術
こんにちは。
わたくし、勤め先の有志と社内向けの日報投稿Webサービス、ニポポタマス(通称ニポタマ)をやっています。元々は会社の開発合宿でつくりはじめたものですが、会社のみんなが日々の出来事、書きたいことを書ける場として、また僕ら開発者がやりたいことをいろいろ試せる場として、9月半ばから、ざっくり5ヶ月くらい開発・運用してきました。そろそろ使っている言語やフレームワークについて、どんな感じに使っているのか、また思うことなど書いてみます。
Elixir/Phoenix
ニポタマはElixir/PhoenixによるJSON APIサーバをバックエンドとしたSingle PageなWebアプリです。ElixirとPhoenixってなんぞや、という方にはこの動画がおすすめです。
基本的には単にJSONを返すAPIなので、至って普通のPhoenixアプリケーションです。とくにumbrellaプロジェクトにしているわけではなく、mix phoenix.new --no-html --no-brunch
から初めています。データベースもデフォルトのPostgresです。なお、このAPIサーバはbodyというコードネームで開発しているので、以降bodyと表記します。Elixirを採用したのは、僕が使いたかったからです。完全に僕の独断で、他の開発メンバーは未経験なので、mix phoenix.server
やmix edeliver deploy release production
などの見慣れないコマンドは、npm start
、npm run deploy
でラップしています。
所感
Elixir(Erlang)で書いてよかったなと思っているところは、非同期処理が簡単に書けることと、OTPの力です。
非同期処理
普通のWebアプリで非同期処理というとジョブキューなどを使うことが多いと思いますが、Erlang VMではプロセスをspawnすることで簡単に非同期処理を書くことができます。ニポタマでは、ログイン時の認証にSlackを使っており、ニポタマにおけるアイコンはSlackアイコンと同じものです。アイコン画像を保存しているわけではなく、URLを保持しているのですが、Slackのアイコンを変えたときにリンク切れになってしまうという問題があります。暫定対応として、ログイン時にその人のSlackアイコンURLを保存しなおしています。アイコンURLはOAuthのフローの中で取得できるので改めて取り直すことはしませんし、保存はUPDATE
クエリ1回だけなので、とくに時間がかかるわけではありません。ですが、ユーザへのレスポンスはすでに返せる状態にあるのに、こちらの都合でわずかな時間でも待たせるのはどうなんだという建前と、ちょっとかっこいいよねという本音から、非同期に保存をするようにしています。コードとしては以下のように、コントローラの中でTask.start/1
を使っています。滅多にないと思いますが仮に失敗してもクリティカルな問題にはならないので、クラッシュしても何もしていません。
defmodule AuthController do def login(conn, params) do ... user = User.get_by(slack_id: slack_id) case user do nil -> need_signup(conn, access_token) user -> async_update_slack_account(user, %{avatar_url: avatar_url}) conn |> put_status(201) |> render(AuthView, "show.json", %{user: user}) end end defp async_update_slack_account(user, params) do Task.start fn -> user.slack_account |> SlackAccount.changeset(params) |> Repo.update end end end
OTP
OTPとは、Erlang VMで動くアプリケーションをつくるときのライブラリやフレームワークやデザインパターン集みたいなものです。Phoenix自体もOTPアプリケーションですが、PhoenixはErlang VMで動くOTPアプリケーションたちのWebインターフェースとして捉えるべきかなと思っています。ここで言いたいのは、Phoenixの後ろ側に機能を追加することで、Webアプリとしても幅が広がるんですよ、ということです。OTP自体の説明が難しかったりあくまでフレームワークなので「こんなことができるようになります」というのも難しいのですが、例えば先ほど書いたSlackアイコンのURLを更新する実装では、アイコンを変えた後にログインしてくれないと、いつまで経ってもリンク切れのままという問題があります。定期的に任意の処理をするサーバを書けば解決するので、あとでやりたいなと思っています。quantumなどのジョブスケジューラを使ったりしてもいいかな、という気持ちですが、結局quantumも中身を見るとGenServer
をつかったOTPアプリケーションです。
他には、昨年末に以下のような集計をして、2016年のまとめのようなページを作ったことがあります。
- 2016年に投稿された日報の数
- 2016年に最も「otsu」されたひと(otsuはlikeみたいなものです)
- 2016年に最も「otsu」したひと
- 日報投稿から最速で付けられた「otsu」
- などなど
これらをJSONで返すコントローラはEctoを経由してSQLで集計をしているわけですが、アクセスがある度に集計するのは無駄なので、キャッシュしようと考えるのが自然です。そんなときに、redisやmemcachedを立てなくても、キャッシュしてくれるOTPアプリケーションを導入すれば問題を解決できます。ニポタマではcon_cacheを使いました。一部省略したコードを以下に示します。
defmodule SummaryController do def index(conn, %{"year" => "2016"}) do data = ConCache.get_or_store(:summary_cache, :summary, fn -> %{ users: SummaryService.registered_people(), nippoes_count: SummaryService.nippoes_count(), otsukares_count: SummaryService.otsukares_count(), longest_nippoes: SummaryService.longest_nippoes(), shortest_nippoes: SummaryService.shortest_nippoes(), fastest_otsukare: SummaryService.fastest_otsukare(), most_otsukared_nippo: SummaryService.most_otsukared_nippo(), otsukare_giver: SummaryService.otsukare_giver(), otsukare_getter: SummaryService.otsukare_getter() } end) render(conn, "index.json", data) end def index(conn, _opts) do conn |> put_status(404) |> render(ErrorView, "404.json") end end
アプリケーションサーバが1台であったり永続化したいときはそれほど旨味を感じませんが、Erlangクラスタを組んだときなどは複数ホストでキャッシュを共有できる(はず)ので便利かと思います。
Vue.js
ユーザが実際に触れる部分は、Vue.jsで実装されたSPAです。faceというコードネームで呼んでいるので、以降faceと書きます。Vue.jsは、script
タグでちょいっとCDNから読むだけでも使えて、かつ、ある程度の規模のSPAも実装できるフレームワークと言われています。開発メンバーの@hypermktさんがぜひVue.jsでSPAを試したいということで採用が決まりました。開発初期はv1系でしたが、Vue.js 2.0のリリースから約1週間後には、v2にバージョンアップしていました。SPAとして動かすため、vue-routerやvue-resourceなどのライブラリも使用しています。vue-resourceは、そろそろaxiosに替える予定です。
所感
学習コストという言葉はあまり好きではありませんが、つくれるものの規模を考えると、学習のコスパは良いと思います。僕が見えていない部分もあると思いますが、それほどフレームワークとして巨大でなく、日本語版のドキュメントもあるので、未経験でもわりとすぐに開発に入れた印象があります。
またvuexは使っていませんが、ニポタマくらいの規模のアプリケーションでも導入してもいいんじゃないかと思っています。公式のドキュメントには中規模から大規模なアプリケーションで導入を検討するとよいということが書いてありますが、APIからデータを取ってきて見せるくらいのSPAで使っても、特に都合の悪い点は無いと思います。ニポタマくらいの規模と言っても伝わらないと思うので、参考までにsrc
ディレクトリ以下の*.js
、*.vue
の行数は合計約2000行、ルーティングは以下の通りです。
let router = new VueRouter({ routes: [ {path: '/', component: FlashMessage, children: [ {path: 'signup', component: Signup}, {path: 'profile', component: Profile}, {path: '', component: Top, children: [ {path: ':date', component: ListNippoes, name: 'nippoes'}, {path: ':date/new', component: NewNippo}, {path: ':date/edit', component: EditNippo}, {path: '@:user_name/life/:date', component: Life} ]} ]} ] });
開発中にちょっと気をつけたほうが良いなと思った点として、VueのMixinはあまり使い過ぎないことをおすすめします。複数のMixinをコンポーネントに入れていくと、どこで定義されたのかパッと分からないメソッドが増えていってしまいます。
テスト
ロジックの複雑なクラスに絞って、ランナーはKarma、フレームワークはMocha、アサーションはChaiを使ってテストを書いています。コンポーネントのテストについては@hypermktさんによるブログエントリが詳しいです。E2Eテストは一切やっていません。E2Eテスト自体をメンテナンスするコストと、E2Eで得られるであろう恩恵を比べての判断です。
Go/Echo
ニポタマでは、家からも読み書きできて、かつ社外の人には日報を読めないようにするために、ユーザ認証にSlackのOAuthを使っています。OAuthにはstateパラメータというものがあり、これを使って、認証を要求した人と認証できたよと言っている人が本当に同じなのか、ということをチェックしています。ざっくりとした順序は
- セッションにランダムな文字列を記録する
- 同じ文字列をパラメータにつけてSlackの認証画面へ飛ばす
- ユーザがSlackにログインする
- codeと先ほどの文字列がstateパラメータに付いてリダイレクトされてくる
- セッションにある文字列と比較して一致したらcodeを使ってaccess tokenを得る
という感じです。これをサボるとCSRFなどのリスクが生まれるのですが、開発初期はサボっていました。後になって対応しようとなったときに、APIサーバにこの役割を追加するか、別の言語で小さなサーバを書くか検討して、楽しそうな方を選びました。実装にはEchoというフレームワークとGorilla Toolkitのsessionsパッケージを使っています。役割上faceのCSSを使うことがあるので、faceと同じリポジトリに入れてしまっています。
役割
このサーバがどんな仕事をしているのか説明します。認証に関することをしているのでauthと呼んでいましたが実際よく見るとgatewayなどが適当かな、と思うので、gatewayサーバと呼んでいきます。まずリクエストを受けるnginxは、/login
はgatewayサーバへプロキシし、/
ではfaceをserveするように設定してあります。/login
に来ると、gatewayがランダムな文字列をセッションとLogin with Slackボタンに埋め込みます。Slackログインしたユーザがリダイレクトされてくると、セッションに入れた文字列とstateパラメータを比較して、違っていたらエラーを表示します。両者が一致したら正当なログインなので、codeをbodyに送ります。bodyはSlackとやり取りし、以下の3通りの応答をしてきます。
- 既にニポタマユーザとして登録済みである。ユーザ情報とJWTを与えよう
- ニポタマにユーザ登録する資格がある。サインアップへ進むのだ
- ニポタマにユーザ登録する資格がない。採用サイトへ飛ばせ
これらの内いずれかのレスポンスを受けたgatewayはfaceの適切なURLへリダイレクトします。faceはbodyとやり取りする中で認証に関するエラーを受けると/login
へリダイレクトし、認証やり直しとなります。なお、ここでのユーザ登録する資格があるか、とは、弊社Slack teamのメンバーとしてログインしてるか、などを見ています。
所感
ポン置きとはこのことか、というくらい、デプロイの簡単さに驚きでした。ビルドしてrsync
しておしまい。デプロイ後の起動はsystemd
でやっています。
GOOS=linux GOARCH=amd64 gom build -o ./auth_server server.go rsync -av -e ssh ./auth_server np-app:~/auth_server
Goで動くものを書いたのはほぼ初めてだったので、動いてるっぽいけどこんな書き方でいいのだろうか、という手探りな状態でした。あとで有識者に見てもらおうかと思います。
WebSocket
ニポタマをつくる上での哲学として、リアルタイム性に重きを置いており、誰かのアクションが他のユーザの画面にすぐに反映されるようにしています。具体的には、日報につけられたotsuや、日報が書かれている途中の様子は、画面を見ている他のユーザにWebSocketで配信されるようにしています。これは開発画面で2つウィンドウ開いて、片方で日報を書いているところです。日報が書かれている様子が見えています。まだ保存していない段階では、あえて誰が書いているのか見せないようにしているのですが、これが意外と楽しかったりします。
実装としては、サーバ側はPhoenixのChannel、クライアント側はそのクライアントを使っています。仮にクライアントの環境がWebSocketを使えない場合は勝手にLong Pollingにフォールバックしてくれます。簡単にコードを示すと、クライアントはtextareaのkeyupイベントで日報の内容が変化していたらnippo:update
イベントと共に日報の内容をサーバに送ります。それを受けたサーバは、送られてきた内容をその他のクライアントにbroadcast
しています。接続はVueのmounted
ライフサイクルで行っています。
// クライアント // socket.js import config from '../config.js'; import * as Phoenix from 'phoenix'; let socket = new Phoenix.Socket(config.websocketUri); socket.connect(); export default socket;
// クライアント <template> <textarea v-model="content" @keyup="pushUpdate" required></textarea> ... </template> <script> import socket from '../../lib/socket'; export default { ... mounted() { ... this.channel = socket.channel(`nippoes:${today}`, {token: token}); this.channel.join(); }, methods: { ... pushUpdate: function() { if (this.content !== this.contentOld) { this.contentOld = this.content; this.channel.push('nippo:update', {content: this.content}); } } } } </script>
# サーバ defmodule NippoChannel do ... def join("nippoes:" <> _date, %{"token" => token}, socket) do case User.from_token(token) do {:ok, user} -> {:ok, assign(socket, :user_id, user.id)} _other -> {:error, %{reason: "Unauthorized"}} end end def handle_in("nippo:update", %{"content" => content}, socket) do payload = %{ user_id: socket.assigns.user_id, content: content } broadcast(socket, "nippo:update", payload) {:noreply, socket} end end
所感
WebSocketを使うとサーバからのpushができるようになるので、表現の幅がグッと広がるなと感じています。アプリケーションとしてできることも増えますし、提供できる体験も変わってくると思います。ただし、ユーザの環境によっては接続が切れやすかったりするので、その点は留意したほうがよいでしょう。今後やりたいこととしては、Phoenix.Presence
で接続しているユーザの一覧が取れるので、何かおもしろい表現ができないかなと考えています。
Web Speech API
ニポタマには、投稿された日報を読み上げる機能があります。読み上げはブラウザのSpeechSynthesis APIを使っています。以下のようなmixinを用意しています。
export default { data() { return { synthes: null, speech: null, } }, created: function() { if (typeof SpeechSynthesisUtterance !== 'undefined') { this.synthes = new SpeechSynthesisUtterance({lang: "ja-JP"}); this.synthes.onend = () => { eventHub.$emit('set-is-playing', false); } this.speech = window.speechSynthesis; } }, methods: { speakAll(date, nippoes) { if (this.synthes !== null) { eventHub.$emit('set-is-playing', true); let text = date + 'の日報が' + nippoes.length + '件あります。'; text += nippoes.map(d => this.breathingString() + `${d.user.nickname}さんの日報です。${d.readable_content}`).join('。'); text += this.breathingString() + 'みなさんおつかれさまでした。'; this.synthes.text = text; if (this.speech.paused) { this.speech.resume(this.synthes); } else { this.speech.speak(this.synthes); } } }, // 0.5秒くらい間を開けます breathingString() { return "。\n。\n。\n。\n。\n。\n"; }, stop() { if (this.synthes !== null) { eventHub.$emit('set-is-playing', false); this.speech.pause(); } } } } if (typeof SpeechSynthesisUtterance !== 'undefined') { this.synthes = new SpeechSynthesisUtterance({lang: "ja-JP"}); let text = `${name}さんの日報です。${body}`; this.synthes.text = text; speechSynthesis.speak(this.synthes); }
SpeechSynthesis APIは漢字もちゃんと読んでくれるのですが、弊社のサービス名や略語など、例えばminne(ミンネ)やMTG(ミーティング)は正しく読めないので、日報を保存する前に@mickey19821さんが作ったRailsアプリに本文を送り、ちょっとだけ読みやすく置換したバージョンも保存して、読み上げにはこちらを使うようにしています。
所感
音声合成を手軽に使えるのはありがたいのですが、いささかWebサービスの中での使い所が難しいなと思います。また上のコードを見るとわかるように、句点や改行を挟んだり涙ぐましい細かい調整をしています。ただ色々やってもそれほど聴きやすい音声とは言えない印象です。十分すごいテクノロジーだとは思いますが、自然でなめらかな音声を期待するとアレっと感じると思います。実は開発初期はこの読み上げ機能をニポタマの目玉としていたのですが、いざ作ってみると開発陣としてもやや前衛的すぎるなと感じています。
PostCSS
ニポタマのデザインとマークアップは@shikakunさんが担当しており、CSSはPostCSSを使って書かれています。利用しているプラグインは以下の通りです。
- autoprefixer
- postcss-apply
- postcss-cli
- postcss-csso
- postcss-custom-media
- postcss-custom-properties
- postcss-hexrgba
- postcss-import
- postcss-mixins
- postcss-nested
// .postcssrc.json { "use": [ "autoprefixer", "postcss-apply", "postcss-csso", "postcss-custom-media", "postcss-custom-properties", "postcss-hexrgba", "postcss-import", "postcss-mixins", "postcss-nested" ], "input": "src/css/style.css", "output": "public/assets/style.css", "autoprefixer": { "browsers": "last 2 versions" } }
所感
CSSにはあまり明るくないので、Sassなどよりどのくらい書きやすいのかわかりませんが、こういう将来の仕様を先取りできるのはレガシー化を防ぐ上で重要かなと思っています。いつかはこのコードも古くなりますが、少なくとも今書き始めるならこうなのでは、という印象です。(書いてないくせに偉そうなこと言ってる。)
Open API
JSON APIの仕様はOpen API 2.0に則ってyamlに書いており、そのyamlファイルをbootprintとbootprint-swaggerに与えて、APIドキュメントを生成しています。bodyと同じリポジトリの中で管理していて、npm run doc:deploy
を叩くと、手元でビルドしてその成果物がrsync
でデプロイされるようにしています。ドキュメントはBASIC認証だけかけて、どこからでも見れるようにしています。
所感
最初にえいやっと仕様だけ書いてしまえばドキュメント生成はライブラリに丸投げできるので、導入は楽だなと感じています。ただ、がっつりカスタマイズしたいようなときはそれなりに茨の道です。APIドキュメントについては最近考える機会があり、もうちょっとイケてる構成ができないかなぁと思っているので、この辺はまた後で何か書くと思います。
インフラ
ニポタマは、弊社のOpenStack環境Nyahの上で動いています。サーバの構成は
- 踏み台サーバ
- アプリケーションサーバ
- DBサーバ
の3台です。ロールとしてはもっとあるのですが、アプリケーションサーバという名の1台にリバースプロキシ(nginx)、body、Goのgatewayが動いており、faceとAPIドキュメントの静的ファイルも置いてしまっています。api
、doc
など細かくサブドメインを切っていますが、バーチャルホストを設定して全てこの1台で受けています。構成管理はitamae、SSLはLet’s Encryptにお世話になっています。DBのバックアップは主にオペミス対策として1日に1回取っていて、過去14日分だけ保持しています。幸いまだ役に立ったことはありません。
所感
元々はherokuからスタートして、その後クラウド便利だな〜くらいの感覚でNyahに普通な構成で移行してしまったのですが、時は2017年なので、例えばDockerで動かしたりするのもいいのかなと思っています。Elixir、node.js、Go、Rubyなどいろんな言語を使うようになってきている(次はPHPが入る予定)ので、本番環境よりむしろ開発環境でDockerを使うと何かと楽になりそうです。
まとめ
ざーっと書いてきましたが、改めていろいろと手を出してきたなという感じです。とはいえ実サービスではこんなにホイホイぶち込むこともできないので、これからも砂場として興味のあるものを試しながら運用していきたいなと思います。おつかれさまでした。
あっちこっちでpreload問題
こんばんは。
Ectoでは関連を明示的にpreloadすることがよくあります。例えばUser
がPost
を複数持っていて、それをUserController
のshow
アクションでこんなjsonで返したいとき、
{ "user": { "name": "joe_noh", "posts": [ {"title": "...", body: "..."}, {"title": "...", body: "..."}, {"title": "...", body: "..."} ] } }
viewはこんな感じに書いたとします。
defmodule UserView do def render("show.json", %{user: user}) do %{user: render_one(user, __MODULE__, "user.json")} end def render("user.json", %{user: user}) do %{ name: user.name, posts: render_many(user.posts, PostView, "post.json") } end end defmodule PostView do def render("post.json", %{post: post}) do %{ title: post.title, body: post.body } end end
"user.json"をrenderするとき、posts
をpreloadしておかないと、user.posts
は
#Ecto.Association.NotLoaded<association :posts is not loaded>
という初期値のままなので、protocol Enumerable not implemented
などエラーが出ます。で、どうするかというと、preloadです。以下のようにしておくと、user.posts
にPostのリストが入って意図したとおりにrenderできます。
user = Repo.preload(user, :posts)
はい、ここで問題。このpreloadはどこでやるべきか。MVCで言えばMに関数つくって、Cから呼ぶ、というのがベタかなと思ってやっていたんですが、段々と
いろんなとこで同じようなpreload書き始めちゃって散らかっちゃって。ある時点のuser
の関連はどれがpreload済みでどれがpreloadされてないのか分からんという。なんとなく思っている程度なんですが、ビジネスロジックのためにpreloadしているところと、renderするためにpreloadしているものが混ざると苦しくなるんじゃないかなぁという気がしています。
じゃあどこにまとめようかということで、最初は自分でも狂ってんなと思ったんですが、Viewでいいんじゃないの、と考え始めました。各Viewモジュールがrenderに必要な属性を知ってて、こんな感じに何をpreloadしたらいいのか教えるようにする。
defmodule UserView do def render("show.json", %{user: user}) do user = preload_requirements(user) %{user: render_one(user, __MODULE__, "user.json")} end def render("user.json", %{user: user}) do %{ name: user.name, posts: render_many(user.posts, PostView, "post.json") } end def requirements do [posts: PostView.requirements] end defp preload_requirements(user) do Repo.preload(user, requirements()) end end defmodule PostView do def render("index.json", %{posts: posts}) do posts = preload_requirements(posts) %{posts: render_many(posts, __MODULE__, "post.json")} end def render("post.json", %{post: post}) do %{ title: post.title, body: post.body, comments: render_many(post.comments, CommentView, "comment.json") } end def requirements do [comments: CommentView.requirements] end defp preload_requirements(post) do Repo.preload(post, requirements()) end end
考え方としては、renderに必要なやつらはViewがカバーしてくれるんで、MやCではその辺忘れていいよってとこです。まー気をつけないと循環しちゃったり、使わないやついっぱいpreloadしちゃったりしそうなんで、どうなるかなというとこですが、ちょっとこれで行ってみようかな。