久しぶりになってしまいましたが、生きてます。
4月からフリーランス生活していて、初月ということもあって個人開発の方の進捗がなかっただけです
さてさて、タイトルの通り噂の土善旅館へ行ってきました。
エンジニア雑談Slack mohikanz による開発合宿。
個人で好きに自分のやりたいことをやる24時間温泉に入れるスーパー快適な開発合宿でした
猫と戯れることもできるとかここが天国か…
さて、エンジニアが何人も集まると色々と知見が集まるので、快適環境が更に快適になるという最高の循環だったんですが、自分は兼ねてから「ヒトカラ」を記録したり、これ歌いたい!を管理するアプリを作りたいと言っていた 不知火/しぃ (@shiranuik) | Twitter さんとアプリを作ることに。
自分は主にバックエンド側担当で。
やっていこう
技術スタック決めるとこ
ここからちょっと技術の話。
せっかくなので、どういう流れでものが決まっていって、どういう作業をしたのかを書いておこう。案外個人開発だとこのあたりの話ってないことが多いので。
Docker-composeはインフラエンジニアの方に用意していただき(多謝)、主な構成はこんな感じに
- nginx
- MySQL 5.6
- JDK11
- JIB
- Spring Boot
メインに据えたのは上記のような感じ。REST APIで単純にJSONのやりとりするだけでいい感じにしとくのと、データストアはNoSQLとどっちがいいの?ユーザー増えたとき大丈夫?構造変化平気?とか、色々考えた結果、この形になりました。RDBが結局楽だよねっていう。
SpringBootにしたのは、最近自分が仕事でSpring畑に戻ってきていることと、しらぬいさんがJavaならわかるというので、とっつきやすいのでこちらにしました。
色々決めていくぞフェーズ
上の技術スタック決めたら次はアプリの中身に迫っていく。
具体的には作りたいもののモデル、データ構造の周りを構築していく。
データ構造が決まらないと、APIがどういう形式で返したらいいかわからないし、クライアントもどういうデータを送ればいいかがわからない。サーバーもクライアントもそのやり取りを中心にまずは考えていった。
ヒトカラの記憶ということでね、ユーザーを中心に据えていくというアプローチで周りを埋めていく。
クライアント側のログイン認証はFirabaseを使うので、Emailが中心。という具合に決めていって要素決めたら、あとは実際のモデルにしていくだけ。
このあたりは決まっていけばすんなりいけるはず
検証しておこうフェーズ
上記も話し合いつつ、実は裏で色々検証しておかないといけないことが結構あってそっちをやりながら、どうしよっかーなんてふわっとした会話しつつ検証してた
自分が合宿中に検証してたのは以下の通り
- SpringBootを使ったJsonを返すREST APIのサンプル作成
- RDB周りのミドルウェア何を使うか
- テストコードのサンプル
一個一個簡単に見てく
SpringBootを使ったJsonを返すREST APIのサンプル作成
SpringBootを仕事で使ってるとはいえ、まっさらな環境を1からってのはやったことがないので、土壌作りから。
最初の時点ではlombokもJacksonもなんにもないので、pom.xmlに追加したりしながら書きっぷりと実際にSpringBootを起動してエンドポイントにローカルホストでアクセスしたりして見てた。
サンプルが必要なのは、今後の実装をスムーズに入るための助走みたいなもので、これがあるなしでスタートダッシュが違ったりする。見えてるものが多いほうが登りやすいっていう理屈。スパイクともいうかな。
RDB周りのミドルウェア何を使うか
MySQLなのは前述した通りなのだけど、じゃあアプリの中でどういう風に扱うかという話。
ORMが楽だけど、何を使うかとか。
今回はMyBatisを選択。コレのいいところはSQLをXMLに書き出しちゃえるから、分離が容易で、検証も個別にできるところ。
生SQLに近いのでクエリが読める人なら何をしているかがファイルを見れば一目瞭然だし、増やすときも作法が確立されているし、記述量も少ない。何よりモデル側に余計なことを基本的に書かなくていい
個人でぱぱっとやるには悪くない選択肢だと思う
テストコードのサンプル
この辺が決まってくると
- ドメイン層
- プレゼン層
がはっきりしてくる。
あんまりサービス層を書く予定はなし。(そんなに複雑なロジックがない予定なので)基本的にはプレゼン層からドメイン層(MyBatisのマッパーインタフェース)をコールして結果が返るだけみたいな作り。
で、その各層のテスト・・・つまり
- Mapperのテスト = データベースのクエリ検証 − コントローラーのテスト = 実際のエンドポイントからクエリを発行
っていうテストを基本的にはすることになる。
これもコードサンプルがあるとスタートダッシュに有利。あとテストのとき、データベースどうするかで課題が出てくる。
マイグレーションツールの選定
DBマイグレーションツール。恥ずかしながら全然知識がなかったけど、色々知見を聞いてみてFlywayを使うことに。
バージョン管理ができるマイグレーションツール(SQLファイル名にルールがある)なので、git管理できるし、テストのときにもそれを動かせる。個人的に今回はかなり刺さったツールその1。
ちなみにテストリソース側におけば、テスト実行時だけ動かす事ができるので、テストデータ投入ができたりする。これも個人的にはポイント高いと思う。テストコードにデータを入れるというコードが消えたのは本当に楽。
テスト時のDBについて
ということで、物理DB使いますか、どうしますかという話。
今回はH2を選択。まだ規模も小さいしオンメモリに乗せてテストしてる。
これはスケールしたときに物理側に動かせばいいかなっていう思惑。スピード重視のため、まずは設定が楽な方で。
ちょっと初期設定でハマって、すぐにはできなかったんだけど、これも設定周りちゃんと書ければサクサク動く。
Flywayと組み合わせると、起動のたびにFlyWayが動いて、セットアップしてくれるからテストの再現度も高いのが個人的にはお気に入りポイント。繰り返し実行による汚染がないのは素晴らしい。
結局サーバーサイドの開発構成どうなった
こうなった
- SpringBoot
- MySQL
- Jacson
- lombok
- MyBatis
- FlyWay
- H2
- Jib(Docker生成用)
- 裏ではDocker-compose。
実際どこまでいった
サンプルなりの技術検証したあと、実際のアプリで検索するところまで書いて、Mapperのテストは素直にかけたんだけど、コントローラーのMockMVCを使うテスト書いてる途中でタイムアップ。
今日やり残した部分をガリガリ書いて、このあたりをクリアしたので、APIを用途に分けてガリガリ生やしていけるところまで来て満足してこの記事を書いてます
クライアントサイドはVueでやるという話だけ聞いて、作ってもらった画面をちょっと見てるだけなので、そのうち形になって出てくるのが楽しみです。自分はとりあえず必要そうなAPIを生やしていく係なのでw
締め
ということで、個人開発で1から作り上げるときのセットアップ周りと検証とか何していくのっていう部分をメインに書いてみた。
やっていて思うのはやはり環境周りの整備が大変でそこで挫けてしまうことはあるなっていうところ。
もっと別のフレームワークであればさくっといくわっていうケースはありそうだけど、今の自分はこれでうまくいっているので満足。
なにか進展があればまた記事にしていきたい。
シャドバの方もやらなきゃな!