Prisma ORM のデプロイ
Prisma Client を使用するプロジェクトは、さまざまなクラウドプラットフォームにデプロイできます。クラウドプラットフォームには多様な種類があり、それぞれ異なる名称が付けられているため、Prisma Client を使用したアプリケーションのデプロイ方法に影響を与える異なるデプロイの形態について言及することは注目に値します。
デプロイの形態
それぞれの形態には、アプリケーションのパフォーマンス、スケーラビリティ、運用コストに影響を与える異なるトレードオフがあります。
さらに、アプリケーションのユーザートラフィックパターンも考慮すべき重要な要素です。たとえば、継続的なユーザートラフィックがあるアプリケーションは、継続的に実行される形態により適している場合がありますが、急激なスパイクがあるアプリケーションは、サーバーレスにより適している場合があります。
従来のサーバー
Node.js プロセスが継続的に実行され、同時に複数のリクエストを処理する場合、アプリケーションは従来の方法でデプロイされていることになります。アプリケーションは、Heroku、Koyeb、Render のような Platform-as-a-Service (PaaS) にデプロイしたり、Docker コンテナとして Kubernetes にデプロイしたり、仮想マシンまたはベアメタルサーバー上の Node.js プロセスとしてデプロイしたりできます。
サーバーレス関数
アプリケーションの Node.js プロセス（または関数に分割されたそのサブセット）がリクエストに応じて起動し、各関数が一度に1つのリクエストのみを処理する場合、アプリケーションはサーバーレスです。アプリケーションは、AWS Lambda や Azure Functions のような Function-as-a-Service (FaaS) 提供サービスにデプロイされる可能性が高いです。
サーバーレス環境にはウォームスタートの概念があり、これは同じ関数の後続の呼び出しで、割り当てられたプロセス、メモリ、ファイルシステム (AWS Lambda では /tmp が書き込み可能)、さらには DB 接続がまだ利用可能な既存のコンテナを使用できることを意味します。
通常、ハンドラー外のコードは初期化されたままになります。
参照: サーバーレス環境における接続管理
Edge 関数
アプリケーションがサーバーレスであり、関数がユーザーに近い1つまたは複数のリージョンに分散されている場合、アプリケーションはエッジデプロイされています。
通常、エッジ環境は従来の環境やサーバーレス環境とは異なるランタイムを持つため、一般的な API が利用できない場合があります。