コンテンツにスキップ

ローカル開発環境の作り方

この章でわかること: 動くプロトタイプにデータ保存を足すと、必ず出てくるのが 「手元(ローカル)で開発するとき、データベースをどうするか」という問題。 ここは選択肢が多く迷いやすいところなので、デプロイ先に合わせて決めるという 筋の良い考え方を、代表的な2構成で整理します。

デプロイ先の構成ローカルのDB理由
Vercel + Postgres 系PGlite(埋め込みPostgres)Docker不要で起動が速い。本番の Postgres と方言が揃う
Cloudflare Workers + D1 系SQLiteD1 は SQLite 互換なので、ローカルも同じ SQLite にすれば差が出ない

そして、どちらを選んでも Drizzle で DB アクセスを 抽象化しておくと、ローカルと本番の違いをコードからほぼ隠せます。以下、順に説明します。

なぜ「ローカルのDB」で悩むのか

Section titled “なぜ「ローカルのDB」で悩むのか”

本番のアプリはクラウド上のデータベースにつながります。では手元で開発するとき、 そのデータベースをどう用意するか。素朴には2案ありますが、どちらも難があります。

  • 案A:本番のDBにローカルから直接つなぐ → 開発中の実験でうっかり本番データを壊す危険がある。ネットワーク越しで遅い。 そもそも推奨されません。
  • 案B:エミュレータ(本番相当のDB)をローカルで動かす → 多くの場合 Docker が必要になり、非エンジニアには導入のハードルが高い。 マシンも重くなりがち。

構成1:Vercel + Postgres なら「PGlite」

Section titled “構成1:Vercel + Postgres なら「PGlite」”

Vercel でよく使う Postgres(Neon や Vercel Postgres など)。この場合、ローカルには PGlite がおすすめです。PGlite は Postgres を丸ごとプログラムの中に埋め込んだ もので、Docker もサーバー起動もいりません。ファイル1つ(またはメモリ上)に データを持つので、起動が一瞬です。

  • Docker 不要。npm install した瞬間から使える
  • 本番が Postgres なので、SQLの方言(書き方)が本番と揃う
  • テストのたびにまっさらな状態から始めやすい

構成2:Cloudflare Workers + D1 なら「SQLite」

Section titled “構成2:Cloudflare Workers + D1 なら「SQLite」”

Cloudflare Workers でデータを持つなら D1 という選択肢があります。D1 は中身が SQLite 互換。なので、ローカルも素直に SQLite を使えば、本番との差がほぼ出ません。 Cloudflare の開発ツール(wrangler)は、ローカル実行時に手元の SQLite を自動で 用意してくれます。

  • 本番(D1)もローカル(SQLite)も同じ SQLite 方言。学ぶことが1つで済む
  • こちらも Docker 不要
  • このチュートリアルサイト自身も Cloudflare Workers で動いています

仕上げ:Drizzle でアクセスを抽象化する

Section titled “仕上げ:Drizzle でアクセスを抽象化する”

ここまでで「ローカルは PGlite か SQLite」と決まりました。最後の鍵が Drizzle という ORM(データベースアクセスを肩代わりしてくれる道具)です。

Drizzle を挟むと、データの読み書きを 同じ書き方で書けます。つなぐ先が ローカルの PGlite でも、本番の Postgres でも、あるいは SQLite / D1 でも、 アプリ側のコードはほとんど変えなくていい——この「差を吸収してくれる層」が あるおかげで、ローカルと本番を安心して行き来できます。

「動いた!」の次に必ず来るのが「手元で安全に育てるにはどうする?」です。 本番に直接つながない・Docker を避ける・本番と方言を揃える——この3点を、 デプロイ先に合わせて PGlite / SQLite で満たし、Drizzle で差を吸収する。 この型を知っておくと、プロトタイプを壊さずに機能を足していけます。