Neon Authは、認証データをデータベース自体に保存します。ブランチを作成すると、ユーザーアカウント、ロール、セッションなどの認証データも一緒に作成されます。各ブランチには専用の認証エンドポイントが割り当てられ、Vercelとの連携により、適切な認証URLがプレビュー環境に自動的に挿入されます。

摩擦がなくなるまで、自分がどれほど多くの摩擦を受け入れていたかに気づきませんでした。プレビュー環境を開き、実際のユーザーアカウントでログインし、ロールベースのアクセス制御をテストし、管理者フローを検証しました。すべて本番環境に近いデータに対して、完全に隔離された環境で行いました。テストが完了すると、ブランチは削除されます。本番環境には一切手を加えません。

Supabaseでは、プレビュー環境で認証変更をテストするには、手動での設定が必要でした。つまり、個別のプロジェクト、個別の認証設定、あるいは変更が競合する可能性のある共有ステージング環境が必要だったのです。Neonのアプローチでは、認証をデータの一部として扱います。つまり、データと同じように分岐するということです。認証も単なるデータであり、データと同じように分岐するというこの事実に気づくのに、私は必要以上に時間がかかりました。