Play+Slick雑感

playframeworkでcommon-apiを作ってた感想。

  • 採用理由

具体的にはファイル渡しをしているところを全部APIで叩いてもらえますように、という作りを目指した。 各webサーバーのバックグラウンドにjavaがあるのが嫌だったので HTML + JS + CSS + etc でwebサービスを作れるようにしたかった。 部署的に基本どのユーザーへも同じような情報を表示しているのでこれでもぜんぜんいけるじゃね?と思って。 フレームワークはPlayframeworkを採用した。理由は使っていたから、とキャッチアップしていきたかったから。 高負荷でのパフォーマンスはかなり良い、との前評判があったから。 逆に懸念点としてはキャッチアップするのが大変、マイナーバージョンが上がりすぎる、 release candidateがすぐさま出る。という悲惨さがあった。 もうなくなるらしいけど2系で採用されている標準ormのanormというものがだめすぎるという話はよく聞いていたし、 ちょっと不安でしたけどまあscalaで書けるんだしやってみよっかなというくらいののりで。

  • akkaのチューニングがよくわからん

これはいまだにわからない。 タイムアウトを3秒にして3秒以内に返せるようにした。 レスポンスをはやくするためにactorを超いっぱいにしてみたりとかがんばってみたけど もちろん十二分に速いけどそこまでCPU負荷があがっているわけでもない。 負荷のかけかたがゆるかったのかもしれないけどそれもよくわからなかった。 まだ検証の余地がある。

  • 超楽

前回適当な管理ツールを作成したときにplay+slickに慣れていたこともあったので なれたものだった。ちょっとはまったところとしてはslickでjodatimeを使うようにしたのだが、 jodatimeだとslickのqueryをつかってbetweenが組み立てられないということだった。 そこは仕方なく変換をかまして以前同様のjava.sql.Timestampを使うことにした。(ださい) 今後の課題としてjodatimeで問題なく使えるような方法を探してみる。

  • モジュールの切り方でなんか失敗した

モジュールを分けるように設計してみた。 core <- モデル層やサービス層やら batch <- quartz で実行されるジョブクラス、ジョブを手動実行するコントローラー api <- api側のコントローラー というふうにしてみたのだが、よくわかってなかったから module配下の各プロジェクトにglobalを用意してしまった。 トップディレクトリのapp配下にもglobalを用意したので競合することとなってしまった。 結果単体テストがめんどくさくなった。まとめりゃいいだけなんだけど。

Published: July 26 2013

  • category:
  • tags:
blog comments powered by Disqus