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

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上で行われています。

  • 私たちのリポジトリのissueや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

© . All rights reserved.