GraphQLゲートウェイを構築する：dataSourceを組み合わせたり、縫いたり、マージしたりする

コアポイント

• GraphQLゲートウェイは、従来のAPIゲートウェイとGraphQLの利点を組み合わせて、ソフトウェアエンジニアがフロントエンドの効率を維持しながら複数のデータソースからデータを取得できるようにします。
• バックエンド、つまり、フロントエンド（BFF）アーキテクチャパターンは、フロントエンドのリクエスト数を減らし、APIゲートウェイに単一のリクエストを許可することでプロセスを簡素化し、各バックエンドサービスからデータを取得し、それを組み合わせます。
• GraphQLは、効率的なデータ収集、すべてのリクエストの単一のエンドポイント、およびフロントエンドが各リクエストに必要なデータのみを選択できる柔軟なクエリなど、多くの利点をBFFに提供します。
• GraphQLゲートウェイを確立するための3つの推奨フレームワークには、Hasura、Stepzen、およびGraphWeaverが含まれます。これらのフレームワークは、複数のデータソース接続、ルーティング、バッチ処理、セキュリティ、クロスデータソースフィルタリング、スケーラビリティなど、複数の機能を提供します。

この記事では、フロントエンドの応答性を迅速に保ちながら、複数のデータソースからデータを取得する方法と、潜在的なソリューション：GraphQL Gatewayを使用する方法について説明します。

ソフトウェアエンジニアとして、私たちは皆、複数のシステムからのデータをまとめるという課題に直面しています。単一ページでも、複数のサービスからのデータをレンダリングする必要があります。

データは、CRMから金融システムまで、SaaSプラットフォームからデータベースまで、どこにでもあります。すべてのビジネスが多数のSaaSプラットフォームを購入し、それらすべての上に統一されたビジネスビューを取得することを望んでいることは避けられません。私たちはこの問題に直面し、すべてをまとめる必要があります。

GraphQLゲートウェイは、従来のAPIゲートウェイとGraphQLの利点を組み合わせています。

最初にAPIゲートウェイの利点について説明し、次にGraphQLがどのように適合するかを確認します。この記事を読み続けてください。独自のAPIゲートウェイを構築するためのフレームワークについて説明します。

APIゲートウェイの利点

ハッカーからの公共向けのAPIを保護することは、全天候型の仕事です。時間が経つにつれて、組織は、サービス指向のアーキテクチャからマイクロサービスまで、多くのAPIを作成するために進化してきました。組織は、これらのAPIをインターネット上に直接配置するのではなく、セキュリティの追加レイヤーを追加する傾向があります。これは、これらすべてのAPIよりも先にあり、データへのアクセスが常に同じ認証ルールに従うことを保証します。

これを行うためにAPIゲートウェイを使用します。

KongやApigeeなどの製品は、中央の場所から内部APIを公開します。それらは、APIキー管理、レートの制限、監視などの機能を備えたリバースプロキシとして機能します。

APIゲートウェイを使用すると、各サービスに誰と何がアクセスできるか、接続を監視し、アクセスを記録できます。

最近、アプリケーションはAPIゲートウェイと他の外部SAASプロバイダーのデータを組み合わせる必要があります。これは、古い集中化されたツール（ルールが順守されていることを確認）が定期的にバイパスされることを意味します。

会社のWebアプリケーションを構築しているとします。私たちのタスクは、ユーザープロファイルページを作成することです。ログインプロセス中に、複数のシステムからのデータを組み合わせる必要があります。

• Salesforce CRM：名や姓などの一般的な顧客データを保存します。
• 注文：最新の注文ユニットは、組織内の注文システムにあります。
• 通知サービス：通知設定と最近のメッセージは、node.jsサービスに接続されたアプリケーション固有のデータベースにあります。

下の図に示すように、データを取得するために、クライアントは3つの個別のリクエストを発行する必要があります。

上記の画像では、Webクライアントが3つの個別のAPI要求を送信し、結果をフロントエンドコードで組み合わせる必要があります。複数のリクエストを送信すると、アプリケーションのパフォーマンスに影響を与える可能性があり、このデータを組み合わせると、コードの複雑さが増すことができます。さらに、複数のアプリケーションがある場合、すべてのアプリケーションがすべてのバックエンドについて知る必要があり、サービスの単一のAPI変更により、すべてのアプリケーションの更新が発生する可能性があります。

私たちはもっとうまくやることができます。理想的には、リクエストを3から1に減らしたいと考えています。これを行うための新しいサービスを作成できます。これは、バックエンドサービスのリクエストを調整するサービスです。このアイデアには名前があります：BFFモード。

バックエンド、つまり、フロントエンド（BFF）アーキテクチャモードにより、フロントエンドは単一のリクエストを発行できます。

しかし、それはどのように機能しますか？このパターンを詳しく見てみましょう。

BFFモードの利点

BFFモードを使用して、アプリケーションはAPIゲートウェイに単一の要求を送信します。 BFFサービスは、各バックエンドサービスからデータを要求し、それを組み合わせます。最後に、データがフィルタリングされ、フロントエンドで必要なデータのみが返され、それによりネットワーク上に送信されるデータの量が減少します。

上の画像に示されているように、

スタックに追加のレイヤーを導入してリクエストを調整します。

ユーザープロファイルエンドポイントは、プロファイルページのアプリケーションで必要なデータを返します。 3つのリクエストを1つに減らすことで、以前のパフォーマンスの問題が解決しました。

しかし、私たちはまだ完了していません。

エンタープライズはモバイルアプリをリリースすることにしました。モバイルアプリにはプロファイルページもありますが、この画面ではプロファイル情報がはるかに少なくなります。

この時点で、モバイルチームには2つのオプションがあります。チームはWebチームのエンドポイントを使用できます。つまり、データをオーバーフレックすることを意味します（モバイルアプリが必要としないデータをより多く取得します）。別のオプションは、モバイルチームに独自のBFFを作成することです。

期待によると、モバイルチームは、アプリケーションに適したパフォーマンスが必要なため、独自のBFFを作成することを決定しました。

上の写真に示されているように、物事は複雑になり始めており、今では2つの新しい問題があります。

• 各チームは、作成する各アプリケーションに対して新しいBFFサービスを作成する必要があります。これにより、各チームが遅くなり、標準化が困難になります。
• 各BFFでは、安全であることを確認するために浸透テストが必要です。

これらの問題をどのように解決しますか？

各アプリケーションが必要なデータを選択できるソリューションが必要であり、すべての会社のアプリケーションで使用される単一のAPIである必要があります。

BFFが成熟するにつれて、多くの開発者は休息の代わりにGraphQLを使用しようとし始めています。

このテクノロジーがどのように役立つか見てみましょう。

bffよりもgraphqlの利点

GraphQLには、BFFにとって理想的な技術となる多くの利点があります：

• 効率的なデータ収集。 GraphQLを使用すると、クライアントは必要なデータを正確に要求できます。これにより、APIから転送されたデータを削減することでパフォーマンスが向上します。
• シングルエンドポイント。 GraphQLは、ゲートウェイを介して多くのエンドポイントを公開する代わりに、すべてのリクエストに対して単一のエンドポイントを使用します。これにより、メンテナンスとバージョンの制御の必要性が簡素化されます。
• 柔軟なクエリ。クライアントは、フィールドと関係を単一のリクエストに組み合わせることにより、クエリを構築できます。これにより、フロントエンド開発者はデータ収集を最適化し、パフォーマンスを向上させることができます。また、フロントエンドの変更の要件を変更すると、バックエンドを変更せずに異なるデータを取得するように更新できます。

フロントエンドは、各リクエストに必要なデータのみを選択できるようになりました。

2つのアプリケーションを同じGraphQLサーバーに接続して、2番目のBFFサービスの必要性を減らすことができます。

組織内のあらゆるアプリケーションに対してBFFを共有できるようになりました。また、浸透をテストする必要がある単一のエンドポイントもあります。

しかし、別の新しい問題を導入しました！ APIゲートウェイとGraphQL BFFの2つのシステムを管理する必要があります。

2つをGraphQLゲートウェイに統合した場合はどうなりますか？

次に、GraphQLゲートウェイの仕組みを見てみましょう。

graphqlゲートウェイとは何ですか？

GraphQLゲートウェイAPIゲートウェイとGraphQL APIを組み合わせて、両方のテクノロジーの最良の結果を得ます。

利点を確認しましょう：

• 開発者には、データをリクエストするための単一のAPIエンドポイントがあります。これにより、各アプリケーションが必要なデータのみを選択するため、過度または不十分なフェッチングが減少します。
• GraphQL Gatewayは、組織内の多くのアプリケーションで共有されています。これは、セキュリティリスクを単一のAPIエンドポイントに減らしたことを意味します。
• BFFがゲートウェイと統合されているため、管理および展開する必要があるサービスは1つだけです。

次の画像は、ユーザープロファイルAPIがGraphQLゲートウェイで動作する方法を示しています。

上記の画像では、クライアントはGraphQLゲートウェイに単一の要求を送信し、必要なデータを要求します。ゲートウェイは、各サービスに単一の要求を発行し、結果を組み合わせます。現在、管理して展開する必要があるサービスは1つだけです。

自分で試してみる準備ができていることを願っています。次に、GraphQLゲートウェイの構築方法を見てみましょう。

GraphQl Gateway

をビルドします

ゲートウェイフレームワークを選択するときは、いくつかの重要な機能を探す必要があります。

複数のデータソース。ゲートウェイは、データベースからSAASまでの多くのデータソースに接続する必要があります。接続を作成できるはずです。
ルート。ゲートウェイは、基礎となるサービスから直接データを要求できるはずです。
バッチ処理。同じサービスに送信された複数のクエリがバッチで送信され、リクエストの数が減ります。
安全。認証と承認は、接続されたデータに誰がアクセスできるかを制御する必要があります。
データソース全体のフィルター。クライアントが必要とするデータのオーバーゲットを避けるために、強力なフィルターを提供する必要があります。
スケーラビリティ。開発者は、ニーズを満たすためにミドルウェアまたは関数を使用してコードを拡張できる必要があります。

選択できるフレームワークはたくさんありますが、次の3つのフレームワークをさらに調査することをお勧めします。

hasura

Hasuraは、最初はGraphQLオーバーポストグレスサーバーとして、長年にわたってますます人気が高まってきました。ただし、外部システムに接続する能力が向上します。

他のサーバーからのGraphQLを組み合わせた「リモートモード」に接続できます。

この方法にはいくつかの欠点があります。まず、リモートスキーマを別のサービスで作成および管理する必要があります。このサービスは、GraphQLエンドポイントでなければなりません。これにより、2番目の問題が発生します。データソースに直接接続することはできません。

さらに、Hasuraでは、別のデータソースの値に基づいて、あるデータソースでデータをフィルタリングすることはできません。これはアカデミックに聞こえるかもしれませんが、「ABC」という名前の注文を教えてください」のようなものを表現したいことがよくあります。

これは柔軟性を提供しますが、複数のサービスを実行するための犠牲を払っています。直接接続できるオプションを見てみましょう。

stepzen

Stepzenを使用すると、GraphQL Serverからデータソースに直接接続できます。これにより、ゲートウェイを作成するために複数のサービスを実行する必要性が軽減されます。

stepzenをデータソースに接続するには、以下に示すようにGraphQLスキーマファイルを作成します。

この例では、カスタムモードを使用して、サーバーをデータベースに接続します。

あなたが好むかもしれない別のオプションがあります。これは純粋なコードアプローチです。次に見てみましょう。

<code>type Query {
  anything(message: String): JSON
  @rest (
    endpoint: "https://httpbin.org/anything"
    method: POST
    headers: [
      {name: "User-Agent", value: "StepZen"}
      {name: "X-Api-Key", value: "12345"}
    ]
    postbody: """
      {
        "user": {
          "id": "1000",
          "name": "The User"
         }
      }
    """
    )
}
</code>

graphweaver

過去数年間、私はGraphWeaverと呼ばれるオープンソース製品を開発しており、GraphQLゲートウェイとして使用できます。

データソースに直接接続し、インスタントGraphQL APIを作成します。このAPIには、作成、読み取り、更新、削除が予想されるすべてのCRUD操作が含まれています。フィルター、ソート、ページングのパラメーターを自動的に生成し、時間を節約します。完全な柔軟性のために、コードを使用して組み込み操作を拡張できます。

GraphWeaverは、PostgresやMySQLなどのデータベースや、XeroやContentfulなどのSaaSプロバイダー用のデータコネクタを箱から出して提供しています。

変更またはデータソースへの接続には、タイプスクリプトコードの作成が含まれ、完全なカスタマイズを行うことができます。

独自のGraphQL APIの作成に興味がある場合は、GraphWeaver GitHubコードをチェックすることを強くお勧めします。

結論

この記事では、現在のAPIゲートウェイとBFFパターンを単一のGraphQLゲートウェイに置き換える方法を検討します。

APIゲートウェイの利点と、組織がそれらを使用する理由を調べました。バージョン化、レート制限、およびアクセス管理がいくつかの理由です。

また、BFFパターンと、フロントエンドアプリケーションのAPIリクエストの調整方法についても調べました。

最後に、GraphQLとそれがBFFにとって有益な手法である理由を調べました。

一日の終わりに、これによりGraphQLゲートウェイを作成するようになり、3つのオプションを調べて、Hasura、Stepzen、および私が開発している製品のGraphWeaver製品を作成しました。

この記事で、自分でgraphqlゲートウェイを使用してみてください。できればgraphweaverを試すことを検討してください。

GraphQl Gateway FAQ（FAQ）

GraphQLゲートウェイの主な目的は何ですか？

GraphQLゲートウェイは、すべてのGRAPHQL操作の単一のエントリポイントとして機能します。リクエストを対応するサービスにルーティングし、応答を集約し、クライアントに送り返す責任があります。これにより、単一の場所から複数のGraphQLパターンとサービスを管理できるため、アプリケーションがよりスケーラブルでメンテナンスが簡単になります。

GraphQLゲートウェイと従来のAPIゲートウェイの違いはどうですか？

従来のAPIゲートウェイは、安らかなAPIを処理するように設計されており、その動作モードはGraphQLの動作モードとは異なります。一方、GraphQLゲートウェイは、GraphQL操作を処理するように特別に設計されています。複数のGraphQLパターンを1つに組み合わせることができるパターンステッチやマージなどの機能を提供します。これは、従来のAPIゲートウェイができないことです。

GraphQLゲートウェイのパターンスプライシングは何ですか？

モードステッチは、複数のGraphQLパターンを1つに組み合わせることができるGraphQLゲートウェイの機能です。これは、複数のサービスがあり、それぞれに独自のスキーマがあり、単一のAPIとしてそれらを公開する場合に特に便利です。パターンステッチは、パターンを統合し、競合を解決し、クライアントにシームレスなエクスペリエンスを提供する責任があります。

GraphQLゲートウェイはパフォーマンスをどのように改善しますか？

GraphQLゲートウェイは、クライアントとサーバー間の往復の数を減らすことにより、パフォーマンスを大幅に改善できます。異なるサービスに複数のリクエストを行う代わりに、クライアントはGraphQLゲートウェイに単一のリクエストを行うだけで、リクエストを対応するサービスにルーティングし、応答を集約し、クライアントに送り返します。これにより、ネットワークの遅延が減少し、全体的なパフォーマンスが向上します。

マイクロサービスでGraphQLゲートウェイを使用できますか？

はい、GraphQLゲートウェイは、マイクロサービスアーキテクチャに特に適しています。各マイクロサービスは独自のGraphQLパターンを持つことができ、ゲートウェイは一緒にスプライスして統一されたAPIを提供できます。これにより、クライアントに一貫したインターフェイスを提供しながら、マイクロサービスを独立して管理および拡大することができます。

GraphQLゲートウェイはすべてのプログラミング言語と互換性がありますか？

GraphQLゲートウェイは言語がないため、GraphQLをサポートするプログラミング言語で使用できます。これには、JavaScript、Python、Ruby、Javaなどの一般的な言語が含まれます。

GraphQLゲートウェイはエラーをどのように処理しますか？

GraphQL Gatewayは、強力なエラー処理機能を提供します。サービスのいずれかでエラーが発生した場合、ゲートウェイは、どのサービスがエラーを引き起こし、どのエラーが発生したかについての情報を含む、クライアントに詳細なエラーメッセージを返します。これにより、診断と修正の問題が容易になります。

サーバーレスアーキテクチャでGraphQLゲートウェイを使用できますか？

はい、GraphQLゲートウェイはサーバーレスアーキテクチャと互換性があります。 Gatewayをサーバーレス関数として展開できます。これにより、サーバーレスコンピューティングのスケーラビリティと費用対効果を活用できます。

GraphQLゲートウェイはセキュリティをどのように処理しますか？

GraphQL Gatewayは、認証と承認、レートの制限、要求の確認など、さまざまなセキュリティ機能を提供します。これらの機能は、不正アクセスや虐待からサービスを保護するのに役立ちます。

既存のRESTFUL APIでGraphQLゲートウェイを使用できますか？

はい、既存のRESTFUL APIでGraphQLゲートウェイを使用できます。 Gatewaysは、Restful APIをGraphQLパターンでラップすることができ、既存のAPIを使用しながらGraphQLを利用できるようにします。

以上がGraphQLゲートウェイを構築する：dataSourceを組み合わせたり、縫いたり、マージしたりするの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。