More than 1 year has passed since last update.

Supabase Launch Week 8 2日目ローカル開発の新機能について

Supabase

Last updated at 2023-08-11Posted at 2023-08-09

自分は英語のリスニングが壊滅的なので動画と一緒にBlogの投稿をしてくれるようになって嬉しい。
Youtubeのか起こしやAIでの要約などを使っても細かいニュアンスまでは伝わらないので、動画もみますが、Blogの方が主な情報源になっています。

Launch Week 8 2日目 (2023年8月8日)

2日目はローカル開発の話題が中心でした。

ブログでの紹介
Supabase Local Dev: migrations, branching, and observability

動画での紹介
Local Development and Database Branching // a more collaborative Supabase workflow 🚀 - YouTube

00:00 はじめに
00:16 Production Supabase プロジェクトの概要
00:30 ローカル Supabase プロジェクトの作成
01:39 本番環境の構造をローカルデータベースにクローン作成し
02:54 本番環境からローカルデータベースにシードデータをクローン作成します
03:47 データベースの分岐
05:28 何を構築しますか?

Launch Week 8 で発表されたローカル開発新機能の紹介

いろいろと新しい機能の追加が予定されています。

その他

1日目

Hugging Face と Supabaseの連携が紹介されました。

ブログでの紹介
Hugging Face is now supported in Supabase

動画での紹介
Use Hugging Face AI models with Supabase 🤖 - YouTube

Hugging Face とは、自然言語処理（NLP）の分野においてのオープンソースのAIプラットフォームです。
事前学習モデルやデータセットなどを共有し、利用することができます。

Hugging Face は自分の目的とマッチしないのでパス

3日目

Supabase Studio 3.0 の紹介でした。

ブログでの紹介
Supabase Studio 3.0: AI SQL Editor, Schema Diagrams, and new Wrappers

動画での紹介
Supabase Studio 3.0: AI SQL Editor, Schema Diagrams, and new Wrappers

Postgres 言語サーバー (開発中)

このサポートは、Linting、構文のハイライト表示、マイグレーション解析、SQLオートコンプリート、Intellisenseなどが出来るようになります。

2023年8月10日現在、Supabase は言語サーバーを提供していません。
が、フィードバックをしてくれる人を募集しています。

supabase/postgres_lsp · Discussions · GitHub

リポジトリ
supabase/postgres_lsp: A Language Server for Postgres

PostgreSQLの観測ツール

Supabase CLIによるデバッグユーティリティの紹介です。 supabase inspect db コマンドを使用することで、データベースの問題を特定することができます。このインターフェースには、遅いクエリから冗長なインデックスの調査まで、19種類の異なるコマンドが含まれています。

これらのコマンドをPostgresデータベースで使用するには、 -db-url パラメータを追加するだけです。

supabase inspect db --help
Tools to inspect your Supabase database

Usage:
  supabase inspect db [コマンド]

利用可能な19のコマンド:

bloat: デッドタプルでいっぱいのリレーションに割り当てられたスペースを推定します。
blocking: ロックを保持しているクエリと、それらが解放されるのを待っているクエリを表示します。
cache-hit: テーブルとインデックスのキャッシュヒット率を表示します。
calls: pg_stat_statementsから、呼び出された合計回数で並べ替えたクエリを表示します。
index-sizes: 個々のインデックスのインデックスサイズを表示します。
index-usage: インデックスの効率に関する情報を表示します。
locks: リレーションに排他ロックを取得したクエリを表示します。
long-running-queries: 5分以上実行されている現在実行中のクエリを表示します。
outliers: pg_stat_statementsから、実行時間の合計で並べ替えたクエリを表示します。
replication-slots: データベース上のレプリケーションスロットに関する情報を表示します。
role-connections: すべてのデータベースロールのアクティブな接続数を表示します。
seq-scans: すべてのテーブルに対して記録されたシーケンシャルスキャンの数を表示します。
table-index-sizes: 個々のテーブルのインデックスサイズを表示します。
table-record-counts: 各テーブルの推定行数を表示します。
table-sizes: 個々のテーブルのインデックスサイズを除いたテーブルサイズを表示します。
total-index-size: すべてのインデックスの合計サイズを表示します。
total-table-sizes: テーブルインデックスサイズを含む合計テーブルサイズを表示します。
unused-indexes: 使用率の低いインデックスを表示します。
vacuum-stats: 各テーブルごとの VACUUM操作に関連する統計情報を表示します。

デッドタプル
データベースのコンセプトであり、削除された行がまだテーブルに残っている状態を指します。
これは、削除された行がトランザクションによって完全に削除されていない場合に発生することがあります。
デッドタプルが存在すると、データベースのパフォーマンスが低下する可能性があります。

VACUUM操作
PostgreSQLデータベースにおいて、デッドタプルを削除し、データベースのパフォーマンスを向上させるための操作です。
VACUUMは、データベース内のテーブルをスキャンし、削除された行を物理的に削除することで、デッドタプルを削除します。
これにより、データベースのパフォーマンスが向上し、ディスクスペースが解放されます。
VACUUMは、定期的に実行することが推奨されています。また、VACUUMを実行する前に、トランザクションをコミットすることが重要です。

各コマンドのドキュメントへのリンクは

Supabase Local Dev: migrations, branching, and observability

↑この記事の Observability tools for Postgres の項目にあります。

各コマンドのドキュメント(タイトルのみ)

全リンクを貼る気力はなかった・・・全て同じページにあるのでそこから探してください。

Show most frequently run queries

Show long running queries
Show queries ordered by total execution time
Show queries waiting and holding locks
Show queries taking exclusive locks
Show total size of all indexes
Show sizes of individual indexes
Show information about index efficiency
Show indexes with low usage
Show total size of all tables
Show sizes of individual tables
Show index sizes of individual tables
Show cache hit rates for tables and indices
Show estimated number of rows per table
Show number of sequential scans for all tables
Show information about replication slots
Show number of active connections
Show estimated database bloat
Show statistics related to vacuum operations

かんたんバックアップ

supabase db dump を使用することで、データベースのバックアップとマイグレーションがさらに簡単になりました。

ただし、オブジェクトのパーミッションなど、いくつかの問題があります。これらの問題を解決するためにいくつかのフラグを提供していますが、一部は自分で解決する必要があります。

ダンプとは、
データベース内のデータやスキーマをファイルに出力することを指します。ダンプされたファイルは、バックアップやマイグレーションなどの目的で使用されます。ダンプされたファイルを別のデータベースにインポートすることで、元のデータベースと同じ状態を再現することができます。

supabase db dump --help
Dumps data or schemas from the remote database

Usage:
supabase db dump [フラグ]

フラグ:

--data-only: データレコードのみをダンプします。
-f, --file string: ダンプされた内容を保存するファイルのパスを指定します。
--keep-comments: コメント行を pg_dump の出力から保持します。
--role-only: クラスターロールのみをダンプします。
--use-copy: 挿入文の代わりにコピー文を使用します。

マイグレーション機能の改善

CLIマイグレーション機能を拡張し、ダッシュボードのサポートを追加しました。データベースマイグレーションは、バージョン管理された SQL ファイルを使用してデータベースを更新する方法を提供します。私たちは、修復、squashコマンドを使用したマイグレーションのクリーンアップ、新しいマイグレーションを生成したりスキーマのドリフトを検出するための差分（migraを使用）を含む、マイグレーションに関する多くのツールを構築しました。

新しいPostgres Language Serverでは、TypeScript、Go、Python、Rustでアプリケーションを開発するのと同じように、Postgresマイグレーションを簡単に書けるようにしたいと考えています。

最後に、ダッシュボードにマイグレーション履歴を追跡するためのマイグレーションビューを追加し、マイグレーションの発見性を向上させました。

データベースマイグレーションとは、バージョン管理されたSQLファイルを使ってデータベースを更新する方法です。
CLIマイグレーション機能を拡張し、ダッシュボードのサポートを追加しました。
マイグレーションには、修復、squashコマンドを使用したマイグレーションのクリーンアップ、新しいマイグレーションを生成したりスキーマのドリフトを検出するための差分（migraを使用）を含む、多くのツールを構築しました。
新しいPostgres Language Serverを使うことで、Postgresマイグレーションを簡単に書けるようにしたいと考えています。
プロジェクトのダッシュボードにマイグレーション履歴を追跡するためのマイグレーションビューを追加し、マイグレーションの発見性を向上させました。

マイグレーションの発見性とは
データベースマイグレーションの履歴を追跡し、どのマイグレーションが実行されたかを確認することができることを指します。
Supabaseでは、ダッシュボードにマイグレーションビューを追加することで、開発者がマイグレーションの履歴を追跡し、問題を特定することができます。これにより、開発者は、データベースの変更履歴をより簡単に管理することができます。

スキーマのドリフトとは、
データベースのスキーマ（テーブル、カラム、インデックスなど）が、アプリケーションのコードと一致しなくなることを指します。これは、アプリケーションのコードが変更された場合、データベースのスキーマも変更する必要があるため、発生することがあります。スキーマのドリフトが発生すると、アプリケーションが正しく動作しなくなる可能性があります。差分を検出することで、スキーマのドリフトを特定し、必要な修正を行うことができます。

supabase migration --help
Manage database migration scripts

Usage:
  supabase migration [コマンド]

コマンド

list: ローカルとリモートのマイグレーションを一覧表示します。
new: 空のマイグレーションスクリプトを作成します。
repair: マイグレーション履歴テーブルを修復します。
squash: 複数のマイグレーションを1つのファイルにまとめます。
up: 保留中のマイグレーションをローカルデータベースに適用します。

supabase migration repair
Supabase CLI reference - Repair migration history table

supabase migration squash
Supabase CLI reference - Squash migrations to a single file

supabase db diff
Supabase CLI reference - Diff local database

データベースの test と lint

supabase test により、データベースのテストを簡素化しました。
supabase test new を実行すると、 pgTAPテストがスタブとして出力され、テストロジックで埋めることができます。

CLI には pg_prove と TAPハーネスが含まれていますので、supabase test db を実行するだけです。

さらに使いやすくするために、Basejump 社が Supabase テストヘルパー一式を作成してくれており、ユーザーの作成、認証ユーザーとしてのテストの実行、RLS ポリシーのテストなどを簡単に行うことができます。

最後に、優れた plpgsql_check 拡張機能による linting のサポートを追加しました。

pgTAPテスト
pgTAP: Unit Testing for PostgreSQL

pgTAP: pg_prove Documentation

Open source SaaS starter kit for Supabase and NextJS - Basejump

usebasejump/supabase-test-helpers: Test helpers for pgTAP and Supabase

A Guide to testing on Supabase using pgTAP

Testing and linting | Supabase Docs

okbob/plpgsql_check: plpgsql_check is a linter tool (does source code static analyze) for the PostgreSQL language plpgsql (the native language for PostgreSQL store procedures).

supabase test
Run tests on local Supabase containers

Usage:
  supabase test [コマンド]

コマンド

db: pgTAPを使用してローカルデータベースをテストします。
new: 新しいテストファイルを作成します。

supabase db lint
Checks local database for typing error

Usage:
  supabase db lint [フラグ]

フラグ

-h, --help: lintコマンドのヘルプを表示します。
--level [ warning | error ]: 出力するエラーレベルを指定します。デフォルトはwarningです。
--linked: スキーマエラーを検出するために、リンクされたプロジェクトを検査します。
-s, --schema strings: 含めるスキーマのリストを指定します。デフォルトはすべてのスキーマです。

データベースのシード処理

シーディングとは、データベースに初期データを投入するプロセスのことで、一般的にはテストや開発用にサンプルレコードやデフォルトレコードを提供するために使用されます。これにより、チーム全体で再現可能な開発環境を構築できます。

supabase start や supabase db reset を実行するたびに、ローカルデータベースにデータを投入するシーディングのサポートを追加しました。

また、Snapletと協力して、データベースから直接シードデータを生成できるようになりました：

supabase/seed.sql 例

insert into countries
  (name, code)
values
  ('United States', 'US'),
  ('Canada', 'CA'),
  ('Mexico', 'MX');

シードデータの生成

npx snaplet generate --sql > supabase/seed.sql

Seeding your database | Supabase Docs

Snaplet

型生成

SupabaseのTypeScript型ジェネレータは、PostgreSQLのスキーマを読み込んで、TypeScriptの定義を自動的に生成します。これにより、データベースからブラウザまで、エンドツーエンドの型安全性が実現されます。

先月、supabase-js にリレーションシップの検出機能が追加されました。これにより、外部キーが生成される型に含まれるようになり、supabase-jsは外部テーブルが配列（1対多）であるべきかオブジェクト（多対1）であるべきかを検出できるようになりました。また、一般的なシナリオにおいて、開発者の使い勝手を向上させるために、ショートハンドアクセッサのようなヘルパー型が追加されました。

ショートハンドアクセッサのようなヘルパー型とは、よく使用されるデータベース操作に対して、より簡単にアクセスできるようにするための型のことです。例えば、SELECT COUNT(*) FROM tableというSQLクエリを実行する場合、ヘルパー型を使用することで、より簡潔なコードで同じ結果を得ることができます。これにより、開発者はより効率的にコードを記述することができます。

// Before
let movie: Database['public']['Tables']['movies']['Row'] = // ...

// After
let movie: Tables<'movies'> = // ...

supabase gen types
Generate types from Postgres schema

Usage:
  supabase gen types [command]

Available Commands:
  typescript  Generate types for TypeScript

Official GitHub Action

CLIを活用した公式のGitHub Actionを開発しました。PRごとに型を生成したり、コミットごとにテストを実行したりできます。

Supabase CLI Action · Actions · GitHub Marketplace

Generate types using GitHub Actions | Supabase Docs

Automated testing using GitHub Actions | Supabase Docs

Local Logging and Debugging

ログはダッシュボードでローカルにアクセスできるようになりました。先週のローンチウィークに、BigQueryをサポートするオープンソースのロギングサーバをリリースしました。

ここ数ヶ月の間に、このサーバにPostgresのサポートを追加しました。これにより、追加設定なしですべてのローカルログにアクセスできるようになりました - 単に supabase start を実行し、ローカルダッシュボードにアクセスしてデバッグを開始します。

CLI の安定リリース

Supabase CLIを2週間に1度の安定リリースサイクルに移行しました。2週間ごとに、npmの最新タグ、supabase/tap for homebrew、supabase scoop bucketを更新します。バイナリのダウンロードはGitHubの最新リリースにあります。

冒険好きな機能ハンターのために、CLI用のベータリリースチャンネルを追加しました。このガイドに従ってSupabase CLI (beta)をインストールしてください。

scoop update supabase

データベースブランチ機能とプレビュー環境 (アルファ版)

この機能は、今回の目玉と謳っていたが、今後数カ月間はアルファ版となりアルファーテスターのみ利用可能です。(申込可能)

これはGitブランチごとに完全に個別のデータベースを作成することができます。つまり、ローカル開発用、プレビュー用、本番用でそれぞれ個別のデータベースを作成することができます。これにより、開発者は、本番環境に影響を与えることなく、新しい機能を開発、テストすることができます。

上記の機能により、ローカル開発は大きく改善することになるでしょう。
SupabaseによるデータベースのGitという考え方は、開発者がデータベースをGitと同じように扱うことを可能にします。これにより、開発者は、データベースの変更を追跡し、変更をロールバックすることができます。また、開発者は、データベースの変更をローカルでテストし、本番環境にデプロイすることができます。

Supabaseは単なるデータベースではなく、Postgresデータベースから50GBの動画まで、バックエンド全体です。ブランチは、開発者やチームがDevOpsに費やす時間を減らし、構築により多くの時間を費やせるように、環境管理の経験を向上させます。

Supabase ブランチは難しい
すべてのプロジェクトはPostgresデータベースであり、Auth、Storage、Edge Functions、Realtime、Vectorsなどのツール群に包まれ、APIミドルウェアとログに包まれています。

優れたブランチングソリューションは、各ツールがマルチテナンシーサポートを提供する必要があります：

データは、セキュリティのために本番環境から分離できる。
データを本番環境から隔離してセキュリティを確保する。
ブランチはどのように機能するのか？
Gitを使って、ローカルの開発環境とホスティングされたデータベースとの橋渡しをします。今のところ、GitHubに焦点を当てています。

GitHub で新しい Pull Request を開くたびに、対応する "Preview Environment" が作成されます。各プレビューブランチは隔離されたFirecrackerインスタンスで、一定時間操作が行われないと自動的に一時停止します。変更がGitHubにプッシュされるたびに、./supabase/migrationsフォルダ内のマイグレーションがプレビューブランチに対して実行され、チーム全体が同じソースで作業できるようになります。

プルリクエストをマージすると、本番データベースに対してマイグレーションが実行されます。

データについてはどうですか？
シードデータから始めます。./supabase/seed.sqlを持つSQLはすべて、プレビューブランチに入力されます。これにより、チーム全体が隔離された再現可能な環境を提供し、データプライバシーに関する懸念から保護されます。

重要なのは、データセキュリティに適切なものが見つかるまで、本番データをクローンしないということです。コピー・オン・ライトが利用可能なオプションであることは知っていますし、適切な匿名化技術を使えば、「本番のような」テスト環境を提供する有望な方法のように思えます。

また、Supabase Storageの大容量ファイルが何を意味するのかを解明する必要もあります。写真やビデオを匿名化する必要がありますか？これは現在進行中であり、フィードバックをお待ちしています。

いずれにせよ、私たちはシードデータと匿名化されたプロダクションデータの両方をサポートしたいと考えています。シードから始めるのは理にかなっています。

Launch Week 8 3日目 (2023年8月9日)

Supabase Studio 3.0

Supabase Studio 3.0: AI SQL エディター、スキーマ図、新しいラッパー