イブ・ポーセロとのスマッシングポッドキャストエピソード31：GraphQLとは何ですか？

公開: 2022-03-10

クイック概要は↬このエピソードでは、我々はGraphQLの話をしています。それは何ですか、そしていくつかの一般的なAPIの問題をどのように解決しますか？ドリュー・マクレランが専門家のイブ・ポーセロと話をして調べます。

このエピソードでは、GraphQLについて話します。それは何ですか、そしていくつかの一般的なAPIの問題をどのように解決しますか？私は専門家のイブ・ポーセロと話をして調べました。

メモを表示

Twitterのイヴ
イブの会社ムーンハイウェイ
O'ReillyからGraphQLを学ぶ
GraphQLの荒野であなたの道を発見-2021年初頭に開始されたEveのGraphQLワークショップ

毎週の更新

Next.jsWebサイトでSanityに保存されているMDXを使用する方法
ジェイソン・レングストルフ脚本の作品
GoogleのDialogflowを使用した会話型NLP対応チャットボットの構築
NwaniVictoryによって書かれました
UX研究における倫理的考慮事項：トレーニングとレビューの必要性
ビクターヨッコによって書かれました
ウェブサイトとの会話を容易にする
フレデリックオブライエンによって書かれました
複雑なソリューションがある場合にシンプルなUIを設計する方法
スザンヌスカッカによって書かれました

トランスクリプト

イブ・ポーセロの写真 Drew McLellan：彼女はソフトウェアエンジニア、インストラクター、著者であり、トレーニングおよびカリキュラム開発会社であるMoonHighwayの共同創設者です。彼女のキャリアは、技術仕様の作成とWebプロジェクトのUXデザインの作成を開始しました。 2012年にMoonHighwayを開始して以来、彼女はegghead.ioとLinkedIn Learningのビデオコンテンツを作成し、O'Reilly'sMediaのLearningReactとLearningGraphQLの本を共同執筆しています。

Drew：彼女は頻繁に会議の講演者でもあり、React Rally、GraphQL Summit、OSCONなどの会議でプレゼンテーションを行ってきました。彼女がGraphQLのエキスパートであることはわかっていますが、彼女がかつてホッキョクグマにチェスをするように教えたことを知っていましたか？私の壊滅的な友人、イブ・ポーセロを歓迎してください。

ドリュー：こんにちはイブ、お元気ですか？

イブ・ポーセロ：私は粉砕しています。

Drew：そこで述べたように、あなたはJavaScriptやReactのようなものの教育者ですが、今日は他の専門分野の1つであるGraphQLについてお話ししたいと思います。私たちの多くは、GraphQLについてある程度聞いたことがあるでしょうが、それが何であるか、それが何をするのか、特にWebスタックでどのような問題を解決するのか完全にはわからないかもしれません。

ドリュー：あなたがするのであれば、私はGraphQLスロットが生態系に行い、それが私のためにどのような機能を実行んフロントエンドの開発者、だならば、私たちのための段階を設定しましたか？

イブ：うん。 GraphQLは、フロントエンドとバックエンドの間にある種の適合です。これは、2つの中間にあるようなものであり、フロントエンド開発者とバックエンド開発者に多くのメリットをもたらします。

Eve：フロントエンド開発者の場合、すべてのフロントエンドデータ要件を定義できます。したがって、たとえばReactコンポーネントの大きなリストがある場合は、クエリを作成できます。これで、そのページのデータを入力するために必要なすべてのフィールドが定義されます。

イブは：私たちは、さまざまなソースのロットから大量のデータを収集することができますので、今のバックエンドピースと、それは、本当に自分のです。つまり、REST API、データベース、およびこれらすべてのさまざまな場所にデータがあります。そして、GraphQLは、すべてのデータが存在する場所の混乱を実際に理解するための、この素敵な小さなオーケストレーションレイヤーを提供します。すべてのスタックの上に皆の種類のために非常に便利です、それはそう。

ドリュー：基本的にはAPIベースのテクノロジーですね。フロントエンドとバックエンドの間に位置し、ある種のAPIを提供しますが、それは正しいですか？

イブ：ええ、その通りです。丁度。

ドリュー：私が思うに、過去10年間で、APIのゴールドスタンダードは休みとなっています。あなたはクライアント側のアプリを持っていて、バックエンドからデータを移入する必要があるのであれば、あなたは、REST APIエンドポイントを構築するだろうし、あなたはそれを照会したいです。では、そのモデルはどこに落ちるのでしょうか？そして、ときに我々はGraphQLがで来て、私たちのためにそれを解決する必要があるかもしれませんか？

Eve：ええと、GraphQLが本当に役立つ問題、一種の黄金の問題、GraphQLが提供する黄金の解決策は、RESTでは大量のデータを過剰にフェッチしていることだと思います。だから私は、ユーザーをスラッシュやバック、すべてのデータの私はルートを打つたびに私を与えるために起こっている製品を、スラッシュしている場合。

Eve： GraphQLを使用すると、必要なデータについて少し気を配ることができます。したがって、100個のオブジェクトから4つのフィールドのみが必要な場合は、それらのフィールドを実際に特定でき、データをデバイスにロードしたり、すべてのデータをデバイスにロードしたりする必要はありません。これは、特にお使いの携帯電話にとって、多くの余分な手間がかかります。

Drew：私は過去にREST APIを見て作業しました。これには、戻したいデータのリストを渡すことができるオプションのフィールドがあるか、余分なもので戻ってくるものを拡張することができます。そして、それがこの問題を特定していると思いますね。つまり、毎回同じデータが返されるとは限りません。では、GraphQLは、フロントエンドがデータの観点からバックエンドが返すものを指定できるようにするというアプローチを形式化したのでしょうか？

イブ：ええ、その通りです。そして、あなたが尋ねるどのようになると、あなたのクエリがそれでは、どのようにフィルタを、あなたはどこからでも情報の任意の並べ替えのために把握する方法。

Eve： GraphQLを実際に正常に機能させるために、すべてのRESTAPIを破棄する必要がないことにも注意することが重要だと思います。私が見た中で最も成功したGraphQLの実装の多くは、RESTAPIのラッパーです。そしてGraphQLクエリは本当にあなたが必要なものデータについて考える方法を提供します。そして、おそらくあなたのデータのいくつかは私たちのユーザーと製品から来ています、例、データのいくつかはRESTから来ています、それのいくつかはデータベースから来ています。

ドリュー：おなじみのシナリオは、ヘッダーを表示するためにユーザーに関する情報を返すエンドポイントがWebサイトにある可能性があることだと思います。それはあなたに彼らのユーザー名と彼らのアバターを与えるかもしれません。そして、それをすべてのページでカリングしてデータを入力しますが、アプリ内の別の場所でフルネームを表示する必要があります。

ドリュー：それをエンドポイントに追加すると、それが返され始めます。そして、あなたはあなたのアカウント管理セクションを行います、そしてあなたは彼らの郵送先住所のように必要です。そのため、そのエンドポイントからも返されます。

ドリュー：そして、あなたがそれを知る前に、そのエンドポイントは、バックエンドでまとめるのにかなりの費用がかかり、明らかにダウンロードするのにかなりの費用がかかる全体の重いペイロードを返しています。

ドリュー：そして、それはアバターを表示するためだけにすべてのページでカリングされています。ですから、これは時間の経過とともに大きくなる種類の問題であり、特に大規模なチームでは、GraphQLがその問題の上にあるため、非常に簡単に陥ることができたと思います。それはそれを解決する方法を知っており、それを解決することを中心に設計されています。

EVE：正確に。そして、ええ、私はGraphQLスキーマの全体的なアイデアは、私が思うに、本当に、それは種類少ないGraphQLのクエリ言語の一部よりの話のだと思います。しかし、特にスキーマがAPI用のこの優れた型システムを提供しているように感じます。

イヴ：だから、チームの誰も、管理職、フロントエンドの開発者、バックエンドの開発者、本当にデータを扱っている誰もが一緒に来ることができ、データは、我々は実際にこのAPI上に提供するために何をしたいの周りに合体して、誰もが何そのソースを知っています真実は、彼らはそれに基づいてアプリの独自の部分を構築することができるということです。

Eve：それで、それを思い付くいくつかのトリッキーなスキーマ管理があります。しかし、これまでのバックモノリスにmicroservicesから移動するように、我々はソートことをやって、私たちはまだmicroservicesのうち好きな利点のすべてを取得しますよ。

Drew： GraphQLシステムを設定する一般的な方法は、基本的に1つのルートを使用することです。これは、すべてのクエリを送信するエンドポイントであるため、必要がないことを正しく理解していますか。最も困難な事が名前を付けるために何かを取り組んでいる、とパスは、この特定のクエリがでなければならないことがどうあるべきか。それはリピーターと製品です、それはユーザーをスラッシュするべきですか、それとも製品をスラッシュするべきですか？

ドリュー：GraphQLであなただけのあなただけにクエリを発射することを一方のエンドポイントを持っていて、適切な応答を取り戻します。

EVE：正確に。うん。これは単一のエンドポイントです。スキーマ内のすべてに名前を付けているので、まだ名前の問題に取り組んでいると思います。しかし、私は、マイクロサービスに大きな賭けをしている多くの企業のように感じます。誰もが、どのようなエンドポイントを持っているのでしょうか。彼らはどこにいる？それらはどのように文書化されていますか？また、GraphQLを使用すると、APIがどのように機能するかについて知りたいことをすべて検索するための、1つの場所と1種類の辞書があります。

ドリューは：SQLは、Web開発者の多くが知っていることをクエリ言語の明らかな例であるようなので、私は、他のクエリ言語に精通してい。そして、その中のクエリは、ほとんどのようなコマンドの形をとります。それはテキスト文字列ですよね、それからこれを選択してください。クエリはGraphQLでどのような形式を取りますか？

イブ：それはまだハイテク文字列だが、そのロジックはどこから来るそれが定義されていません。そして、ロジックの多くはサーバーに戻されます。 GraphQLサーバだから、GraphQL APIは、言って、本当に責任がある「Goは、それは、それは、これらのパラメータに基づいてフィルタであるところから、このデータを取得します。」

Eve：しかし、クエリ言語では、非常にフィールド指向です。だから私たちは検索したいもののためのフィールドを追加するだけです。もちろん、これらのクエリにフィルタを適用することもできます。しかし、私はそれは少しその情報がどこから来るかについての直接のだと思います。多くの機能がサーバーに組み込まれています。

ドリュー：クエリで組み合わせることができます。 1回のリクエストでさまざまな種類のデータを取り戻すリクエストを作成できます。そうですか？

イブ：ええ、その通りです。したがって、サーバーが許可する限り多くのフィールドに対してクエリを送信し、あらゆる種類のネストされたデータを戻すことができます。しかし、それが実際に機能する方法です。フィールドでさまざまなタイプを接続します。したがって、ユーザーと製品のアイデアをリサイクルすると思いますが、ユーザーには製品のリストを返す製品フィールドがある場合があります。それらはすべて他のタイプにも関連付けられています。したがって、クエリを実行したいだけ深くネストすることができます。

Drew：つまり、あらゆる種類の処理が行われている可能性のあるWebアプリケーションの一般的なビューのデータを取得することを意味します。つまり、バックエンドに1つのリクエストを送信するだけで、別のデータを作成しなくても、すべてを一度に取得できます。異なるエンドポイントへのクエリ、それはすべてただ一つのことはだから？

イブ：うん。それがまさに全体の目標であり、単一のクエリであり、必要なすべてのフィールドを定義して、それを1つの応答で返します。

Drew：クエリはJSONベースですよね？

Eve：クエリ自体はテキスト文字列ですが、通常はJSONデータを返します。したがって、フィールドがある場合、JSON応答は完全に一致します。したがって、データ応答はまったく同じように見えるため、そのクエリを送信したときに何が得られるかは非常に明確です。

ドリュー：クエリの多くは、顧客や製品など、ほとんど裸のオブジェクトのように見えます。ビジネスロジックがバックエンドで制御される、より複雑なクエリを指定する方法はありますか？ユーザーのチームのリストを取得したいとしますが、そのユーザーがチームの管理者であり、チームプランの有効期限が切れていない場合、および日常のWebアプリケーション開発で直面するすべての種類の実際の制約のみです。それはGraphQLで達成できますか？

イブ：絶対に。これがGraphQLの本当にエキサイティングで強力なことです。つまり、そのロジックの多くをサーバーに移動できます。複雑なクエリ、取得したい特定のタイプのユーザーがある場合、スキーマで行う必要があるのは「複雑なユーザーを取得する」と言うだけです。サーバー上には、次のような関数があります。すべてのロジックを好きな言語で書くことができます。 JavaScriptは最も人気のあるGraphQL実装言語の一種ですが、それを使用する必要はまったくありません。つまり、Python、Go、C ++など、使用したいものが何であれ、それを使用してGraphQLサーバーを構築できます。しかし、ええ、あなたはあなたが望むように複雑なクエリを定義することができます。

ドリュー：それで、多くのビジネスロジックを新しいタイプのオブジェクトにカプセル化できるようになると思います。それは公平ですか？ご存知のとおり、複雑なユーザーを設定すれば、複雑なユーザーが何であるかを考える必要はありませんが、その複雑なユーザーを使い続けるだけで、ビジネスロジックがその上に実装されていることがわかります。そうですか？

イブ：その通りです。ですから、これはフロントエンドの人々にとって本当に素晴らしいことだと思います。なぜなら、彼らはそれに基づいてプロトタイプを作成し始めることができるからです。そして、バックエンドチームは、それらの機能を実装して、それを機能させることができます。そして、その型が実際にであり、彼らが誰であるか、そして何のために親切、この共通の理解のあります「というタイプのフィールドは何ですか？」そして、すべてはスタックのどこでもGraphQLが機能している場所で処理できます。そしてそれが、それが実際にはフロントエンドまたはバックエンドテクノロジーではない理由です。それは本当に両方の種類であり、どちらでもありません。

Drew： APIとフロントエンドとバックエンドの関係を形式化したようなもののように聞こえるので、誰もが標準化された予測可能なインターフェースを手に入れています。

EVE：正確に。

ドリュー：フロントエンドとバックエンドが異なるチームによって所有されている組織では、これはまったく珍しいことではないと思いますが、このアプローチでは、フロントエンドで変更を加えることもできると思います。たとえば、フロントエンドで異なる必要がある場合があります。データ、それに対応する変更を行うためにバックエンドで作業する誰かを必要とせずに。新しいデータが必要な場合に変更するための作業を必要とせずに、このほぼ無限にカスタマイズ可能なAPIを引き続き使用できます。

イブ：ええ、その通りです。

Drew：では、GraphQLサーバーは応答のフォーマットを担当しますか、それともサーバー側のロジックでそれを行う必要がありますか？

Eve：つまり、GraphQLサーバーは2つのことを定義します。サーバー上に存在するスキーマ自体を定義し、次にリゾルバー機能を定義します。それらはそれがどこからデータを取りに行くの機能です。したがって、GraphQLでラップしているREST APIがある場合、リゾルバーはそのAPIからフェッチし、必要に応じてデータを変換してから、その関数でクライアントに返します。あなたは、あなたにもそのサーバー上のしたいデータベース機能の任意の並べ替えを使用することができます。したがって、さまざまな場所にデータがある場合、これは、すべてのデータを配置し、すべてのロジックを設計するための非常に優れたまとまりのある場所です。どのように変換したいですか？」

Drew：クライアントが「複雑なユーザーが欲しい」と言うと、サーバーはクエリでそれを受け取り、「そうです、複雑なユーザーリゾルバーを検索します」と言うことができます。そうですか？

イブ：うーん（肯定的）。

Drew：これは関数です。次に、バックエンドチーム、またはその関数内にロジックを記述した人が、複雑なユーザーを返すために必要なことをすべて実行するロジックを記述します。

イブ：ええ、その通りです。

Drew：他のAPIを呼び出したり、データベースにクエリを実行したり、キャッシュ内のものを検索したりする可能性があります。

イブ：ほとんど何でも。そして、関数からの戻り値がスキーマの要件に一致し、そこに返されるフィールド、タイプが一致する限り、すべてがうまく調和して機能します。

Drew：デフォルトでは、API全体で一貫した応答形式が提供されると思います。あなたはそれがどのように見えるかをデザインする必要はありません。一貫した結果が得られます。

イブ：ええ、その通りです。

Drew：特に大規模なチームでは、広範囲のAPIエンドポイント間で一貫性を維持することが非常に難しいため、これは非常に大きなメリットになると思います。さまざまな人々がさまざまなことに取り組んでいます。非常に厳格なガバナンスを実施していない限り、非常に迅速に複雑になる可能性がありますね。

イブ：ええ、もちろんです。そして、私は、スキーマはすべてを記述するだけで、このような素敵な小さな文書であると思います。、あなたはあなたがイントロスペクションクエリを送信することができますので、それにクエリを送信しようとしているときは常にそのスキーマ内のすべてのフィールドを見ることができるの自動利益を取得し、そのための素晴らしいツールのすべての種類はGraphQLとGraphQL遊び場のような、あります小さなツールを使用するには、APIのデータと対話するために使用することができます。

Eve：しかし、REST APIにpingを実行するなど、Postmanをいじったことがある場合は、ドキュメントが実際には存在しないか、見つけるのが難しいなどです。 GraphQLは、そのAPIの一部である可能性のあるすべてのものを記述するための優れたまとまりのあるレイヤーを実際に提供します。

ドリュー：実際には、サーバー側ではどのように機能しますか？つまり、インフラストラクチャの一部としてGraphQLサービスを実行する必要があると思いますが、それはどのような形式を取りますか？サーバー全体が独自のポートで実行されていますか？それとも、既存のExpressやApacheに統合するライブラリのようなものですか、それともそのサービスに解決されるルートを備えたものですか？どのように実装しますか？

Eve：ええ、それは実際のサーバーです。したがって、最も人気のあるGraphQL実装の一種はNode.jsサーバーです。仕様としてのGraphQLがリリースされたとき、チームはJavaScriptでこのリファレンス実装をリリースしました。これは、ポップアップした他のすべてのサーバーのガイドラインとして機能する一種のノードサーバーです。しかし、ええ、これらのサーバーを独自のインスタンスで実行できます。あなたはそれらをラムダに置くことができます。だから、アポロServer Expressはあります、アポロサーバーラムダがあります。このことを実際に実行するために使用できるあらゆる種類の異なるタイプの実装。

ドリュー：だからあなたは、サーバーが持っているスキーマの概念の前に簡単に述べました。

イブ：ええ。

ドリュー：あなたはより厳密にだけ、あなたが知っている、リゾルバに名前をマッピングするよりも、あなたのタイプを記述することができます。そこにはもっと関わっていますね

イブ：うん。完全な言語があります。そのため、仕様を参照しましたが、それが何であるかについては説明しませんでした。 GraphQL自体は、クエリ言語とスキーマ定義言語を記述する仕様です。したがって、独自の構文があります。これらのタイプを定義するための独自のルールがあります。

Eve：スキーマ定義言語を使用している場合、基本的にその言語のすべての機能を使用して考えます。APIの一部であるタイプは何ですか？また、アクションのような動詞であるクエリやミューテーションを定義したり、アカウントログインを作成したりする場所でもあります。また、別の優れた機能であるGraphQLサブスクリプションでさえ、スキーマですぐに定義できるリアルタイムのGraphQLです。

Eve：そうですね、スキーマは本当に重要です。そして、フルスタックアプリケーション全体でこの優れたタイプエンフォースメントが得られると思います。これらのフィールドとタイプから逸脱し始めるとすぐにエラーが表示されるようになるためです。この場合、エラーが発生します。スキーマのルールに従っています。

Drew：それとTypeScriptの間にクロスオーバーはありますか？そこには2つの間にある種の相乗効果がありますか？

イブ：絶対に。ですから、あなたがGraphQLについてよく話す人なら、時々人々はそれが悪いとあなたに言うでしょう、そしてあなたがそれをすることができるとき彼らは公にあなたのところに来て、GraphQLがいかに良くないかについて話します。しかし、多くの場合、彼らはあなたがタイプから得るクールなものをスキップします。だから、限り活字体との相乗効果が行くように、絶対に、あなたはスキーマからの型を使用して、フロントエンドアプリケーションの種類を自動生成することができます。初めて生成するだけでなく、フロントエンドアプリケーションとの相互運用性が向上するだけでなく、状況が変化したときに型を再生成してから、それらの変更を反映するようにビルドできるため、これは大きなメリットです。そうですね、型が事実上のルールのようなものになり始めているので、これらのものは本当にうまく調和していると思います。

イブは：...種類JavaScriptで事実上のルールのように、彼らは一緒にうまく収まります。

Drew： TypeScriptが設計された方法で、ある種の継続的なテーマのようです…申し訳ありませんが、TypeScriptではありません。 GraphQLは、フロントエンドとバックエンドの間の相互作用を定式化についての多くがありますように設計されています。そしてそれは、これまで多くの人々にとって休息をとったかなりごちゃごちゃした経験であったものの一貫性と形式化を作成するだけの中間の解決策として来ています。私たちは常にクライアント側のアプリケーションを書くときに心に留めておく必要があることの一つは、コードを検査し、潜在的に修正の対象であるということです。また、クライアントがデータを要求できるAPIを使用するのは危険な場合があります。さて、必要なフィールドを指定できれば、それは危険かもしれません。スタック全体の一種で、あなたはどこにユーザーの許可に対処し、あなたのデータの周りのビジネスルールが施行ていることを確認して作るのでしょうか？

Eve：サーバー上ですべてを処理します。したがって、それはさまざまな方法で発生する可能性があります。 1回限りの戦略を使用する必要はありませんが、リゾルバーが承認を処理します。それはあなたがあなた自身の上に構築されてきましたAuth0のようなサービスか何かのように、既存のREST APIオフを包む意味するかもしれませんので。これは、GitHub、Facebook、GoogleログインなどのOAuthとやり取りすることを意味する可能性があります。これには、リゾルバーとの間でトークンをやり取りするような種類のものが含まれます。しかし、多くの場合、それはスキーマに直接組み込まれます。したがって、スキーマには、ログインミューテーションが作成されると表示されます。次に、クレデンシャルを使用してそのミューテーションを送信し、サーバー上でそれらのクレデンシャルがすべて検証されます。したがって、クライアントはそれほど心配する必要はありません。トークンを渡すなどのことを少し行うかもしれません。しかし、そのほとんどはサーバーに組み込まれているだけです。

Drew：基本的に、現時点でRESTエンドポイントを構築している方法と比べて実際には変わりません。技術として休む、まあ、それは本当にいずれかの権限を扱っていないと我々はそれを扱い、そのサーバー上のミドルウェアやものを持っています。そして、それはGraphQLでも同じです。あなたはそれに対処するだけです。それを行うためのGraphQLコミュニティ内のすべての規則がありますか？一般的なアプローチはありますか、それとも人々がそれを実装する方法を選択するためのあらゆる場所にありますか？

イブ：正直なところ、あちこちにあります。ほとんどの場合、スキーマに組み込まれている人々を目にすることになると思います。つまり、これらのタイプと許可されたユーザーを表すのに対して、通常のユーザーはそれらのタイプをスキーマ自体に組み込んでいます。しかし、あなたはサードパーティのソリューションを使ってたくさんの人々も見えます。 Auth0について触れました。多くの人々は、それに焦点を当てている企業、特に中小企業や新興企業などに、認可をオフロードするでしょう。しかし、大企業がこのためのソリューションを作成し始めていることもわかります。だから、AWSは、AmazonはGraphQLの彼らの味であるAppSyncを、持っている、と彼らはAppSyncに直接組み込まれ、著者のロールを持っています。そして、それは一種のクールのちょうど、私にはわからないことができるようにするためだ、その原料の全部または少なくとも心配する必要はありませんが、そのを扱うためのインタフェースを提供します。したがって、これらのエコシステムツールの多くには、承認がGraphQLの非常に大きなトピックであると思います。彼らは、必要性の種類、認証ソリューション、グラフ上の認証を処理する標準的なアプローチのための需要を見てきました。

ドリュー：ある種の承認を必要としない実装はほとんどないと思います。そうですね、それはかなり一般的な要件になるでしょう。私たちは皆、コンポーネント化されたアプリケーションをますます構築しています。特に、ReactとViewを使用している場合や、何を使用している場合はそうです。また、緩い結合の原則により、周囲のページで他に何が実行されているかを必ずしも認識していない多くのコンポーネントが残ります。その結果、多くのコンポーネントが同じデータをクエリして複数のリクエストを行う可能性があるという危険性はありますか？それともただの建築の問題は、あなたがそれを解くために必要なことを、あなたのアプリにありますか？それに対処するための整ったトロッドデンのソリューションの種類はありますか？

Eve：ええと、GraphQLはほとんどの場合、ソリューションの100％ではなく、ほとんどすべてのGraphQLクエリがHTTP経由で送信されるためだと思います。したがって、これらの複数のリクエストが発生している場所を追跡したい場合、アプリケーションにRESTデータを使用している人々にとってはおそらくかなりなじみのある問題です。そのため、フロントエンド開発者向けのPaulo Client DevToolsやUrkelDevToolsなどのツールがあります。このページにはどのクエリがありますか？」それはあなたに何が起こっているかについての本当に明確な洞察を与えます。それにはいくつかの考え方があります。ページのすべてのデータに対して1つの大きな巨大なクエリを作成しますか？または、アプリのさまざまな部分のデータを読み込むための小さなクエリを作成しますか？ご想像のとおり、どちらにも独自の欠点があります。大きなクエリがある場合は、さらに多くのフィールドを待っているからです。

Eve：クエリが小さい場合、必要なデータ間で衝突が発生する可能性があります。しかし、私が思うに、および接線のあまりにオフに行くことはないが、私はすでにそこです。そのため、GraphQL仕様に追加される遅延ディレクティブと呼ばれるものがあり、遅延ディレクティブは一種の二次的なコンテンツのロードに役立ちます。そのため、ページ上部にいくつかのコンテンツがあるとしましょう。最初にロードしたい超重要なコンテンツ。それをクエリに追加すると、後続のフィールドはその上で遅延ディレクティブを取得します。これは、フィールドに追加する小さなデコレータであり、「わかりました。最初に重要なデータをロードし、次に2番目のデータを保持してロードします。」と表示されます。それは一種のあなたにこれを与え、それは、体感的なパフォーマンスがありますのでという、そこの対話あなたのフロントエンドへのストリーミングデータの種類の出現です。人々は、すべてのフィールドがページに読み込まれるのを待つのではなく、すぐにデータを表示しています。これは問題になる可能性があります。

ドリュー：うん。私はそれはあなたがすべてをのは...私たちは、ビューポートについてはあまり話を好きではないが、それは倍以上のすべてです、あなたが優先順位を付けることができ、中にその負荷を持っているし、その後二更のすべてのソートにロードすることを建築家のページにできます推測します下。そのため、データのクエリについて多くのことを話しました。 APIの主な仕事の1つは、永続化のために新しいデータと変更されたデータをサーバーに送り返すことです。先ほど簡単に突然変異についてお話しました。これは、GraphQLがサーバーにデータを書き戻すために使用する用語ですか？

EVE：正確に。したがって、データに加えたいあらゆる種類の変更、サーバーに書き戻したいあらゆる変更、それらはミューテーションであり、それらはすべてクエリと同じであり、サーバー上に存在する名前付き操作です。だから、私達は私達のユーザーが行うことができるようにしたいすべてのものが何であるかを考えることができますか？突然変異のある人を表します。そして、再びサーバー上で、そのスタッフの仕事をするすべての機能を記述します。

ドリュー：それはデータのクエリと同じくらい簡単ですか？突然変異を呼び出すのも同じくらい簡単ですか？

イブ：うん。これはクエリ言語の一部です。見た目はほとんど同じです。唯一の違いは、まあ、私はクエリをフィルタで取り込むと思います。だから、変異は、クエリ自体にフィルタのように見えたものを撮影しました。しかし、それらは実際にデータを変更する責任があります。電子メールとパスワードが変更されて送信される可能性があり、サーバーはそれを収集し、それを使用してユーザーを承認します。

ドリュー：だからは、以前と同じように、あなたはそれに対処するためにして行われる必要があるものは何でもするためにバックエンドでのリゾルバを作成しています。データを書き込むときによくあることの1つは、変更をコミットしてから再クエリを実行して、データの現在の状態の種類を取得することです。 GraphQLにはそのための優れたワークフローがありますか？

イブ：それは突然変異自体の中にある種の生き物です。したがって、スキーマを作成するときに、ミューテーション操作を作成することがよくあります。私がログインに固執するだろう、メールアドレスとパスワードを取り込みます。そして、突然変異自体が何かを返しました。したがって、ブール値のような単純なものを返す可能性があります。これはうまくいったか、うまくいかなかったか、実際の型を返す可能性があります。そのため、ログインミューテーションのようなミューテーションが表示されることがよくありますが、ユーザーを返す可能性があります。したがって、ユーザーがログインすると、ユーザーに関するすべての情報を取得できます。または、ユーザーに加えてユーザーがログインした時間を提供するカスタムオブジェクトタイプを作成し、リターンオブジェクトでそのトランザクションに関するメタデータをもう少し作成することもできます。。繰り返しになりますが、それを設計するのはあなた次第ですが、そのパターンは実際にGraphQLに組み込まれています。

ドリュー：このすべての音はかなり素晴らしいが、すべての技術的な選択はトレードオフを伴います。 GraphQLを使用することの欠点は何ですか？それが本当に悪い選択になるシナリオはありますか？

Eve： GraphQLが苦労するかもしれない場所は、1対1のマップを作成していると思います-

イブ：...闘争は、表形式のデータの1対1のマップを作成しています。たとえば、さまざまな種類のフィールドを持つデータベーステーブルがあるとしましょう。特定のタイプの何千ものフィールドなど、そのタイプのデータを適切に表すことができます。 GraphQLを使用しますが、そのデータに対してスキーマを生成するプロセスを実行すると、データベースで発生したのと同じ問題がスキーマに残ることがあります。これは、クライアントのデータを超えるデータが多すぎる可能性があります。実際に必要です。だから私はそれらの場所は潜在的に問題だと思います。データに基づいて自動生成されたスキーマを持っている人々と話をしましたが、それは数百万行のスキーマまたはそのようなものになり、数千行のスキーマコードになりました。そして、それが少しトリッキーになるところです。たとえば、これが人間が読める形式のドキュメントとしてどれほど役立つのでしょうか。

イブ：うん。したがって、クライアントを扱っているあらゆる種類の状況では、さまざまなタイプのデータをモデル化する限り、非常に適しています。データソースが大きすぎると、少し注意が必要になります。

ドリュー：つまり、フィールドでの応答を注意深くキュレートし、それをより手作業で行うところならどこでも、非常に強力な結果を得ることができるように思えます。しかし、あなたが巨大なスキーマを持っていただけだから自動生成されているならば、それからそれは少し扱いにくいでしょう。

イブ：うん。そして、私は人々が耳を傾け、そのための良いツールがそこにもあるので、その上で私と一緒に不同意されていると思います。しかし、私はGraphQLが本当に輝く場所のようなものだと思う、サーバーにロジックを抽象化するフロントエンド開発者はそのコンポーネントまたはそのフロントエンドのデータ要件を定義する自由を与え、そして本当にチームとしてスキーマを管理することのステップです。

ドリューは：結果のページネーションに対処するためのクエリ言語に組み込まれているのが何の一種である、または必要に応じてカスタム実装へのダウンしていますか？

イブ：ええ。ページ付け、最初にスキーマに組み込むので、そのためのページ付けを定義できます。コミュニティには、ある種のガイドラインが浮かび上がってきました。あなたがGraphQLまたは新しくないなら見に良い例が、私はこのすべての時間を見て、GitHubのGraphQL APIです。彼らは基本的に、GraphQLを使用して公開APIのv4用のAPIを再作成しました。したがって、これを大規模に使用している実際の大企業がどのようになっているのかを確認するのに適した場所です。多くの人々は大きなAPIが実行されているが、彼らは皆にそれを公開することはありません。したがって、ページ付けはそのAPIに非常にうまく組み込まれており、これまでに作成した最初の50個のリポジトリを返すことができます。また、データ内のアイデアに基づいてレコードを返すためにカーソルベースのページ付けを使用することもできます。人々はそれにアプローチする方法通常だが、多くの技術があります最初、最後のレコードのように、位置改ページの改ページや種類をベースとカーソルがそう。

Drew： GraphQLを使用する際に知っておくべき大きな落とし穴はありますか？セイ私は私の組織のための新しいGraphQLインストールを展開する程度だけど、私たちは今後GraphQLを使用して、すべての私たちの新しいAPIエンドポイントを構築しようとしています。何を知っておくべきですか？茂みに潜んでいるものはありますか？

イブ：常にテクノロジーを駆使して、茂みに潜んでいますよね？私はGraphQLに内蔵されていませんが、あまり手間をかけずに実装することが可能なものの一つは、APIのセキュリティだと思います。たとえば、私が巨大なクエリを持っている場合、承認を得てこれについて話しましたが、誰かが巨大なネストされたクエリ、友達の友達、友達の友達、友達の友達を送信できるAPIを開くのも怖いです、チェーンのダウンとダウン。そして、あなたは基本的に、あなたはこれらの巨大なクエリでDDoS攻撃に人々を許可しています。 So there's things that you can set up on the server to limit query depth and query complexity. You can put queries on a safe list. So maybe your front ends, you know what they all are and it's not a public API. So you only want to let certain queries come over the wire to you. So I would say before rolling that out, that is definitely a possible gotcha with the GraphQL.

Drew: You do a lot of instruction and training around GraphQL, and you've co-written the O'Reilly 'animal' book with Alex Banks called Learning GraphQL. But you've got something new that you're launching early in 2021, is that right?

Eve: That's right. So I have been collaborating with egghead.io to create a full stack GraphQL video course. We're going to build an API and front end for a summer camp, so everything is summer camp themed. And yeah, we're just going to get into how to work with Apollo server, Apollo client. We will talk about scaling GraphQL APIs with Apollo Federation. We'll talk about authorization strategies and all sorts of different things. So it's just kind of collecting the things that I've learned from teaching over the past, I don't know, three or four years GraphQL and putting it into one spot.

Drew: So it's a video course that… Is it all just self-directed, you can just work your way through at your own pace?

Eve: Yeah, exactly. So it's a big hefty course so you can work through it at your own pace. 絶対。

Drew: Oh, that sounds really good. And it's graphqlworkshop.com, is that right?

Eve: Graphqlworkshop.com, exactly.

Drew: And I'm looking forward to seeing that released because I think that's something that I might need. So I've been learning all about GraphQL. What have you been learning about lately?

Eve: I've also been looking into Rust lately. So I've been building a lot of Rust Hello Worlds, and figuring out what that is. I don't know if I know what that is yet, but I have been having fun tinkering around with it.

Drew: If you dear listener, would like to hear more from Eve, you can find her on Twitter where she's @eveporcello, and you can find out about her work at moonhighway.com. Her GraphQL workshop, discover your path through the GraphQL wilderness, is coming out early in 2021 and can be found at graphqlworkshop.com. Thanks for joining us today, Eve. 別れの言葉はありますか？

Eve: Parting words, have fun with GraphQL, take the plunge, you'll enjoy it, and thanks so much for having me. それは有り難いです。