拙いながら、ハンズオンを作ってみた話

2025-05-13

概要

Goでレイヤードアーキテクチャの書き方を学んでいる際に、

「技術の管理、差し替えがしやすいというメリットを最大限活かしたコンテンツを作れないかな…」

と思ったのがハンズオンづくりの始まりでした。

そこで、

といった手順を、アプリケーションの実装を気にせずに演習できる環境が用意できるのではないかと思いつきました。

これなら、サークルの中で「デプロイやセットアップの初歩をやってみたい」と思っているもののなかなか手が伸びない人にも、手元のVMで演習できるという手軽さをもって提供できるかな、という目論見もありつつ…

ですが、思いつきと勢いだけで始めたこのプロジェクト、結構大変でした。

ここには、苦労したところ、結構うまく行ったところを綴っていきます。

GitHub - saitamau-maximum/Maximum-Infra-hands-on

Contribute to saitamau-maximum/Maximum-Infra-hands-on development by creating an account on GitHub.

今回は簡易的なチャットアプリを作ってみました。理由はDB登録やWebsocketなどの技術を混ぜたほうがコンテンツが増えると踏んだからです。

でも、これをレイヤードアーキテクチャで書くのがむずいのなんの。

フロントエンドも、ユーザー認証のためのロジックや文面チャットの無限スクロールなどがあって…

でも、フロントエンドがちゃんとしてないと見栄えが悪い上に遊んでもらう側のモチベーションが下がりそう。

バックエンドをサボると技術差し替えが難しくなって根底が揺れる。

ということで、この部分にかなり時間をかけてしまいました。

デプロイ＋αの内容、と述べましたが、私自身にもデプロイの経験がたくさんあるわけではなく、いろいろ学んではドキュメントにして…の繰り返しでした。

WebからDockerのファイルをパクってきてDBを立てていた私ではそのままでは太刀打ちできず。

かなり基礎的な操作や知識から学ばなければいけないことも多く、己の矮小さを再発見する日々でした。

今回の目標は、「いかにアプリケーションのことを考えずに演習ができるか」でした。

基本的には、環境変数にセットアップした技術にまつわる環境変数（MySQLならDSN）を設定するだけで技術が切り替わり、正常に動くようにしたかったのです。

ちょと厳しい。

それぞれの技術を、「切り替える前」も「切り替わった後」も正常に動くように設計するのが結構辛いところでした。

とくに、技術の追加をするときが大変だった…

メソッドはインターフェースで抽象化しているものの、DBの初期化メソッドや情報受け渡し構造体の変更が起こると修正の伝播がものすごくなってしまいました。

「キャッシュ」はDBの設計を終えた後に追加したのですが、SQLiteの実装とMySQLの実装、どちらも素朴なキャッシュが動いている状態で正常に動く必要がありました。

（後から追加した技術があっても、はじめから遊ぶ人に影響があってはいけません）

そもそも通常の2倍実装があるのに、その他の気にしなきゃいけない場所も２倍で…

まあ、多少動かなくても…（ハンズオン中にフロントエンドを動かして遊んでくれる人はそんなにいないかも）

以前、WebRTCをやる前段階としてWebsocketの実装流行ってみて、テストも動いてはいたのですが、実際にフロントエンドと連携して動くアプリを構築するのはこれが初めてでした。

ちゃんと目に見えて動くものができて、素直にとても嬉しいです！

今までずっとVMを腐らせてたのですが、これの駆動テストとしての役割を与えることができました。

わざわざブリッジ接続したりしてたので、もったいないなぁ…とずっと思ってたのですが、ついに日の目を浴びました。

実際に使う人がいることを意識して作ると、動作不良にも敏感になり、結果としていろいろな知識が身についたように思います。

いつかこれを体系的にまとめて記事にしたいなぁ。と画策していたり、いなかったり。

デプロイプラスαのハンズオンを作ってみて、思ったことをまとめてみました。

これからもこのハンズオンの成長は続く…ハズ。

精進します。