Product-apim: graphqlのサポート

+1

+1

+1

+1

+1

+1

：+1：

こんにちは@YannickB 、

これを持ってきてくれてありがとう。 これをロードマップに追加したいと思います。

私はGraphQLをあまり使用していないため、要件の正確な範囲を理解するのに問題があります。 わかりやすくするために、例を使用して現在の機能の正確な制限を説明できますか？ 基本的に、Apolloサーバーを介して公開されるものと、今日API Gatewayを介してこれを公開する方法と、APIGatewayを介して公開する理想的な方法を比較します。

ありがとう、
ヌワン。

+1

こんにちは@nuwand 、

まず免責事項として、チケットを開いたとしても、この機能がどのように機能するかを説明するのに最適な人物かどうかはわかりません。 私を、GraphQLやAPI Gatewayなどの非常に優れたソフトウェアアーキテクチャを構築するために勉強している人だと考えてください。これを勉強していると、今日の市場にあるAPIGatewayはGraphQLを完全にサポートするように設計されていないことがわかりました。 したがって、現時点では本番環境での実際のユースケースはありませんが、できる限りサポートします。

説明する最良の方法が例になることに同意するので、ここにあります：

製品と請求書の2つのオブジェクトにCRUD関数を提供するAPIがあるとします。

Rest APIを使用すると、http ：//myapi.com/api/productとhttp://myapi.com/api/invoiceの2つのエンドポイントを使用してから、GET / POST / PUT / DELETE操作を実行します。それらの上に。
WSO2では、各エンドポイントを個別に構成できます。1つは製品用、もう1つは請求書用です。次に、WSO2が提供するセキュリティ/スロットリング/現金化などの機能を個別に管理するために、各エンドポイントに特定の構成を指定できます。

しかし、GraphQL APIを提供している場合、現在、はるかに制限されています。 これは、両方のオブジェクトが同じエンドポイントhttp://myapi.com/graphqlでアクセスできるためです。 そして、いくつかのエンドポイントhttp://myapi.com/graphql/productとhttp://myapi.com/graphql/invoiceを作成する方法はありません。これは、GraphQLのベストプラクティスと完全にアンチパターンであり、ほとんどのエンドポイントを作成します。動作を停止するためのエコシステム内のツール。 さらに、すべてのHTTP操作はPOSTであると思います。

したがって、例として、GraphQLエンドポイントでこれらのリクエストを実行したい場合があります。

query {
  product(id: 1) {
    id
    name
  }
}

mutation {
  createInvoice(data: {
    'customerID': 1
    'productID': 1
    'price': 20
  }) {
    id
    number
    total
  }
}

最初のリクエストは指定された製品の情報を照会し、2番目のリクエストはこの製品の請求書を作成します。 両方のクエリはhttp://myapi.com/graphqlエンドポイントで実行されます。

したがって、WSO2ゲートウェイの現在の状態では、エンドポイントごとの構成のみを許可します。たとえば、 http：//myapi.com/graphqlエンドポイントを構成することにより、createInvoiceへの呼び出しごとに0.01セントで収益化する場合は、その後、製品への呼び出しも0.01セントで現金化されます。 RESTを使用すると、POSTで0.01centをhttp://myapi.com/api/invoiceに構成するだけで、それだけになります。
これが私のポイントを理解するのに十分であることを願っています。これは単純な例ですが、他にもたくさん見つけることができます。現在の状態では、構成の柔軟性がないため、GraphQLでゲートウェイ機能を使用することはできません。 そして、それはあなたのせいではありません。市場に出回っている他のすべてのAPIGatewayにも同じ問題があると思います。

そのため、IMHOのソリューションでは、WSO2構成をエンドポイントだけでなくGraphQL関数にもアタッチできます。 これは技術的な課題になると思いますが、現在GraphQLはAPIゲートウェイで機能しないか、非常に機能が低下しているため、市場では間違いなくこれが必要です。

この提案はかなりの注目を集めたようです。 この問題をフォローしている人には、ユースケースとWSO2がこの機能をどのように設計するかについての情報を提供することをお勧めします。 状況を説明するために最善を尽くしたことを願っていますが、これを適切に実装するには、実際の例が必要になると思います。

よろしくお願いします、
ヤニック

一時的な解決策として、API Gatewayへの完全なサポートを待っている間にサービスディレクトリとして使用するために、少なくともWSO2-AMgraphqlエンドポイントにインポートする可能性があると便利です。

こんにちは@YannickB 、

説明ありがとうございます。 許してください、しかし私はまだエンドポイントの制限を理解しようとしています。 エンドポイントに関してAPIManagerが持つ機能について説明します。そうすれば、制限を特定できるかもしれません。

http://myapi.com/api/invoiceとhttp://myapi.com/api/productの2つのエンドポイントがあるとします。 両方のエンドポイントが同じホスト（myapi.com）にあるように見える、あなたが行ったのと同じ例を使用していることに注意してください。 両方のエンドポイントをプロキシするためにAPIManagerに単一のAPIを用意する必要がある場合は、2つのリソースを作成する必要があります。1つはPOST / invoiceとして、もう1つはPOST / productとして作成し、 http：//myapi.com/を指定します。それぞれのAPIのエンドポイントとしての

POST http://gateway.myqpi.com/graphql/1.0.0/invoice-> POST http://myqpi.com/api/invoice
POST http://gateway.myqpi.com/graphql/1.0.0/product-> POST http://myqpi.com/api/product

両方のエンドポイントをプロキシするために作成する必要があるAPI（/graphql/1.0.0）は1つだけであることに注意してください。 あなたがすでに知っていることを繰り返している場合は申し訳ありませんが:)しかし、問題をよりよく理解するのに役立つGraphQLを使用することを不可能にする、マッピングへのリソースの制限を特定できれば。

ありがとう、
ヌワン。

nuwand、私はあなたより技術的ではありません。 しかし、APIM / Identityサーバーに関する私の理解では、APIレベルでAPIの管理（セキュリティ、スロットリング、... ..）を定義しています。 GraphQLは、「メタ」言語を介してAPIを組み合わせた一種の「スーパー」言語です。 私が興味を持っているのは、GraphQLの概念とWS02APIMの概念がどのように一致しているかを理解することです。 両方の概念が統合されるかどうか。 オフコースでは、それ自体がすべてを管理するGraphQL als 1リソースを検討できますが、すべての「レガシー」サービスにgraphqlサーバー経由でアクセスできる場合は、WS02の値が制限されます。

+1

GraphQLでは、実際にはエンドポイントが1つしかないため、myapi.com / graphql / invoiceやgraphql / productのようなものはなく、endointは「myapi.com/graphql」であり、それ以降は何もありません。 これは、各クエリとミューテーションで文字通り同じURLであり、操作はリクエストの本文内で定義されています。

一部のAPI管理機能では、リクエスト本文のイントロスペクション、graphqlスキーマの知識などが必要になります。これは短期的には実現不可能であると想定しましょう。WSO2はそれ自体でGraphQLサーバー/ゲートウェイになる（または統合する）必要があります。

代わりに、どのAPI管理機能が可能であるかに焦点を当てる必要があります。 WSO2と実際のGraphQLサーバー/ゲートウェイの間で、たとえばヘッダーを設定するなどして、協力する必要があると思います。 収益化の例：GraphQLサーバーはクエリの複雑さを計算し、この情報をHTTPヘッダーとして応答に追加します。ここで、WSO2はこの値を価格に変換します。 同様に、監視の場合、GraphQLサーバーは、JSON形式のクエリをRESTのような疑似エンドポイント（のリスト）に「変換」できます。これは、WSO2が応答ヘッダーから読み取って監視情報を更新します。 セキュリティについても同じことができます。おそらく2つのフェーズです。最初にGraphQLサーバーにクエリをRESTのようなエンドポイントに変換するように依頼し、WSO2はクエリを渡すかどうかを決定し、クエリを実際のエンドポイントに転送します。

私はWSO2にまったく慣れておらず、ほとんどのドキュメントを読んでいないので、おそらくこれらの機能はすでにWSO2に含まれています（より具体的には、通常は正確なRESTエンドポイントURIから派生するWSO2の機能について、同じ機能が可能かどうか別の方法で派生する（たとえば、ヘッダー値またはWSO2自体に対するその他のAPI））。 これらのWSO2固有の機能をサポートするには、GraphQLサーバーを変更する必要がある可能性があります。 問題は、どのような低ぶら下がっている果物から始めることができるかということです。

（もちろん、WSO2がGraphQLに大きなコミットメントをすることを望んでいます...しかし、私たちは何かを始める必要がありますよね？）

素晴らしいフィードバック、私は同じように感じます;）

Op di 6nov。 2018 om 12:06 schreef [email protected] ：

GraphQLでは、実際にはエンドポイントは1つしかないため、そのようなものはありません。
myapi.com/graphql/invoiceおよびgraphql / productのように、endointは
「myapi.com/graphql」だけで、その後は何もありません。 それは文字通りです
クエリとミューテーションごとに同じURLで、内部で操作が定義されています
リクエストの本文。

一部のAPI管理機能では、
リクエスト本文、graphqlスキーマの知識など。これを想定しましょう
短期的には実現可能ではありません：WSO2はほぼGraphQLになるはずです
サーバー/ゲートウェイ自体（または統合）。

代わりに、可能なAPI管理機能に焦点を当てる必要があります。
WSO2と実際のGraphQLの間の協力が必要だと思います
サーバー/ゲートウェイ。たとえば、ヘッダーを設定します。 例：現金化：
GraphQLサーバーはクエリの複雑さを計算でき、これを追加します
WSO2がこれを変換する応答へのHTTPヘッダーとしての情報
価格に価値を。 同様に、モニタリングの場合、GraphQLサーバーは次のことができます。
JSON形式のクエリをRESTのような（リスト）に「変換」します
WSO2が応答ヘッダーから読み取って更新する疑似エンドポイント
監視情報。 同じことがセキュリティのために、おそらく2で行うことができます
フェーズ：最初に、GraphQLサーバーにクエリをRESTのようなものに変換するように依頼します
エンドポイント、WSO2は合格するかどうかを決定し、クエリを実際の
終点。

私はWSO2にまったく慣れておらず、ほとんどのドキュメントを読んでいないので、
多分これらの機能はすでにWSO2にあります（より具体的には：
通常、正確なRESTエンドポイントから派生するWSO2の機能
URI、同じ機能を別の方法で導出できるかどうか
（たとえば、WSO2自体へのヘッダー値またはその他のAPI））。 の可能性が高い
これらのWSO2固有をサポートするには、GraphQLサーバーを変更する必要があります
特徴。 問題は、どのような低ぶら下がっている果物から始めることができるかということです。

（もちろん、WSO2がGraphQLに大きなコミットメントをすることを望んでいます...
しかし、私たちは何かを始める必要がありますよね？）

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/wso2/product-apim/issues/3184#issuecomment-436215537 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/Ad4tuNmWvNcpkc1Nk5y46DljcQeM9RPwks5usW0kgaJpZM4TLf2Q
。

-
Bart Van Vlierberghe

こんにちは、
ApolloServerのドキュメントの抜粋は次のとおりです。
_ "HTTPヘッダーのように、承認が組み込まれているREST APIを使用している場合は、もう1つのオプションがあります。GraphQLレイヤー（リゾルバー/モデル）で認証または承認作業を行うのではなく、可能です。ヘッダーまたはCookieをRESTエンドポイントに渡すだけで、RESTエンドポイントに機能させることができます。 "_
APIキーがgraphqlクエリに含まれるすべてのエンドポイントで同じである場合、それでうまくいく可能性があります。
この「回避策」（ApolloサーバーをAPI-Mの前​​に置く）について何か考えはありますか？

要件分析

• GraphQLは、RESTの代替となるFacebookによって開発されています。 これは、特定のユーザーがAPIから必要なデータを正確に指定できるAPIのクエリ言語です。
• Swagger定義（Open API仕様）を使用してRESTAPIを設計できることはわかっています。 しかし、GraphQLでは、スキーマ定義言語（SDL）を使用してGraphQLAPIのスキーマを作成できます。
• GraphQL APIを呼び出すということは、GraphQLクエリを使用してデータをフェッチし、GraphQLミューテーションを使用してデータを書き込むことを意味します。
• ここでの要件は、GraphQL APIを作成して公開し、https / httpを介して呼び出すために、WSO2APIMからのサポートを提供することです。

推奨されるアプローチ

• GraphQL APIを公開するときは、定義を構成するスキーマファイルをアップロードするようにユーザー（公開者）に要求します。 次に、ユーザーは名前、バージョン、コンテキストなどのAPIに関する詳細を入力できます。ただし、APIを作成するときに、GET、POSTメソッドのリソースを作成するように求められることはありません。
  

• 次に、[実装]タブで、ユーザーが選択した場合、

  • APIを管理する

    • エンドポイントタイプは、 HTTP / RESTエンドポイントに自動的に設定する必要があります。 （ユーザーはこれを変更することができてはなりません）
    • ユーザーは、通常どおりエンドポイント（本番環境とサンドボックス）を変更できる必要があります。
    • 他のフィールドは同じままである必要があります。
      

  • プロトタイプAPI

    • インライン実装メソッドでは、次のスクリーンショットに示すように、2つのGETメソッドとPOSTメソッドを自動的に作成して表示する必要があります。
      

• [APIの管理]オプションを選択した場合は、 [管理]タブで設定を行う必要があります。

  • ここでも同じ手順に従う必要があります。
  • 特にインラインプロトタイプメソッドの場合と同様に、次のスクリーンショットのように、2つのGETメソッドとPOSTメソッドを自動的に作成して表示する必要があります。
    

• APIが公開またはプロトタイプ化された後

  • APIは、APIストアでGraphQLAPIとしてラベル付けする必要があります。
  • コンシューマーは、APIストアを介してそのAPIのスキーマファイルをダウンロードする機能を持っている必要があります。

素晴らしく見える

@wasuradananjithまた、GraphQL APIがストアでどのように表示されるかを投稿できますか？ おそらくスキーマを使用して、APIポータルでクエリを使用できますか？

少なくともApolloは、GraphQLデータリクエストでのGETの使用をサポートしています。

こんにちは、みんな、

WSO2 APIM3.0.0リリースに関連するGraphqlサポートの情報とPRを見つけてください。 新しいReactベースのUIでWSO2APIM 3.0.0をリリースする予定なので、新しいUIのスクリーンショットを以下に追加しました。

APIパブリッシャー
説明：
API作成者がgraphQLスキーマをAPIパブリッシャーにアップロードすると、クエリおよびミューテーション操作がパブリッシャーポータルに一覧表示されます。 次に、スコープの定義、ポリシーの調整、操作に対するセキュリティの有効化/無効化を許可します。

出版社での機能。

1. GraphQLSDLスキーマをインポートしてGraphQLAPIを作成します
2. スキーマを検証し、スキーマ定義からその操作を抽出します
3. パブリッシャーでSDLスキーマを取得/インポート/ダウンロードします。
4. リソースの代わりに操作を表示します
5. スロットリング、スコープ、操作に対するセキュリティを追加/更新します
6. APIリストページで「GRAPHQL」というラベルの付いたgraphQLAPIを表示する

APIストア
APIがパブリッシャーユーザーによって公開されると、SDLスキーマでのすべての操作が開発者ポータルに入力され、スキーマファイルもダウンロードできるようになります。 開発者は、GETおよびPOSTリクエストタイプでTryoutコンソールを使用して操作をテストできます。

ストアでの機能。

1. APIリストページで「GRAPHQL」というラベルの付いたgraphQLAPIを表示する
2. 特定のAPIの操作を表示する
3. SDLスキーマ取得スキーマをダウンロードできます
4. APIを呼び出すためのGETとPOSTを開発者コンソールに提供します

ビューのスクリーンショット

1. GrpahQLAPIページを作成する
   

1. スキーマページのアップロード
   

2. [次へ]をクリックしてフォームに入力し、詳細を入力します
   

3. GraphQLAPIの概要ページを作成しました
   

4. GraphQLAPI操作ビュー
   

5. アップロードされたスキーマ定義
   

6. スコープの追加/更新、スロットリング、セキュリティ
   

7. 店舗運営概要
   

8. スキーマのダウンロード
   

9. 開発者コンソール
   

GraphqlAPIの呼び出し時間

1. 承認-APICreatorは、パブリッシャーでの操作ごとにスコープを追加できます
   APPユーザーがクエリ/ミューテーション（読み取り専用/読み取り/書き込み）操作でgraphQL APIを呼び出すと、APIゲートウェイはペイロードに含まれている操作を識別し、ユーザーのトークンスコープに従ってそれらを照合します。 ペイロードに複数のスコープを持つ複数の操作が含まれている場合、トークンには少なくとも操作スコープの結合が含まれている必要があります。
   例：-クエリに次が含まれている場合を考えてみましょう（操作A-スコープ1、操作B-スコープ2）
   クエリを実行するユーザーのトークンには、両方のスコープ（scope1とscope2）が必要です。

2. セキュリティ-APICreatorは、パブリッシャーでの操作ごとにセキュリティを有効/無効にできます。
   クエリリクエストに複数のオペレーション名が含まれている場合、セキュリティはオペレーションセキュリティの結合と見なされてきました。 1つの操作でセキュリティが有効になっている場合は、リクエスト全体のセキュリティをサポートします。

3. スロットリング-APICreatorは、パブリッシャーでの操作ごとにスロットリングポリシーを追加できます。
   クエリリクエストに複数の操作名が含まれている場合、操作ごとにスロットルポリシーが適用されます。 要求の1つの操作名がそのポリシーに従って抑制されている場合、抑制された操作の場合、要求全体が抑制されます。

PRはhttps://github.com/wso2/carbon-apimgt/pull/6784にあります。

• このレベルでは、クエリの検査と分析のサポート、GraphQLエンドポイントのAPI MicroGatewayのサポート、インバウンドエンドポイント（WebソケットAPI）でのGraphqlサブスクリプションのサポート、操作呼び出しの数を確認するためのGraphqlAPIの追加ウィジェットの組み込みは行いません。オペレーションタイプなどに基づいています。したがって、将来のロードマップに関連するサポートを追加するために、新しい問題が開かれています。

1. https://github.com/wso2/product-apim/issues/5432
2. https://github.com/wso2/product-apim/issues/5431
3. https://github.com/wso2/product-microgateway/issues/773
4. https://github.com/wso2/analytics-solutions/issues/310

これに関するあなたの考えと貴重なインプットに感謝します。

ありがとう！

こんにちは、みんな、

WSO2 APIM3.0.0リリースに関連するGraphqlサポートの情報とPRを見つけてください。 新しいReactベースのUIでWSO2APIM 3.0.0をリリースする予定なので、新しいUIのスクリーンショットを以下に追加しました。

APIパブリッシャー
説明：
API作成者がgraphQLスキーマをAPIパブリッシャーにアップロードすると、クエリおよびミューテーション操作がパブリッシャーポータルに一覧表示されます。 次に、スコープの定義、ポリシーの調整、操作に対するセキュリティの有効化/無効化を許可します。

出版社での機能。

1. Create a GraphQL APIs by importing GraphQL SDL schema

2. Validate the schema and extract its operations from the schema definition

3. Retrieve/Import/Download  SDL schema at the publisher.

4. Shows operations instead of resources

5. Add/Update throttling,scopes,security against operations

6. View graphQL APIs labeling 'GRAPHQL' at API Listing Page

APIストア
APIがパブリッシャーユーザーによって公開されると、SDLスキーマでのすべての操作が開発者ポータルに入力され、スキーマファイルもダウンロードできるようになります。 開発者は、GETおよびPOSTリクエストタイプでTryoutコンソールを使用して操作をテストできます。

ストアでの機能。

1. View graphQL APIs labeling 'GRAPHQL' at API Listing Page

2. View operations for particular API

3. Able to download SDL schema retrieving schema

4. Provide developer console with GET and POST to invoke the API

ビューのスクリーンショット

1. Create GrpahQL API page

1. Upload schema page

1. Click next and populate a form to fill details

1. Created GraphQL API overview page

1. GraphQL API operation view

1. Uploaded schema definition

1. Add/Update scopes,throttling,security

1. Store operation overview

1. Schema download

1. Developer Console

GraphqlAPIの呼び出し時間

1. Authorization - API Creator can add scopes per operations at the publisher
   When the APP user invokes the graphQL API with query/mutation (read-only/ read-write) operation, API gateway will identify which operations are containing in the payload and match them according to the token scope of the user. If the payload contains multiple operations with multiple scopes, the token should have at least a union of the operation scopes.
   Eg:- Let's say when a query contains, (operation A  - scope 1, operation B -  scope 2)
   the token of the user who is going to execute the query should have both scopes (scope1 and scope2)

2. Security - API Creator can enable/disable security per operations at the publisher.
   When a query request comes with multiple operation names, security has been considered as the union of the operations security. If one operation has been enabled the security, we support security for whole request.

3. Throttling - API Creator can add throttling policy per operations at the publisher.
   When a query request comes with multiple operation names, throttle policies will apply per operation. If one operation name of the request has been throttled out according to its policy, the whole request is going to be throttled out in the case of throttled operation.

PRはwso2 / carbon-apimgt＃6784にあります。

* At this level, we are not going to support on inspecting and analyzing queries, support API MicroGateway for GraphQL endpoints, support Graphql subscriptions with the inbound endpoints(Web socket APIs), Include an extra widget for Graphql APIs to see the count of operation invocation based on operation types, etc. Therefore, new issues have been opened to add relevant support for our future roadmap.


1. #5432

2. #5431

3. [wso2/product-microgateway#773](https://github.com/wso2/product-microgateway/issues/773)

4. [wso2/analytics-solutions#310](https://github.com/wso2/analytics-solutions/issues/310)

これに関するあなたの考えと貴重なインプットに感謝します。

ありがとう！

こんにちは@HiranyaKavishani 、
このサポートにより、wso apimを介した既存のAPIに対して通常行うように、APIMを介した既存のGraphQL APIの公開が導入されますか？

また、機能をテストするためのベータ/アルファリリースはありますか？

ありがとう ！

こんにちは@arvindkannan 、

既存のGraphqlAPIの場合、他のAPIと比較するとgraphqlのサポートが異なるため、APIを再作成して再公開する必要があります。 ただし、そうする場合は、既存のトークンと既存のURLが変更されないようにする必要があります。これは、既存の顧客に影響を与えるためです。

この機能は、10月にリリースされるAPIM3.0.0で利用できるようになります。

ありがとう！

このサポートはAPIM3.0.0ベータ版で利用可能であるため、問題を解決してください