はじめに
皆様、こんにちは。『ねむりのガチャ』アプリ開発記の第3回です。
前回は、開発を爆速化するための技術スタック（Cloudflare × Firebase）の選定理由についてお話ししました。今回はいよいよ、実際のプログラミング作業に入っていきます。最初の関門は、どんなWebサービスでも必ず必要になる「ユーザー認証（ログイン）機能」の構築です。
「睡眠ポイント」や「ガチャのアイテム」というユーザー固有のデータを安全に保存するためには、誰が操作しているのかを正確に識別しなければなりません。今回はFirebase Authenticationを活用し、Googleログインを実装するまでの過程と、そこで直面した「思わぬ落とし穴」について解説します。
ユーザーに負担をかけない「Googleログイン」
新しいアプリを使い始めようとしたとき、「メールアドレスとパスワードを入力してアカウントを作成してください」と言われて、そっと画面を閉じた経験はありませんか？
個人開発のアプリにおいて、登録のハードルを下げることは至上命題です。そこで今回は、ユーザーがパスワードを新しく管理する手間を省くため、最初から「Googleアカウントでのログイン（ソーシャルログイン）」をメインに据えることにしました。
Firebase Authenticationを使えば、Googleの強力なインフラを利用して安全にユーザー認証を行うことができます。React側では AuthContext という仕組みを作り、アプリ全体で「現在ログインしているユーザーの情報」を簡単に呼び出せるように設計しました。
リダイレクト方式とポップアップ方式の罠
FirebaseでのGoogleログイン実装には、主に2つの方法が用意されています。
1つは、Googleのログイン画面にページごと遷移（リダイレクト）し、ログイン後に元のアプリに戻ってくる signInWithRedirect。もう1つは、現在の画面の上に小さな別窓を出してログインさせる signInWithPopup です。
当初、私はスマートフォンでの見栄えを考慮し、画面遷移が自然なリダイレクト方式を採用して開発を進めました。しかし、いざスマートフォンの実機（SafariやChrome）でテストをしてみると、奇妙なエラーに悩まされることになります。
ログイン画面からアプリに戻ってきた際、ブラウザの仕様やメモリ制限によってReactのステート（状態）がリセットされてしまい、うまくログイン状態を保持できないケースが頻発したのです。特にiOS環境などでは、リダイレクトによるセッション切れがシビアに判定されることがわかりました。
そこで、実装を signInWithPopup（ポップアップ方式）に切り替えました。これにより、元のアプリ画面（親ウィンドウ）の状態を維持したまま裏側で認証処理が完結するため、スマホ特有の予期せぬエラーがピタリと収まりました。公式ドキュメント通りに進めても、実際の端末（環境）で動かすと思わぬ罠が潜んでいるという、Web開発ならではの教訓を得た瞬間です。
まとめ
今回は、Firebase Authenticationを用いたGoogleログインの実装と、そこで直面したリダイレクトの罠についてお話ししました。
ポップアップ方式に切り替えるというシンプルな解決策でしたが、これによってユーザーがストレスなく「ねむりのガチャ」の世界へ入れる強固な玄関口が完成しました。認証基盤が整えば、次はいよいよ「ユーザーのデータを保存する場所」を作るフェーズです。
次回【第4回】では、Cloudflare D1を使ったエッジデータベースの設計と、ローカル環境での快適な開発体験についてお届けします。
【編集後記】
ログイン機能の実装は、実はエンジニアにとって一番プレッシャーのかかる部分かもしれません。もし自前でパスワードを管理する仕組みを作っていたら、暗号化のアルゴリズムや流出対策など、夜も眠れないほど（睡眠アプリなのに！）心配事が増えていたはずです。
それを数行のコードで、しかも世界最高峰のセキュリティレベルで代行してくれるFirebaseには本当に頭が下がります。少し引っかかったポップアップの挙動も、無事に解決したときの「おおっ、動いた！」という感動はたまりません。玄関の鍵がしっかりかかったので、安心して家の中（データベース）を作り込んでいきます！