はじめに
Next.js + Supabase を使用して作った .env を GitHubリポジトリに紐づけて共有・保存出来るWebアプリ であるEnvHubをアップデートしました。
こちらが デプロイしたアプリケーション になります。
こちらが EnvHubのGitHubリポジトリ になります。
技術スタック
主に以下の技術スタックを使用しています。
- Next.js(App Router)
- Supabase
工夫したところ
-
React Server Components
を活用して無駄なハイドレーションを抑えた点 -
SSG
できる部分はSSG
して静的にビルドされた部分を描画している点 -
SSR
される部分が導線の大元になることからローディングアニメーションを追加した点 -
Supabase(BaaS)
へのアクセスをフロントエンドからではなくバックエンドからのアクセスにした点
苦労したところ
-
基本的にはフロントエンドからのアクセスされる事が想定されている
Supabase
へのアクセスをバックエンド経由にしたことで、認証処理を公式ドキュメント通りに進めても上手く行かなかったことに苦労しました。
結果的にOAuth
の認可コードフローを見ながら、自分がどこで詰まっているのかを把握して、対応しました。 -
トップ画面に表示している画像スライダーがTypeScriptに対応していなかったため、コード補完されず苦労しました。
結果的に、ライブラリのGitHubリポジトリのIssueから同じ問題を抱えているユーザがフォークして作成したライブラリを使って対応しました。
アップデート内容
- organizationのリポジトリも共有対象として選択できるようになりました!
- 添付画像の組織タブをクリックするとorganizationのリポジトリが選択出来ます。
- 1度のアップロードにつき1回、コミットを生成出来るようになりました!
- アップロードを確定するを押下時にコミットメッセージを入力出来ます。
- コミット単位で過去アップロードしたファイルを遡って取得出来るようになりました!
- コミット履歴からコミットを一つをクリックすると、コミットに紐づいているアップロードしたファイル群が描画されます。
- ファイル単体での保存、コミットに紐づいたファイル全体の保存どちらも可能です!
- デザインを一新しました!
- 以下に画面のBefore Afterを載せておきます。
- モーダル内の描画等の細かい物は載せていないので、ぜひ一度触ってみてください!
トップ画面
- Before
- After
ログイン画面
- Before
- After
ファイルアップロード画面
- Before
- After
ファイルダウンロード画面
- Before
- After
V2アップデートに伴い新しくやってみたこと
-
GitHub Actionsを使った
CI
の導入
PRタイトルがConventional Commits
に沿っているか判定するactions
とjest
のテストを実行するactions
を組みました。
Conventional Commits
に沿っているかを判定するactions
は概ね満足なんですが、Danger JS
を起動するためにdocker
コンテナを建てていて、それに時間が掛かってしまっているのでdocker
コンテナを建てずに実行して時間短縮したいと思っています。
jest
のテストを実行するactions
は大満足です。
ただ、テストはあまり書けていないので時間のある時に書きたいです。
CI
を全く知らない状態からactions
を組んでみたのですが、ちゃんとやるとかなり開発効率が上がりそうでもっと詳細に学習したいと思いました。
-
Issueを使ってタスクを管理する
Issue
を使ってタスクをチケットにして管理し、PR内部でcloseすることでGitHubのみでチケット管理を行っていました。
チケット起票・進捗の見える化がGitHub
のみで行えてかなり良かったです!
個人開発で行うと自己満感が強かったので、今度はチーム開発で使いたいです。
こんな感じでチケット管理が出来ます。
チケット起票画面はこんな感じです。
V3でやりたいこと
-
コマンドラインでのenvファイルの取得・アップロード
env pull
env push
のようなコマンドでenvファイルの取得・アップロードを行えるようにしたいです。 -
BEの分離・リファクタリング
現在BE
部分をNext.js
のRoute Handlers
とServer Actions
の併用で実装しています。
この部分をNestJS
かHono
のどちらかに分離して実装したいと思っています。
NestJS
はデフォルトでコントローラとサービス層が分かれていて、リポジトリパターンの概念を持ち込むことでそのまま実装出来そうだという理由とDTO
とclass-validator
の使いやすさが選定理由です。
Hono
はCloudflare Workers
にそのままデプロイ出来て格安で運用出来そうだという選定理由です。
リファクタリング
については処理自体を関数に分けているものの、全てをコントローラから呼んでいる状態でかなり読みづらくなってしまっています。
BE
の分離によりリポジトリパターンに則った実装にし、読みやすく出来れば良いなと思っています。 -
Supabaseからの脱却
現在はSupabase
というBaaS
に強く依存したアプリになっており、
具体的にはDB・Auth・オブジェクトストレージの機能を使用しています。
これらを全てCloudflare D1・Auth.js・Cloudflare R2に乗せ換えたいと思っています。
主にコストが要因です。(R2エグレス料金無料だし無料枠もかなり多いです。)
さいごに
こちらが V1デプロイ時に書いた紹介記事 です。