PrismaとGraphQLの連携方法

TLDR: GraphQLはPrismaの多くのユースケースの一つです

私たちはGraphQLを愛しており、その輝かしい未来を強く信じています！私たちはGraphQLエコシステムへの投資を続け、Prismaがデータベースに裏打ちされたGraphQLサーバーを構築するための最高のツールとなるよう努力していきます。私たちの取り組みの一例は、今後のYoga2フレームワークで、これによりGraphQLにRuby-on-Railsのような体験が提供される予定です。

PrismaはORMの代替であり、RESTやgRPC APIの構築など、GraphQL以外にも多くのユースケースがあります。Prismaの目標は、データベースワークフローを簡素化することです。データベースへのアクセス、マイグレーション、データ管理を容易にする一連のデータベースツールと考えてください。

---

歴史: GraphQLからORMとデータベースへ

Prismaが今日の姿にどのように進化してきたかを振り返り、短い歴史の授業から始めましょう。

1) Graphcool: フロントエンド開発者のためのGraphQLの簡易化

Prismaのローンチと公式リブランディングの前に、私たちのコア製品はGraphcool（オープンソースのGraphQL BaaS）でした。Graphcoolの目標は、当初から開発者がGraphQLを可能な限り簡単に使用できるようにすることでした。

Graphcoolはバックエンドスタック全体を表現していたため、アーキテクチャはシンプルでした。これにはデータベース、アプリケーションレイヤー、GraphQL APIが含まれていました。

Graphcoolを2年間本番環境で運用した後、以下のような顧客からのフィードバックや要望が繰り返し寄せられました。

• Graphcoolはその使いやすさで愛されていました。開発者はプロトタイピングにそれを使用していましたが、本番環境では独自のGraphQLサーバーを構築するためにそれをやめることがよくありました。
• 開発者は、バックエンドスタックにより多くの制御と柔軟性を求めていました。例えば、
  • データベースとAPIレイヤーの分離
  • 独自のドメイン駆動型GraphQLスキーマの定義（汎用CRUDの代わりに）
  • プログラミング言語、フレームワーク、テスト、CI/CDツールの選択の柔軟性

2) Prisma bindings: あらゆるデータベースでGraphQLサーバーを構築

Graphcoolのようなツールでは、開発者が洗練されたGraphQLバックエンドを構築するために求める要件が満たされていないことは明らかでした。この認識が私たちをPrismaへと導きました。Prismaの最初のバージョンは、Graphcoolのクエリエンジンコンポーネントのスタンドアロン版でした。

Prismaをスタンドアロンコンポーネントとして利用可能にすることで、開発者はデータベース用のCRUD GraphQL APIを迅速に生成できるようになりました。このAPIはフロントエンドから消費されるものではありませんでした。代わりに、その上にビジネスロジックを追加し、クライアント向けAPIをカスタマイズするための追加のアプリケーションレイヤーを構築するというアイデアでした。

このアプリケーションレイヤーはPrisma bindingsを使用して実装されました。この精神モデルでは、開発者が2つのGraphQL API（生成されたCRUD APIの上にカスタムのクライアント向けAPI）を扱っていることを理解する必要がありました。

Prismaの主な目標は依然として、開発者がGraphQLを可能な限り簡単に使用できるようにすることでしたが、焦点はGraphQLリゾルバーをデータベースに接続するデータアクセスレイヤーになることに移っていました。

3) Prisma Client: 従来のORMの置き換え

多くの顧客やPrismaコミュニティとの対話を経て、Prismaが何であるか（そして最終的に何になり得るか）についての私たちの理解は、再びかなり進化しました。

Prisma bindingsを使用してGraphQLサーバーを構築する以前のアプローチには、いくつかの問題がありました。

• Prisma bindingsは開始を容易にしましたが、より高度なユースケースで開発者が理解する必要がある概念の複雑さは、天井知らずでした（スキーマデリゲーションの複雑さとinfoオブジェクトのため）。
• 完全に型安全なリゾルバーを達成することは非常に困難で非実用的でした。
• JavaScriptエコシステムに限定されていました。
• ユースケースとしてGraphQLに限定されていました。

Prismaクライアントはこれらの問題を解決します。これは、シンプルで完全に型安全なデータアクセスAPIを備えた自動生成されるデータベースクライアントです。

この新しいアプローチにより、生成されたCRUD GraphQL APIは、Prismaのコア開発ワークフローの一部ではなくなりました。むしろそれは実装の詳細となります。

Prismaサーバーの追加の必要性をなくし、アプリケーションサーバー内で直接使用できるバージョンのPrismaがまもなく登場することに注意してください。

現在のPrismaクライアントAPIは、すでに最高のデータアクセスAPIの1つであると信じていますが、多くのコミュニティからのフィードバックが、さらなる改善に役立ちました。その結果、近日中にリリースされる非常に強力で直感的なデータベースAPIが生まれました。

Prismaクライアントにはdataloaderが内蔵されているため、GraphQLサーバーのリゾルバーを実装するのに最適なツールです。

---

Prismaによって生成されるGraphQL APIの考え方

生成されたPrisma GraphQL CRUD APIが実装の詳細と見なされることを理解することは、Prismaの焦点と将来の方向性を把握するために重要です。

宣言的データモデルから生成されるGraphQL CRUDへ

Prismaの核となるアイデアは常に同じでした。

1. 開発者はGraphQL SDLでデータモデルを定義し、それをデータベースにマッピングする
2. Prismaはデータモデルに基づいて強力なCRUD GraphQL APIを生成する
3. 生成されたCRUD GraphQL APIは、アプリケーションレイヤーとクライアント向けAPIの基盤として使用される（Graphcoolを除く）

生成されたCRUD GraphQL APIはPrisma bindingsでは絶対に不可欠でしたが、Prismaクライアントでは実装の詳細になりました。

これは、Prismaウェブサイトの最新の再設計にも反映されており、PrismaクライアントがGraphQLに代わって主要なテーマとなっています。

PrismaのCRUD GraphQL APIの重点を低下させる

今日、開発者はPrismaクライアントが基盤となるデータベースとどのように通信するかを気にするべきではありません。開発者が気にするべきはPrismaクライアントAPIです！

これを公式ドキュメントに反映させるため、前回のPrismaリリースでPrisma GraphQL APIのドキュメントを削除しました。それでもドキュメントが必要な場合は、ドキュメントの古いPrismaバージョンに移動してアクセスできます。

また、GraphQL Playgroundに加えて、Prismaプロジェクトのデータとやり取りするための追加ツールとしてPrisma Adminを導入しました。

GraphQL SDLでのデータモデリング

PrismaとGraphQLに関するもう一つの一般的な混乱の原因はデータモデリングです。Prismaを使用する場合、データモデルはGraphQLのスキーマ定義言語（SDL）のサブセットを使用して指定されます。

データモデルのファイルタイプを.graphqlから.prismaにすでに調整しましたが、データモデリングにSDLを使用することは、依然としてGraphQLとの強い結びつきです。しかし、私たちは現在、独自のモデル言語（SDLの修正版となる予定）に取り組んでいます。

PrismaとAWS AppSync & Hasuraの比較

PrismaのCRUD GraphQL APIの役割について新しい理解を得ると、Prismaがもはや「GraphQL-as-a-Service」のカテゴリーに属さないことが明らかになります。

AWS AppSyncやHasuraのようなツールは、データベース（AppSyncの場合は他のデータソースも）用に生成されたGraphQL APIを提供します。対照的に、Prismaは様々な言語で簡素化された型安全なデータベースアクセスを可能にします。

---

GraphQLはPrismaにとって重要なユースケースです

Prismaクライアントがリリースされて以来、Prismaが内部的にGraphQLを使用していることは実装の詳細と見なされています。それでは、GraphQLはPrismaにとってどのような役割を果たすのでしょうか？

私たちはGraphQLが大好きです

私たちにとって答えは明確です。私たちは依然としてGraphQLを最も重要な今後のAPIテクノロジーの1つと見なし、開発者がGraphQLサーバーを可能な限り簡単に構築できるようにしたいと考えています。GraphQLはPrismaにとって重要なユースケースであり続けます！

GraphQLエコシステムへの投資

私たちはオープンソースのGraphQLエコシステムへの投資を継続します。私たちが構築した多くのツールは、GraphQL Playground、graphql-yoga、GraphQL Nexus（Tim Griesserが構築）など、多くのGraphQL開発ワークフローでデフォルトとなっています。

最近発表されたnexus-prismaは、Prismaの上にGraphQLサーバーを実装することを非常に容易にします。今後のYoga2フレームワークでは、GraphQLにRuby-on-Railsのような開発体験をさらに提供することを目指しています。

GraphQLコミュニティへの貢献

GraphQLエコシステムに投資するのと同様に、私たちはGraphQLコミュニティにも貢献したいと考えています。私たちは世界最大のGraphQLコミュニティカンファレンスを運営し、How to GraphQLやGraphQL Weeklyなどの人気リソースを維持しています。

私たちは最初の参加企業ではありませんでしたが、間違いなくGraphQL Foundationの一員となり、その将来の方向性を導く手助けをすることも計画しています。

---

🔮 未来への一瞥

この記事全体で強調されているように、私たちはPrismaに対して多くのエキサイティングで根本的な改善に取り組んでいます。現在取り組んでいることの概要については、ぜひ私たちのロードマップをご覧ください。

私たちは今後のすべての機能を公開で（GitHubのIssueとRFCプロセスを通じて）仕様化していますので、ぜひGitHubでの議論に参加し、ご意見をお聞かせください！

ご質問やご意見がありましたら、Spectrumで共有してください。

採用しています！ロードマップの項目の一つに、PrismaコアのRustでの完全な書き換えがあります。Rustエンジニアの方、または高度な技術的課題とオープンソース開発に全般的に興味のある方は、ぜひ私たちの採用ページをご覧ください。