Prisma — データベースORM — を開発するNikolas Burk氏は先頃、Prismaのすべてのツール(Prisma Client、Prisma Studio、Prisma Migrate)が実運用環境で使用可能になったと発表した。Prisma Migrateは今年になってプレビューを完了していたが、今回から一般提供されるようになる。
Prismaツールスイート開発の背景について、Burk氏は次のように要約している。
Prismaを開発する中で、Node.jsのエコシステムが — データベースを使用するアプリケーション開発において、ますます人気を集めているにも関わらず — これらのタスク[データモデリング、スキーマのマイグレーション、データベースクエリの記述]をアプリケーション開発者が行うための最新ツールを提供していない、ということが分かったのです。
アプリケーション開発者が対応すべきなのはデータであって、SQLではありません。
ツールをより専門化することで、アプリケーション開発者は、グルーコードを書いてアプリケーションの各層を取りまとめるのに時間を費やすのではなく、自らの組織にとって付加価値となる機能の実装に集中できるようになるはずです。
リモートデータ管理に関するさまざまな要望に応じるべく、Prismaは3つのツールを提案している。Prisma Clientは、基盤となるデータベース上でCRUD(create、read、update、delete)オペレーションを実行するための、タイプセーフなクエリを自動生成するクエリビルダである。Prisma Studioは、データベースコンテンツの視覚的な検索や操作が可能な、ユーザインタフェースアプリケーションである。
そして、新たに一般提供が開始されたPrisma Migrateは、データベーススキーマの修正と、それに伴うアプリケーションのクエリの修正という、反復的な開発プロセスを合理化しようというものだ。Prismaのデベロッパアドボケートを務めるDaniel Normal氏は、Prisma Migrateの目標を次のように述べている。
現在、データ駆動アプリケーションの要件は絶えず変化しています。リレーショナルデータベースの使用においては、継続的に進化するスキーマの管理がひとつの課題になります。
Prisma Migrateは、データベーススキーマのマイグレーションツールとして、データベーススキーマとアプリケーションの協調的な更新作業を簡略化します。[...] Prisma Migrateは、データベースマイグレーション記述時の反復的でエラーを起こしやすい部分を自動化しながらも、最終的な実行方法の決定を自分自身で行うことによって、生産性とコントロールのバランスを保ちます。
Prisma Migrateは、データベースエンティティやエンティティ間の関係性を表現することが可能な、データベーススキーマDSLを備えている。
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
model User {
id Int @id @default(autoincrement())
email String @unique
name String?
birthdate DateTime @db.Date
activated Boolean @default(false)
}
このスキーマDSLは、次のようなSQLマイグレーションスクリプトに変換される。
-- The SQL can be edited prior to execution
-- CreateTable
CREATE TABLE "User" (
"id" SERIAL NOT NULL,
"email" TEXT NOT NULL,
"name" TEXT,
"birthdate" DATE NOT NULL,
"activated" BOOLEAN NOT NULL DEFAULT false,
PRIMARY KEY ("id")
);
-- CreateIndex
CREATE UNIQUE INDEX "User.email_unique" ON "User"("email");
データベーススキーマの進化に伴って、Prisma Migrateは、.sqlマイグレーションファイルの履歴情報を専用のフォルダに生成する。
migrations/
└─ 20210313140442_init/
└─ migration.sql
└─ 20210313140442_added_job_title/
└─ migration.sql
Prisma Migrateは一般的なスキーマ変更(フィールド追加など)をカバーしているが、マイグレーションスクリプトをカスタマイズしてデータベースベンダ特有のコードを追加したり、処理対象ではないユースケースを提供する必要があるかも知れない。Prime Migrateのドキュメントには、フィールドの名称変更や型の変更、1対1リレーションシップの方向の変更など、いくつかの例が紹介されている。
Reddit上で開発者たちが強調しているのは、データベースとアプリケーションの間に位置するORM抽象化の便利さは認めるが、現実的にはSQLや基盤となるデータベース特有の知識が — 特にクエリの最適化やパフォーマンスに関連して — 必要であることに変わりはない、という点だ。これを理由に、抽象化は完全にバイパスすべきだ、と主張する開発者もいる。これに対してBurk氏は、ORMの抽象化がリークするケースはPrismaの付加価値を大きく低減させるほど頻繁ではない、と反論している。
SQLは複雑で、自分の足を撃ち抜くようなことが少なくありませんし、そのデータモデル(リレーショナルデータ/テーブル)は、JS/TSで作業する場合に開発者が扱うもの(ネストしたデータやオブジェクト)とはかけ離れています。リレーショナルデータをオブジェクトにマッピングする作業には、精神的にも実務的にもコストが伴うのです！
[...] 大半のケース(ほとんどのアプリは単純なCRUD操作しか行いません)において、開発者はそのようなコストを払うべきではありません。自然に使えて、生産性の向上するAPIがあって然るべきなのです。そうは言っても、クエリの5パーセントには何らか最適化が必要です。Prismaはそのために、オペレーションを生のSQLにドロップダウンして、特定のSQLステートメントをDBに直接送信できるようになっています。
"フロントエンドの開発者はRESTエンドポイントではなく、データを注視するべきだ"という主張において、私は、PrismaにはGraphQLに通ずる部分があるのではないか、と思っています。GraphQLを使えば、データをどこから取得するのか、必要な構造にどうやってアセンブルするのか、といったことを考える必要がなくなるからです。
Prismaの生成するマイグレーションヒストリはバージョン管理が可能なので、開発中のアプリケーションの他部分と合わせて、スキーマの変更をトラッキングすることができる。Prisma Migrateは現在、PostSQL、MySQL、SQLite、SQL Server(プレビュー版として)をサポートしている。
最近リリースされたフレームワークやメタフレームワークには、Prismaをスタックに加えたものがある。Ruby on RailsのエクスペリエンスをJavaScriptで提供しようというフルスタックフレームワークのRedwoodや、Haskellで記述されたWebアプリDSLのWasp、Next.js上に構築されたフルスタックReact FrameworkであるBlitzなどが、データ層にPrismaを使用している。
オンライン公開されているPrismaのドキュメントには、チュートリアルと合わせて概念的なイントロダクションも含まれる。Prismaはベンチャーキャピタルが後援する企業で、Apache 2.0ライセンス下でオープンソースソフトウエアを提供している。