はじめに
皆様、こんにちは。『ねむりのガチャ』アプリ開発記の第4回です。
前回はFirebaseを使って、安全かつスムーズなGoogleログイン機能（玄関口）を完成させました。次に取り組むのは、ログインしたユーザーの情報を保管する「倉庫」の準備、つまりデータベースの設計と構築です。
せっかく寝てポイントを貯めても、画面を閉じた瞬間にデータが消えてしまっては意味がありません。今回は、エッジ環境で爆速に動作するCloudflareのデータベース「D1」をどのように活用し、データを設計したのかを詳しく解説します。
Cloudflare D1の魅力とは？
今回データベースに採用した「Cloudflare D1」は、世界中に分散されたサーバー（エッジネットワーク）上で動作する「SQLite」ベースのデータベースです。
従来の一般的なデータベース（MySQLなど）は、特定の国や地域のサーバーにデータが置かれるため、遠くからアクセスするとどうしても通信の遅延（ラグ）が発生しました。しかしD1なら、ユーザーに最も近い場所にあるサーバーが自動的にデータを処理してくれるため、圧倒的なスピードで読み書きが可能です。
さらに、個人開発者にとって最大のメリットは「インフラの設定作業がほぼゼロ」であること。難しいサーバー構築の知識がなくても、コマンドをいくつか叩くだけで一瞬にして本番用のデータベースが誕生します。
MVPのための超シンプル設計
今回のアプリは「MVP（最小限の実行可能な製品）」としてスモールスタートするため、データベースの設計（スキーマ）も極限までシンプルに保つことを意識しました。
作成したテーブルは users（ユーザーテーブル）ただ1つです。
id: ユーザーを一意に識別するID（Firebaseのログイン情報と紐づけるためのPrimary Key）
points: 睡眠によって獲得した現在の所持ポイント（数値）
ownedItemIds: これまでにガチャで引き当てたアイテムIDのリスト（JSON形式などの文字列）
通常であれば、「ユーザーの基本情報テーブル」と「所持アイテムのテーブル」を分けてリレーション（紐付け）を張るのがリレーショナルデータベースの定石です。しかし今回は、ユーザーの総数もアイテムの種類も限定的であるため、あえて1つの行（レコード）にすべてのデータを集約する方針をとりました。これにより、データを読み書きする際の処理が劇的に軽くなり、開発スピードの向上にもつながりました。
wranglerコマンドがもたらす極上の開発体験
D1を使っていて最も感動したのが、ローカル（自分のパソコン）でのテストの快適さです。
通常、データベースをパソコン上で動かすには専用のソフトをインストールしたり、Docker等の仮想環境を立ち上げたりと手間がかかります。しかし、Cloudflareが提供する wrangler（ラングラー）という開発ツールを使えば、コマンドラインから直感的にデータベースを操作できます。
例えば、開発中に「ちゃんとポイントが追加されているか？」を確認したいときは、ターミナルで npx wrangler d1 execute sleep-app-db –local –command "SELECT * FROM users" と打ち込むだけで、瞬時に手元のデータの中身を確認できます。本番環境とローカル環境を完全に分離したまま、安全かつスピーディーにトライ＆エラーを繰り返せるこの体験は、一度味わうと元には戻れません。
まとめ
今回は、Cloudflare D1を用いたデータベースの設計と、開発を加速させるツールの活用についてお話ししました。
「シンプルに保つこと」を最優先に設計したデータベースは、軽量で高速に動作し、今後のガチャシステムの土台として完璧に機能してくれます。バックエンドのインフラがすべて整ったところで、次はいよいよユーザーの目に触れる画面側を作っていくフェーズです。
次回【第5回】では、ReactとTailwind CSSを駆使して構築した、直感的な「寝る・起きる」ボタンのフロントエンド実装について詳しくお届けします。
【編集後記】
SQL（データベース言語）を書くのは久しぶりだったのですが、wrangler ツールのおかげで本当にサクサクと開発が進みました。
「テーブルを一つにまとめる」という決断は、熟練のエンジニアから見れば邪道と思われるかもしれません。しかし、個人開発において最も恐ろしいのは「設計を複雑にしすぎて完成しないこと」です。まずは動くものを世に出し、必要になったらその時にデータベースを分割（マイグレーション）すればいい。この割り切りこそが、MVP開発における最大の秘訣だと改めて実感したフェーズでした。次回からはついに画面が動き出します！