Next.js + Auth.js + Docker でTo-Doアプリを作った話

はじめに

Next.js アプリケーション開発の勉強をしています。
Auth.js (v5) によるGithub OAuth認証と、Drizzle ORMによるMySQLデータベース処理を行います。

データ取得はNext.jsサーバからHTMLを返す際に一緒に行うため、 SWR や tRPC といったクライアントサイドでのデータ取得用のライブラリを使用しません。

この記事は Next.js で何かWebアプリケーションを作りたいなーという人向けに、技術スタック（どんなフレームワーク、ライブラリを組み合わせているか）の一例を示すような内容になっているのではと思います。

App Router + Server Action 等、Next.js が推している新しい技術を利用し、こんな感じになっています。

https://faveo-systema.net/sekirei-todo

皆さんの個人情報を私の管理しているDBに入れるのがちょっと怖いので、ログインできるのは私だけになっている...つもりです。

Githubリポジトリはこちら。

https://github.com/daiius/sekirei-todo

認証部分

Next.jsはRC版（v15.0.0-rc.0）、Auth.jsはベータ版（5.0.0-beta.20）を使用しています。

詳しい解説は公式ドキュメントや他の記事にお願いして、大雑把な全体のコードを示します。

src/auth.ts

Auth.jsの初期化・設定や一部の処理内容を記述します。
https://github.com/Daiius/sekirei-todo/blob/main/src/auth.ts

今回はGithubのOAuth機能を使用しています。どんなデータが返ってくるかはOAuthプロバイダ次第です。Twitterを利用する際にはこんな感じで別の設定が必要になります。

Auth.jsのデバッグ機能を開発中はOnにしておくと、OAuthプロバイダが返してくるデータ内容が表示されるので、それに合わせて処理を記述しました。

auth.ts

(前略)
export const { handlers, auth, signIn, signOut } = NextAuth({
  // docker環境ではtrustHost: trueが必要らしいです
  trustHost: true,
  providers: [GitHub],
  debug: true, // <------ これ
(後略)

本番環境ではnginxリバースプロキシ下に置くことを想定しており、開発環境もそれに合わせています。
ログイン状態に合わせたリダイレクト先を相対パスにするか、絶対パスにするか、かなり慎重に検討・試験しました。

src/middleware.ts

Next.jsのmiddleware機能の設定をします。
https://github.com/Daiius/sekirei-todo/blob/main/src/middleware.ts

今回は/tasksと/の2つのパスにだけ、認証有無のチェックを設定しています。

繰り返しになりますが、nginxリバースプロキシ下に置くため、
これも相対パスにするか、絶対パスにするか、かなり慎重に検討・試験しました。

src/actions/authenticate.ts

ログインボタンが押された際の処理、より正確にはformDataを受け取ってAuth.jsに処理を委譲する部分です。
https://github.com/Daiius/sekirei-todo/blob/main/src/actions/authenticate.ts

データベース部分

Drizzle ORM によるデータベース管理を行っています。Prismaといった大御所はありますが、TypeScriptのみでスキーマ定義やマイグレーションが完結する部分に魅力を感じ採用しています。

src/db/schema.ts

テーブル2つから成ります...が、2つ目のtasksテーブルしか使っていません。
https://github.com/Daiius/sekirei-todo/blob/main/src/db/schema.ts

src/db/index.ts

データベースとの接続関連の設定が入ります。
https://github.com/Daiius/sekirei-todo/blob/main/src/db/index.ts

Auth.jsやNext.jsのチュートリアルでは、Next.jsのcanaryバージョンを使用するようなものがあります。Next.jsのcanaryバージョン+mysql.poolConnection({...})の組み合わせは、next build && next start時（本番環境時）に変なエラーを出して止まりがちなのでお勧めできません。

もう一つ、await mysql.createConnection({...})という接続方法はNext.jsバージョンによらず安定して見えるものの、本番環境で長時間稼働すると何かの拍子に切断された際に復帰しないのでこれもお勧めできません。

src/actions/tasksActions.ts

タスク関連のサーバ側で行う処理をServer Actionとして定義しています。
https://github.com/Daiius/sekirei-todo/blob/main/src/actions/tasksActions.ts

基本的にuserIdとtaskIdの組でもってどのタスクかを特定し、それに対して処理を行います。ただ、userIdは必ずAuth.jsから取得できるセッション情報から取得し、ユーザのブラウザからは取得しません。

これはServer Actionで受け取る引数が不正である（もっと言えば攻撃の対象になる）可能性もあるためで、サーバ側だから安心！という訳にはいかないかなという感覚です。

Dockerを使った開発環境

Next.js + MySQL 環境を Docker (Docker Compose) で管理します。
https://github.com/Daiius/sekirei-todo/blob/main/docker-compose.yml
上記docker-compose.ymlファイルのdatabase-preparationサービスでは、Drizzle ORM（正確にはデータベース管理用のdrizzle-kitパッケージ）を使って開発環境に対して適切なテーブル生成とテスト用データを追加します。

Dockerを使ったDistroless本番環境

Next.jsアプリケーションを本番環境に配置する際にもDockerを使います。こちらの記事を参考にしています。
https://zenn.dev/kazumax4395/articles/427cc791f6145b

https://github.com/Daiius/sekirei-todo/blob/main/Dockerfile.nextjs.prod

この様なスクリプトで本番用コンテナをビルドします。
https://github.com/Daiius/sekirei-todo/blob/main/docker-build-production.sh

ポートフォワード関連のことが書いてあるのは...

本番環境用コンテナをビルドする際には、本番環境DBに接続できるようにメッセージを出しています。
直接外部からアクセスできない用にしているので、SSHポートフォワードを行ってから実行するようにしています。

（後発のプロジェクト用の設定で、このアプリケーションでは不要な設定です）

おわりに

素の React で SPA を作っていた時と比べ、Next.js は本当に出来ることが多く、難しく感じます。
でも逆に Next.js の範囲内で出来ることが把握できるほど、頼もしい存在にも思えます。

ベストプラクティスが何か中々分からない状況になった際には、公式ドキュメントに戻って考えるようにしています。

To-Doアプリという性格上、ほとんどのページが Dynamic Rendering になりましたが、次は静的なコンテンツを扱う際に Static Rendering も積極的に取り入れるものにしてみたいです（Static & Dynamic Rendering については こちら）。