はじめに
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 pullenv 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デプロイ時に書いた紹介記事 です。











