メインコンテンツにスキップ

Prisma ORMを使うべきか？

Prisma ORMは、他のツールと同様に、独自のトレードオフを伴う新しい種類のORMです。このページでは、Prisma ORMがどのような場合に適しているか、また、他のシナリオの代替案について説明します。

次の場合、Prisma ORMはおそらくあなたに適しています...​

... データベースと対話するサーバーサイドアプリケーションを構築している場合​

これは、Prisma ORMの主なユースケースです。サーバーサイドアプリケーションは通常、REST、GraphQL、gRPCなどのテクノロジーを介してデータ操作を公開するAPIサーバーです。これらは一般的に、マイクロサービスまたはモノリシックアプリとして構築され、長時間実行サーバーまたはサーバーレス関数を介してデプロイされます。Prisma ORMは、これらのアプリケーションおよびデプロイメントモデルのすべてに最適です。

Prisma ORMがサポートするデータベース（リレーショナル、NoSQL、NewSQL）の完全なリストを参照してください。

... 生産性と開発者体験を重視する場合​

生産性と開発者体験は、ツールを構築する方法の中核です。手動で実行すると複雑で、エラーが発生しやすく、時間がかかるタスクに対して、開発者フレンドリーな抽象化を構築することを目指しています。

SQL初心者でもベテランでも、Prisma ORMは最も一般的なデータベースワークフローで生産性を大幅に向上させます。

以下は、ツールを設計および構築する際に適用する指針と一般的なプラクティスのいくつかです。

... チームで作業している場合​

Prisma ORMは、特に共同環境で使用する場合に威力を発揮します。

宣言的なPrismaスキーマは、誰にとっても理解しやすいデータベースの現在の状態の概要を提供します。これは、開発者が現在のテーブル構造を理解するために移行ファイルを掘り下げる必要があった従来のワークフローに対する大きな改善です。

Prisma Clientの最小限のAPIサーフェスにより、開発者は学習オーバーヘッドをあまりかけずにすぐに使い始めることができるため、チームへの新しい開発者のオンボーディングがはるかにスムーズになります。

Prisma Migrateワークフローは、共同環境でのデータベーススキーマの変更をカバーするように設計されています。最初のスキーマ作成から、スキーマ変更を本番環境にデプロイし、並行変更によって導入された競合を解決する時点まで、Prisma Migrateは対応できます。

... データベースワークフローを包括的にカバーするツールが必要な場合​

Prisma ORMは、「単なる別のORM」ではありません。私たちは、データベースと対話するアプリケーション開発者の日常的なワークフローをカバーするデータベースツールキットを構築しています。いくつかの例を挙げます。

... 型安全性を重視する場合​

Prisma ORMは、TypeScriptエコシステムで唯一の完全な型安全ORMです。生成されたPrisma Clientは、部分的なクエリとリレーションに対しても型付きのクエリ結果を保証します。これの詳細については、TypeORMとの型安全性の比較をご覧ください。

... 生の型安全なSQLを書きたい場合​

直感的で高レベルなクエリAPIに加えて、Prisma ORMは完全な型安全性で生のSQLを書く方法も提供しています。

... 透明性のある開発プロセス、適切なメンテナンスとサポートを備えたORMが必要な場合​

Prisma ORMのオープンソースツールの開発は、オープンに行われています。そのほとんどは、メインのprisma/prismaリポジトリのGitHubで直接行われています。

  • リポジトリの問題とPRは、トリアージされ、優先順位が付けられます（通常は1〜2日以内）。
  • 新機能と改善を含む新しいリリースが3週間ごとに発行されます。
  • GitHub Discussionsで質問に答える専任のサポートチームがいます。

... 素晴らしいコミュニティに参加したい場合​

Prismaには活気のあるコミュニティがあり、Discordで見つけることができます。また、定期的にミートアップ、カンファレンス、その他の開発者向けのイベントを開催しています。ぜひご参加ください！

次の場合、Prisma ORMはおそらくあなたに適していません...​

... すべてのデータベースクエリを完全に制御する必要がある場合​

Prisma ORMは抽象化です。そのため、Prisma ORMの本質的なトレードオフは、生産性の向上と引き換えに制御量が減少することです。これは、Prisma Client APIが、プレーンSQLを使用する場合よりも、一部のシナリオで機能が少ない可能性があることを意味します。

アプリケーションにPrisma ORMが提供していないデータベースクエリの要件があり、回避策のコストが高すぎる場合、プレーンSQLを使用してデータベース操作を完全に制御できるツールの方が適している可能性があります。

注：特定の制限を回避できるものの、Prisma ORMが状況を処理する方法の改善を見たい場合は、GitHubで機能リクエストを作成して、製品チームとエンジニアリングチームが調査できるようにすることをお勧めします。

代替案：SQLドライバー（例：node-postgres、mysql、sqlite3、...）

... バックエンドのコードを一切書きたくない場合​

バックエンドのコードを一切書きたくなく、APIサーバーとデータベースをすぐに生成できるようにしたい場合は、プロジェクトにBackend-as-a-Service（BaaS）を選択することをお勧めします。

BaaSを使用すると、通常、ハイレベルAPI（例：GraphQL SDL）またはビジュアルエディターを介してデータモデルを構成できます。このデータモデルに基づいて、BaaSはCRUD APIを生成し、データベースをプロビジョニングします。このセットアップでは、通常、APIサーバーとデータベースが実行されているインフラストラクチャを制御することはできません。

Prisma ORMを使用すると、Node.jsまたはTypeScriptを使用してバックエンドを自分で構築します。これは、BaaSを使用する場合と比較して、多くのコーディング作業を行う必要があることを意味します。このアプローチの利点は、バックエンドの構築、デプロイ、スケーリング、および保守に完全な柔軟性があり、スタックの重要な部分についてサードパーティソフトウェアに依存しないことです。

代替案：AWS AppSync、8base、Nhost、Supabase、Firebase、Amplication

... コードを一切書かずにCRUD GraphQL APIが必要な場合​

nexus-plugin-prismaやtypegraphql-prismaのようなツールを使用すると、GraphQL APIでPrisma ORMモデルのCRUD操作をすばやく生成できますが、これらのアプローチでは、GraphQLサーバーを手動でセットアップし、Prismaスキーマで定義されたモデルのGraphQLクエリとミューテーションを公開するためにある程度の作業が必要です。

データベースのGraphQLエンドポイントをすぐに取得したい場合は、他のツールの方がユースケースに適している可能性があります。

代替案：Hasura、Postgraphile