👋
Supabaseのローカル開発環境でGraphQLを動かしてみるぞ
はじめに
Supabaseをローカル開発環境で構築し、GraphqQLのクエリを叩いてみるところまでやってみた記事です。
Supabaseはローカル開発環境構築のためのCLIが提供されており、コマンドを何回か叩くだけで環境を用意できます。docker-composeの設定なども必要ありません。
GraphQLのサポートはPostgreSQLの拡張機能を有効にして、スキーマを再構築するだけで利用できるようです。
基本的に ドキュメントの Local Development の章をなぞっているだけですが、Supabaseをローカル環境で動かしたい、手元にGraphQLが動かせる環境を用意したい人の参考になれば嬉しいです。
- GraphQL が Supabase で利用可能になりました
環境構築
- Supabase CLIのインストール
$ brew install supabase/tap/supabase
- 以下のコマンドを実行する
# プロジェクトのディレクトリ作成
$ mkdir my-supabase-project
$ cd my-supabase-project
$ git init
# プロジェクト初期化
$ supabase init
# 起動
$ supabase start
`supabase start` 実行結果
-
supabase start
実行後、API URLやkeyの情報などを取得できる
$ supabase start
Started supabase local development setup.
API URL: http://localhost:54321
DB URL: postgresql://postgres:postgres@localhost:54322/postgres
Studio URL: http://localhost:54323
Inbucket URL: http://localhost:54324
anon key: <your anon key>
service_role key: <your service_role key>
- 起動後、http://localhost:54323 にアクセスすると、Studioの画面が表示されました。本番環境と同様のGUI操作をローカルでできるのは便利。
サンプルのデータ追加
動かしてみるためのサンプルデータを追加します。Studioの画面からGUIの操作で追加します。
デフォルトのプロジェクトにアクセスする
SQLエディタにアクセスして、サンプルデータ用の `employees` テーブル作成用のSQLを実行する
- SQLエディタの画面に以下のSQLを入力して実行する
create table employees (
id integer primary key generated always as identity,
name text
);
テーブルエディタから `employees` が作成されてることを確認できる
-
employees
テーブルが作成されてる
- テーブルを追加したら、以下のコマンドを実行して、マイグレーションファイルを生成する。(
supabase/migrations/<timestamp>_create_employees.sql
が生成される)
$ supabase db commit create_employees
- サンプルデータ追加するためにシーダーを作成する。
supabase/seed.sql
を新しく作って以下のSQLを追加する。
insert into public.employees (name)
values
('Erlich Backman'),
('Richard Hendricks'),
('Monica Hall');
- 以下のコマンドで、マイグレーションとシーダーのスクリプトを再実行させて、シーダーのデータを反映させる
$ supabase db reset
実行結果
- テーブルにデータが追加されてること
GraphQLのエンドポイントを叩いてみる
テスト用に作った employees
のデータをGraphQLのクエリでアクセスできるか試してみます。
-
employees
テーブルを追加して SQL schemaを変更したので、SQLエディタから以下のSQLを実行して、スキーマを再構築するselect graphql.rebuild_schema();
- Apollo Studioの sandbox からQueryをを叩いてみる
sandbox からQueryをを叩いてみるための設定
- ローカルのsupabaseにアクセスできるように、sandboxに設定を追加する
- 必要な項目(エンドポイントとキー)を入力して保存する
- supabaseのAPI URLとanon keyキーを確認したい場合は、以下のコマンドで確認できる
$ supabase status
supabase local development setup is running.
API URL: http://localhost:54321
DB URL: postgresql://postgres:postgres@localhost:54322/postgres
Studio URL: http://localhost:54323
Inbucket URL: http://localhost:54324
anon key: <your anon key>
service_role key: <your service_role key>
- キーについて。次の 2 つのキーが提供されている
- anon key ブラウザのコンテキストで安全に使用できるキー。
- service_role key サーバーでのみ使用する必要があるキー。このキーは行レベル セキュリティをバイパスできます。ブラウザでこのキーを使用しないでください。
- https://supabase.com/docs/guides/api#api-keys
- 以下のQueryを叩いてみる
query Query {
employeesCollection {
edges {
node {
id
name
}
}
}
}
- 取得できた!!!
- ついでにMutationも叩いてみる
# Operation
mutation Mutation($objects: [employeesInsertInput!]!) {
insertIntoemployeesCollection(objects: $objects) {
records {
id
name
}
}
}
# Variables
{
"objects": [
{
"name": "太郎"
}
]
}
- 追加できた!!!
ローカル環境をリモート環境に反映させる
- DBの変更など、ローカル環境で変更したい内容をapp.supabase.com上のプロジェクトに反映させることができます。
# ローカル環境とリモートプロジェクトを紐付ける
$ supabase link --project-ref <your-project-ref>
# リモートのDBをセットする
$ supabase db remote set 'postgresql://postgres:<your_password>@db.<your_project_ref>.supabase.co:5432/postgres'
# StudioでGUIの操作からSQLを実行してスキーマに変更かけた後に以下のコマンドを実行しマイグレーションファイルを生成する
$ supabase db commit create_hoges
# ローカルのDBの変更をリモートに反映させる
$ supabase db push
試してみた
- ローカル環境で適当なテーブルを作ってみる
create table foods (
id integer primary key generated always as identity,
name text,
value text
);
- スキーマの変更をマイグレーションファイルを作成する
$ supabase db commit create_foods
Finished supabase db commit on branch main.
WARNING: The diff tool is not foolproof, so you may need to manually rearrange and modify the generated migration.
Run supabase db reset to verify that the new migration does not generate errors.
- マイグレーションファイルが生成された
- リモートプロジェクトに反映させる
$ supabase db push
Applying unapplied migrations...
Finished supabase db push.
- リモート環境にもスキーマの変更が反映された
おわりに
- 以前ローカル環境でSupabaseを動かした時は、CLIでローカル環境を作る機能がまだなかったので、docker-composeの設定を色々と試しながら動かしていたのですが、今回試してみて、コマンド数回叩くだけでローカル環境が作れるのは感動しました。
- GraphQLを使う際に、スキーマを再構築するSQLを叩かないとGraphQL使えないことに気がつかず少しハマりましたが、ほとんど何もしなくてもGraphQLの機能が使えて便利で良かった。
- 本筋と関係ないですが、apollo studio 補完がめっちゃ効いて、クエリ描きやすくてかなり便利でした。
- スキーマの変更を生のSQLで管理するの大変そうなので、Prismaと組み合わせて使った方が良さそうかなと思ったりしたので、組み合わせた構成も試してみたいと思いました。
参考
GitHubで編集を提案
Discussion