【Scala】 playframework2.5とslick3でwebサーバを書いた話
目次
- タイトルの通り
なぜこんなことをした！言え！
- Fate/EXTRAで敵のパターンをテキストに記録し続けるのが億劫になってきたから
- ブラウザ上でポチポチしてパターンを記録したり絞り込んだりできる奴作ろうと思って
- nodejs辺りでさくっとやっても良かったが、DB周りが不安だったので、過去にやったことのあるplay slickで
どこで使い方を習った
公式ドキュメントを読んだのよ
公式ドキュメントにしたがってactivatorの最新版（ここでは2.5）をダウンロード/インストール
PlaySlickの公式ドキュメントにしたがって依存性解決
application.confに適切な設定をしたらコーディング開始
Eclipse使ってるんで、plugin.sbtにsbteclipseの設定も忘れずに
今までの（play slick）とは違うよ！
- playframeworkは2.4になってからDIのサポートを始めたり、DBActionを廃止したりしてる
- 前に書いた時は2.3.6だったので、書き方が全く変わっていて戸惑った
DI（Dependencies Injection）
依存性の注入（いそんせいのちゅうにゅう、英: Dependency injection）とは、コンポーネント間の依存関係をプログラムのソースコードから排除し、外部の設定ファイルなどで注入できるようにするソフトウェアパターンである。英語の頭文字からDIと略される。
!cite:https://ja.wikipedia.org/wiki/%E4%BE%9D%E5%AD%98%E6%80%A7%E3%81%AE%E6%B3%A8%E5%85%A5!
!title:依存性の注入 - Wikipedia!
例えば、あるdaoを使いたいserviceが、そのdaoのインスタンスをnewするコードを含まなくても良い
- でも、型は書かなきゃダメなんですよね
- しかもimportしないといけないので、ソースコードから依存性の記述を排除できていないのでは？
こいつが力を発揮するのは、例えば上記の例ではdaoが共通であるクラス（dao基底）を継承している場合
- ソースには基底だけ書いて、実際の型の記述は設定ファイルに追い出すことができる
- これを利用すると、test時に使いたいmockの型を設定ファイルから読み込むだけでtestが簡単に書ける……んじゃないかな？
ぶっちゃけてしまうと、今回書いた程度の規模のサーバではそんなにありがたみがない仕組みだった
- 規模を大きくしてテストもガッチリ書くプロダクトでなら嬉しいのかも
daoを書く際にdb設定をDIで注入しないといけないのに注意
さよならDBAction 未来を信じて
これのおかげでかなり楽にかけていたが、2.4から廃止された
基本的にAction.asyncを使ってFutureを返せということらしい
daoからの戻り値は基本的にFuture型に固定される
Future型は、「結果はまだ確定していないが後で確定するから処理を続行してくれ」という「ここは俺に任せて先に行け」を地で行く型
例えばDBアクセスは重いので、「その後に書かれているがDBアクセスの結果を使わない処理」を先にやってしまえるならそのほうが効率が良いよね、というようなこと
これもやっぱり小規模なサーバではそんなにありがたくない
Optionと同じくMonadなので、mapとか諸々を使える
成功/失敗判定をして別々の処理をさせる記述も可能
- 例外処理をしっかり書くことが推奨されるようなDBアクセスとかはそれが書きやすくて良いのかも
罠
- activator new時に生成されるapplication.confはslick用にチューンされていない
- slick用の設定を必ず自分で書くように
欲しかった安心は手に入った？
- 書くだけ書いてまだ運用していないが、微妙な気がしてきた
- ポチポチする事が面倒になるのがなんとなく見えている
- とは言え、目grepでパターンを探さなくても良くなるのはちょっと期待してる
運用してみて（2016/05/31追記）
- ４回戦のランルーくん戦でめっちゃ威力を発揮
- これ、パターンをテキストに記録して目grepとかしてたら気が狂うレベルにパターンが多い
- しかし、ExMatchを使えば何度もリトライして死に覚えゲーすることでかなりのパターンを網羅できる
使えるの？
- githubには置いてあるけど、DB空っぽなので１から登録してかないといけないです
- そのうちcsvにでもしてデータロードできるようにしたい