【prel】1からWebアプリ(OSS)を作ってみた振り返り

作ったもの

Google Cloud の IAM role を期間限定でユーザに付与するためのワークフローアプリ。

技術スタック

Backend / Front: Go (template)
プロトコル：HTTP + OpenAPI v3(ogen)
DB: Posgresql

他にも新しく使ったものをすべてかく

tagpr / Playwright / HoberFly / sqlc / postgres / cockroachdb/errors / cobra & viper / oauth2 / iap(header) / CloudSQL / CloudSQL Connector / pgx / dockertest / chatgpt による画像生成

学び

Go template ですべてのページ生成をまかなう

最小限にしたかったのでレンダリングも Go でやった。

最初は良かったがだんだん動的なページをつくりたくなって MPA から CSR をやるページがちらほらでてきた。 Go の template で書くと copilot もうまく効かないし、フォーマッタや Linter も動かなくて相当やりづらかった。（ほぼ ChatGPT に作ってもらった）

やりたいこと完全に別だわということを思い、「だからフロントエンドって独立させたのか」 とここで気づいた。

次やるならフロントエンド作る・・・？とおもったけど個人開発で分けるのはめんどくさいなあ・・・。逆にフロントエンドにバックエンドを寄せる方が可能性があるのだろうか？

1から openapi schema を書くということ

1から書いた経験がなかったのでよかった。

すべてのエンドポイント(HTMLページ / API )について記載をしていたのだが、途中で API エンドポイントだけでいいんじゃないかと気づく。そして気づいた時にはすでに遅し。

静的ページも返すようにしてしまったので /request が静的ページ、/api/requests がAPIというややこしい感じになってしまったし、静的ページのレスポンスとして 404 ページの text/html を返したりしてしまったので application/json だけを返す思想からはずれてしまった。

次は openapi では定義しないようにします・・・。

ogen が便利

blog.framinal.life

コードの書き方

普段の癖で DBスキーマから書いて行ったのだがその後フロント側の修正に合わせてどんどん変わっていった。

実際の使われ方次第でドメイン設計が変わることに気づいたので、次からは 先に使われ方を設計してから画面を考えてやり取りするデータを決め、じゃあそれをどう管理する かという流れにしたい。

インフラ（主にDB）の再設計

Cloud Run + SQlite で行こうと考えて途中まで実装していたのだが、Cloud Run から参照する SQlite 置き場は以下の選択肢があるがいろんな理由で全部無理となった。

sqlite on GCSFUSE: バックエンドとしての利用が公式として非推奨、複数の書き込みがあると最後のが勝つ
sqlite with Litestream: データが欠損の恐れあり。ユースケース的に微妙では
sqlite on Filestore: 最低1TBからでとても高い

全部無理となった後に Postgresql (Cloud SQL) に置き換えたので1日かかってしまった。とはいえクリーンアーキテクチャと sqlc でだいぶ抽象化していたのでめちゃくちゃ大変ではなかった。

次はもっとDB選定を気をつけよう。

sqlc

クエリからコードを生成できるツール。便利便利と聞いていたが思ったより便利。たまにDBごとの独自の書き方をしないと動かないケースもあるが、大体そういうのは issue にあがってたりするので見れば解決する。

途中から E2E テストのために TypeScript を導入しそこから DB を参照したかったので sqlc with TypeScript を使ったが、これも簡単に使えてとても良かった。

セッションに JWT を使わない

セッション維持のために最初は JWT を使っていた。

DB管理しなくていい
expired を JWT だけで実装できる

しかし、jwt key がわかると簡単にセッションが生成できセキュリティリスクがあることに気づき実装を丸ごと入れ替えた。"セッション jwt" で調べると警鐘を鳴らす記事がたくさん出てくるので見ると良い。

Google OAuth2 に初挑戦 / IAP

やったことないからくる、OAuth2 に苦手意識があったが今回初挑戦。Client ID / Client Secret を発行しあとはコールバックエンドポイントを用意すれば、idtoken が発行されてはいおしまいだけの簡単なものだった。

これをきっかけに idtoken のことを少しわかったり、Identity-Aware Proxy のこともひきづられて理解度が上昇したのでとてもよかった。

E2E テストの大変さと安心感

バックエンドのみなら API を複数組み合わせたテストで安心できるのだが、ブラウザ操作については全く安心できないということで初めて Playwright 入れてみた。

最初はどう書くかよくわからなかったけど相当楽（まだしっかりかけないけど）

テストもグラフィカルで見ていて楽しい。また変更してもテストがあるのでとても安心感があってよい。ただし Flaky なテストも生まれやすいので取り扱いには注意。

hoverfly による外部通信のエミュレート

Google API の呼び出しができないのでこれでシュミレートした。

使い方は単純で外部通信を読み取った後 json に dump してそれを使い回すだけ。Google からのレスポンスは gzip + base64 encode されていてめんどくさかったけどまあなんとかなった。いいツールなのに日本語情報少ないのはなんでだろ？

ただリクエストに差がないけど明示的に違うレスポンスを返したいケースはどうにもできなかったので、それだけが心残り。

dockertest

DBテストの際につかった。テストのたびにコンテナを生成して消すというもの。

ただちょっと変えて、テスト時にコンテナ起動→以後のテストはDBをつくるだけ→全てのテストが終わったらコンテナ削除　という感じにした。こっちの方がコンテナ起動停止で遅くなることもない。

tagpr

タグのアップデートとか考えなくていいのがとても楽。

`cockroachdb/errors`

エラーページ出しわけのためにカスタムエラーを使いたかったのとスタックトレースだしたかったので採用。本来の使い方としてあってるかは甚だ怪しいが WithDetail でカスタムエラーをくっつけて、あとで Detail の有無をチェックしてHTTPステータスコードにマッピングさせるという処理をした。

手軽にできて使用感もよく便利だったのでこれでいいんじゃないかと思う。