Product-apim: Unterstützung für graphql

+1

+1

+1

+1

+1

+1

:+1:

Hallo @YannickB ,

Danke, dass du das angesprochen hast. Wir möchten dies in unsere Roadmap aufnehmen.

Ich habe GraphQL nicht viel verwendet und habe daher einige Probleme, den genauen Umfang der Anforderung zu verstehen. Könnten Sie zur Verdeutlichung die genauen Einschränkungen der aktuellen Funktionalität vielleicht anhand eines Beispiels erläutern? Was wird im Wesentlichen über den Apollo-Server offengelegt und wie müssten Sie dies heute über das API-Gateway offenlegen, im Vergleich zu dem, was der ideale Weg gewesen wäre, es über das API-Gateway offenzulegen?

Danke,
Nuwan.

+1

Hallo @nuwand ,

Zunächst als Haftungsausschluss, selbst wenn ich das Ticket geöffnet habe, bin ich mir nicht sicher, ob ich die beste Person bin, um zu beschreiben, wie die Funktion funktionieren sollte. Stellen Sie sich mich als jemanden vor, der studiert, um eine wirklich gute Softwarearchitektur aufzubauen, also Dinge wie GraphQL und API Gateway, und während ich dies studierte, wurde mir klar, dass kein API Gateway auf dem heutigen Markt dafür ausgelegt ist, GraphQL vollständig zu unterstützen. Daher habe ich noch keinen wirklichen Anwendungsfall in der Produktion, aber ich werde mein Bestes tun, um zu helfen.

Ich stimme zu, dass der beste Weg, dies zu erklären, ein Beispiel sein wird, also hier ist es:

Angenommen, Sie haben eine API, die CRUD-Funktionen für zwei Objekte bereitstellt, Produkt und Rechnung.

Mit einer Rest-API müssten Sie zwei Endpunkte verwenden, http://myapi.com/api/product und http://myapi.com/api/invoice , und Sie führen dann GET/POST/PUT/DELETE-Vorgänge aus auf sie.
In WSO2 können Sie jeden Endpunkt unabhängig konfigurieren, einen für das Produkt und einen für die Rechnung, und dann jedem von ihnen eine spezifische Konfiguration zuweisen, um die von WSO2 bereitgestellten Sicherheits-/Drosselungs-/Monetarisierungsfunktionen usw. unabhängig zu verwalten.

Aber wenn wir eine GraphQL-API bereitstellen, sind wir derzeit viel viel eingeschränkter. Dies liegt daran, dass auf beide Objekte über denselben Endpunkt http://myapi.com/graphql zugegriffen werden kann. Und es gibt keine Möglichkeit, mehrere Endpunkte zu erstellen http://myapi.com/graphql/product und http://myapi.com/graphql/invoice , dies ist völlig Anti-Pattern mit den Best Practices von GraphQL und wird die meisten machen Werkzeuge in seinem Ökosystem, um nicht mehr zu funktionieren. Außerdem glaube ich, dass alle HTTP-Operationen POST sind.

Als Beispiel möchten wir vielleicht diese Anfragen auf dem GraphQL-Endpunkt ausführen:

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

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

Die erste Anfrage fragt die Informationen des angegebenen Produkts ab, die zweite erstellt eine Rechnung für dieses Produkt. Beide Abfragen werden auf dem Endpunkt http://myapi.com/graphql ausgeführt.

Also mit dem aktuellen Stand von WSO2 Gateway, das, wenn ich mich nicht irre, nur die Konfiguration pro Endpunkt zulässt, wenn ich zum Beispiel jeden Aufruf von createInvoice mit 0,01 Cent monetarisieren möchte, indem ich den Endpunkt http://myapi.com/graphql konfiguriere, dann wird auch der Call-to-Product mit 0,01 Cent monetarisiert. Mit REST würden Sie einfach die 0,01 Cent für http://myapi.com/api/invoice auf POST konfigurieren und das wäre alles.
Ich hoffe, das reicht aus, um meinen Standpunkt zu verstehen, dies ist ein einfaches Beispiel, aber wir können viele andere finden, zum gegenwärtigen Zeitpunkt ist es aufgrund mangelnder Flexibilität bei der Konfiguration unmöglich, die Gateway-Funktionen mit GraphQL zu verwenden. Und es ist nicht Ihre Schuld, ich glaube, alle anderen API-Gateways auf dem Markt haben das gleiche Problem.

Die Lösung ermöglicht es IMHO also, die WSO2-Konfiguration nicht nur an Endpunkte, sondern auch an GraphQL-Funktionen anzuhängen. Dies mag sich als technische Herausforderung erweisen, denke ich, aber es gibt definitiv einen Bedarf dafür auf dem Markt, da GraphQL derzeit einfach nicht mit API-Gateways funktioniert, oder auf eine sehr herabgesetzte Weise.

Es scheint, dass dieser Vorschlag ziemlich viel Aufmerksamkeit erregt hat. An die Leute, die diese Ausgabe verfolgen, lade ich Sie ein, einige Informationen über Ihren Anwendungsfall zu geben und wie WSO2 diese Funktion entwerfen sollte. Ich hoffe, ich habe mein Bestes getan, um die Situation zu beschreiben, aber ich glaube, sie brauchen ein echtes Beispiel, um dies richtig umzusetzen.

Mit freundlichen Grüßen,
Yannick

Als vorübergehende Lösung wäre es großartig, zumindest die Möglichkeit zu haben, WSO2-AM-Graphql-Endpunkte zu importieren, um sie als Dienstverzeichnis zu verwenden, während auf eine vollständige Unterstützung im API-Gateway gewartet wird

Hallo @YannickB ,

Danke für deine Erklärung. Verzeihen Sie mir, aber ich versuche immer noch, die Einschränkungen mit den Endpunkten herauszufinden. Lassen Sie mich die Fähigkeit von API Manager in Bezug auf Endpunkte erläutern, und dann können Sie vielleicht die Einschränkung lokalisieren.

Angenommen, Sie haben zwei Endpunkte als http://myapi.com/api/invoice und http://myapi.com/api/product. Beachten Sie, dass ich dasselbe Beispiel wie Sie verwende, bei dem sich beide Endpunkte auf demselben Host zu befinden scheinen (myapi.com). Wenn Sie eine einzelne API auf API Manager als Proxy für beide Endpunkte benötigen, müssen Sie zwei Ressourcen erstellen, eine als POST /invoice und die andere als POST /product, und http://myapi.com/ angeben.

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

Beachten Sie, dass Sie nur 1 API (/graphql/1.0.0) erstellen müssen, um beide Endpunkte als Proxy zu verwenden. Es tut mir leid, wenn ich etwas wiederhole, das Sie bereits wissen :), aber wenn Sie die Beschränkung unserer Ressource auf das Mapping aufzeigen könnten, die es unmöglich macht, GraphQL zu verwenden, würde mir das helfen, das Problem besser zu verstehen.

Danke,
Nuwan.

nuwand, ich bin weniger technisch als du. Aber nach meinem Verständnis definieren wir mit einem APIM / Identitätsserver auf API-Ebene die Verwaltung einer API (Sicherheit, Drosselung, ... ..) . GraphQL ist eine Art „Super“-Sprache, die APIs über eine „Meta“-Sprache kombiniert. Was mich interessieren würde, ist zu verstehen, wie die Konzepte von GraphQL und die Konzepte eines WS02-APIM übereinstimmen. und ob beide Konzepte integriert werden. Natürlich können Sie GraphQL als eine Ressource betrachten, die selbst alles verwaltet .... aber dann ist der Wert von WS02 begrenzt, wenn alle meine "alten" Dienste über den Graphql-Server zugänglich sind.

+1

Bei GraphQL gibt es wirklich nur einen einzigen Endpunkt, also gibt es so etwas wie myapi.com/graphql/invoice und graphql/product nicht, der Endpunkt ist nur „myapi.com/graphql“ und danach nichts mehr. Es ist buchstäblich dieselbe URL für jede Abfrage und Mutation, wobei die Operationen im Hauptteil der Anfrage definiert sind.

Einige API-Verwaltungsfunktionen würden dann eine Selbstprüfung des Anforderungstexts, Kenntnisse des Graphql-Schemas usw. erfordern. Nehmen wir an, dass dies kurzfristig _nicht_ machbar ist: WSO2 sollte fast selbst zu einem GraphQL-Server/Gateway werden (oder einen integrieren).

Stattdessen sollten wir uns darauf konzentrieren, welche API-Verwaltungsfunktionen möglich sind. Ich denke, wir brauchen eine Zusammenarbeit zwischen WSO2 und dem eigentlichen GraphQL-Server/Gateway, zB durch das Setzen von Headern. Zum Beispiel Monetarisierung: Der GraphQL-Server kann die Komplexität der Abfrage berechnen und diese Informationen als HTTP-Header zur Antwort hinzufügen, wobei WSO2 diesen Wert in einen Preis übersetzt. In ähnlicher Weise kann der GraphQL-Server für die Überwachung die JSON-förmige Abfrage in (eine Liste von) Rest-ähnlichen Pseudo-Endpunkten „konvertieren“, die WSO2 aus dem Antwortheader liest, um die Überwachungsinformationen zu aktualisieren. Dasselbe kann aus Sicherheitsgründen getan werden, vielleicht in zwei Phasen: 1. Bitten Sie den GraphQL-Server, die Abfrage in Rest-ähnliche Endpunkte umzuwandeln, WSO2 entscheidet, ob sie bestehen oder nicht, und leitet die Abfrage an den tatsächlichen Endpunkt weiter.

Ich bin völlig neu bei WSO2 und habe den größten Teil der Dokumentation nicht gelesen, also sind diese Funktionen möglicherweise bereits in WSO2 enthalten (genauer gesagt: für jede Funktionalität von WSO2, die normalerweise von der genauen REST-Endpunkt-URI abgeleitet wird, ob dieselbe Funktionalität kann auf alternative Weise abgeleitet werden (z. B. ein Header-Wert oder eine andere API zu WSO2 selbst)). Es ist wahrscheinlich, dass ein GraphQL-Server modifiziert werden muss, um diese WSO2-spezifischen Funktionen zu unterstützen. Die Frage ist: Mit welchen niedrig hängenden Früchten können wir beginnen?

(Natürlich würde ich gerne sehen, dass WSO2 sich stark für GraphQL engagiert ... aber wir müssen irgendwo anfangen, oder?)

Tolles Feedback, mir geht es genauso ;)

Am 6. Nov. 2018 um 12:06 schreef four44 [email protected] :

Bei GraphQL gibt es wirklich nur einen einzigen Endpunkt, also gibt es keinen solchen
Ding wie myapi.com/graphql/invoice und graphql/product, das Ende ist
nur "myapi.com/graphql" und nichts danach. Es ist buchstäblich die
gleiche URL für jede Abfrage und Mutation, mit den darin definierten Operationen
den Text der Anfrage.

Einige API-Verwaltungsfunktionen würden dann eine Selbstprüfung der
Anforderungstext, Kenntnis des graphql-Schemas usw. Nehmen wir an, dass dies
ist kurzfristig nicht machbar: WSO2 soll fast ein GraphQL werden
Server/Gateway selbst (oder integrieren).

Stattdessen sollten wir uns darauf konzentrieren, welche API-Verwaltungsfunktionen möglich sind .
Ich denke, wir brauchen eine Zusammenarbeit zwischen WSO2 und dem eigentlichen GraphQL
Server/Gateway, zB durch Setzen von Headern. Zum Beispiel Monetarisierung: die
GraphQL-Server kann die Komplexität der Abfrage berechnen, fügen Sie dies hinzu
Informationen als HTTP-Header an die Antwort, wo WSO2 diese übersetzt
Wert in einen Preis. In ähnlicher Weise kann der GraphQL-Server für die Überwachung
„Konvertieren“ Sie die JSON-förmige Abfrage in (eine Liste von) Rest-like
Pseudo-Endpunkt(e), die WSO2 aus dem Antwort-Header liest, um die
Überwachungsinformationen. Dasselbe kann für die Sicherheit getan werden, vielleicht in 2
Phasen: 1. Bitten Sie den GraphQL-Server, die Abfrage in Rest-like umzuwandeln
Endpunkte entscheidet WSO2, ob sie übergeben werden oder nicht, und leitet die Abfrage an den eigentlichen weiter
Endpunkt.

Ich bin völlig neu bei WSO2 und habe den größten Teil der Dokumentation nicht gelesen, also
vielleicht sind diese Features schon in WSO2 (genauer gesagt: für alle
Funktionalität von WSO2, die normalerweise vom genauen REST-Endpunkt abgeleitet wird
URI, ob dieselbe Funktionalität auf alternative Weise abgeleitet werden kann
(z. B. ein Header-Wert oder eine andere API zu WSO2 selbst)). Das ist wahrscheinlich
ein GraphQL-Server muss modifiziert werden, um diese WSO2-spezifischen zu unterstützen
Merkmale. Die Frage ist: Mit welchen niedrig hängenden Früchten können wir beginnen?

(Natürlich würde ich gerne sehen, dass WSO2 sich stark für GraphQL engagiert ...
aber wir müssen irgendwo anfangen, oder?)

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/wso2/product-apim/issues/3184#issuecomment-436215537 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/Ad4tuNmWvNcpkc1Nk5y46DljcQeM9RPwks5usW0kgaJpZM4TLf2Q
.

--
Bart van Vlierberghe

Hallo,
Hier ein Auszug aus der Apollo Server Dokumentation:
_"Wenn Sie eine REST-API mit integrierter Autorisierung verwenden, wie bei einem HTTP-Header, haben Sie eine weitere Option. Anstatt Authentifizierungs- oder Autorisierungsarbeiten in der GraphQL-Schicht (in Resolvern/Modellen) durchzuführen, ist dies möglich um die Header oder Cookies einfach an Ihren REST-Endpunkt weiterzuleiten und ihn die Arbeit erledigen zu lassen."_
Wenn der API-Schlüssel für alle Endpunkte, die von Ihren graphql-Abfragen betroffen sind, gleich ist, scheint dies ausreichen zu können.
Irgendwelche Gedanken zu diesem "Workaround" (Apollo-Server vor API-M setzen)?

Anforderungsanalyse

• GraphQL wird von Facebook entwickelt und ist eine Alternative zu REST. Es ist eine Abfragesprache für APIs, in der ein bestimmter Benutzer genau angeben kann, welche Daten von einer API benötigt werden.
• Wir wissen, dass wir eine Swagger-Definition (Open API Specification) verwenden können, um eine REST-API zu entwerfen. Aber in GraphQL können wir die Schema Definition Language (SDL) verwenden, um das Schema für eine GraphQL-API zu schreiben.
• Das Aufrufen einer GraphQL-API bedeutet einfach das Abrufen von Daten mithilfe von GraphQL-Abfragen und das Schreiben von Daten mithilfe von GraphQL-Mutationen.
• Hier ist unsere Anforderung, die Unterstützung von WSO2 APIM zu geben, um eine GraphQL-API zu erstellen und zu veröffentlichen und sie über https/http aufzurufen.

Vorgeschlagener Ansatz

• Beim Veröffentlichen einer GraphQL-API fordern wir den Benutzer (Publisher) auf, die Schemadatei hochzuladen, die die Definition enthält. Dann kann der Benutzer die Details über die API wie Name, Version, Kontext usw. eingeben. Der Benutzer wird jedoch nicht aufgefordert , die Ressourcen für GET- und POST-Methoden zu erstellen, wenn er die API erstellt.
  

• Als Nächstes auf der Registerkarte Implementieren , wenn der Benutzer auswählt,

  • API verwalten

    • Endpunkttyp sollte automatisch auf HTTP/REST -Endpunkt gesetzt werden. (Der Benutzer darf dies nicht ändern können)
    • Der Benutzer muss die Möglichkeit haben, den Endpunkt (Produktion und Sandbox) wie gewohnt zu ändern.
    • Andere Felder sollten gleich bleiben.
      

  • Prototypisierte API

    • Bei der Inline -Implementierungsmethode müssen zwei GET- und POST -Methoden automatisch erstellt und angezeigt werden, wie im folgenden Screenshot dargestellt.
      

• Wenn Sie die Option „ API verwalten “ wählen, müssen Sie die Einstellungen auf der Registerkarte „ Verwalten “ vornehmen.

  • Hier muss das gleiche Verfahren befolgt werden.
  • Speziell wie bei der Inline -Prototypenmethode müssen zwei GET- und POST -Methoden automatisch erstellt und wie im folgenden Screenshot angezeigt werden.
    

• Nachdem die API veröffentlicht oder als Prototyp erstellt wurde

  • Die API sollte im API Store als GraphQL-API gekennzeichnet sein.
  • Ein Verbraucher muss die Möglichkeit haben, die Schemadatei dieser API über den API Store herunterzuladen.

Sieht großartig aus

@wasuradananjith kannst du auch posten, wie eine GraphQL-API im Store aussieht? Ist die Abfrage im API-Portal verfügbar, wahrscheinlich mit dem Schema ?

Zumindest unterstützt Apollo die Verwendung von GET für die GraphQL-Datenanforderung.

Hallo zusammen,

Hier finden Sie die Informationen und PR des Graphql-Supports im Zusammenhang mit der Version WSO2 APIM 3.0.0. Da wir WSO2 APIM 3.0.0 unter einer neuen React-basierten Benutzeroberfläche veröffentlichen werden, wurden im Folgenden Screenshots der neuen Benutzeroberfläche hinzugefügt.

API-Herausgeber
Beschreibung:
Wenn der API-Ersteller das graphQL-Schema in den API-Publisher hochlädt, werden Abfrage- und Mutationsvorgänge im Publisher-Portal aufgelistet. Dann erlaubt er/sie, die Bereiche zu definieren, Richtlinien zu drosseln und die Sicherheit für die Vorgänge zu aktivieren/deaktivieren.

Funktionalitäten beim Verlag.

1. Erstellen Sie GraphQL-APIs, indem Sie das GraphQL-SDL-Schema importieren
2. Validieren Sie das Schema und extrahieren Sie seine Operationen aus der Schemadefinition
3. Abrufen/Importieren/Herunterladen des SDL-Schemas beim Herausgeber.
4. Zeigt Vorgänge anstelle von Ressourcen an
5. Hinzufügen/Aktualisieren von Drosselung, Bereichen, Sicherheit gegen Operationen
6. Sehen Sie sich die graphQL-APIs mit der Bezeichnung „GRAPHQL“ auf der API-Listing-Seite an

API-Store
Sobald die API von einem Publisher-Benutzer veröffentlicht wurde, wurden alle Vorgänge im SDL-Schema im Entwicklerportal ausgefüllt und die Schemadatei steht auch zum Download bereit. Entwickler können die Vorgänge mithilfe der Tryout-Konsole mit den Anforderungstypen GET und POST testen.

Funktionalitäten im Shop.

1. Sehen Sie sich die graphQL-APIs mit der Bezeichnung „GRAPHQL“ auf der API-Listing-Seite an
2. Anzeigen von Vorgängen für bestimmte APIs
3. Kann SDL-Schema-Abrufschema herunterladen
4. Stellen Sie der Entwicklerkonsole GET und POST bereit, um die API aufzurufen

Screenshots von Ansichten

1. GrpahQL-API-Seite erstellen
   

1. Schemaseite hochladen
   

2. Klicken Sie auf Weiter und füllen Sie ein Formular aus, um Details einzugeben
   

3. GraphQL-API-Übersichtsseite erstellt
   

4. GraphQL-API-Betriebsansicht
   

5. Schemadefinition hochgeladen
   

6. Bereiche hinzufügen/aktualisieren, Drosselung, Sicherheit
   

7. Überblick über den Geschäftsbetrieb
   

8. Schema-Download
   

9. Entwicklerkonsole
   

Aufrufzeit der Graphql-API

1. Autorisierung – API Creator kann Bereiche pro Vorgang beim Herausgeber hinzufügen
   Wenn der APP-Benutzer die graphQL-API mit einer Abfrage-/Mutationsoperation (Nur-Lesen/Lesen-Schreiben) aufruft, identifiziert das API-Gateway, welche Operationen in der Nutzlast enthalten sind, und passt sie entsprechend dem Token-Umfang des Benutzers an. Wenn die Nutzlast mehrere Vorgänge mit mehreren Bereichen enthält, sollte das Token mindestens eine Vereinigung der Vorgangsbereiche aufweisen.
   Beispiel: – Angenommen, eine Abfrage enthält (Operation A – Bereich 1, Operation B – Bereich 2)
   Das Token des Benutzers, der die Abfrage ausführen wird, sollte beide Bereiche haben (Bereich1 und Bereich2).

2. Sicherheit – API Creator kann die Sicherheit pro Vorgang beim Herausgeber aktivieren/deaktivieren.
   Wenn eine Abfrageanforderung mit mehreren Vorgangsnamen eingeht, wurde die Sicherheit als Vereinigung der Vorgangssicherheit betrachtet. Wenn für einen Vorgang die Sicherheit aktiviert wurde, unterstützen wir die Sicherheit für die gesamte Anfrage.

3. Drosselung – API Creator kann eine Drosselungsrichtlinie pro Vorgang beim Herausgeber hinzufügen.
   Wenn eine Abfrageanforderung mehrere Vorgangsnamen enthält, gelten die Drosselungsrichtlinien pro Vorgang. Wenn ein Vorgangsname der Anforderung gemäß seiner Richtlinie gedrosselt wurde, wird im Fall eines gedrosselten Vorgangs die gesamte Anforderung gedrosselt.

PR finden Sie unter https://github.com/wso2/carbon-apimgt/pull/6784.

• Auf dieser Ebene werden wir die Überprüfung und Analyse von Abfragen nicht unterstützen, API MicroGateway für GraphQL-Endpunkte unterstützen, Graphql-Abonnements mit den eingehenden Endpunkten (Web-Socket-APIs) unterstützen, ein zusätzliches Widget für Graphql-APIs einschließen, um die Anzahl der Vorgangsaufrufe anzuzeigen basierend auf Operationstypen usw. Daher wurden neue Probleme geöffnet, um relevante Unterstützung für unsere zukünftige Roadmap hinzuzufügen.

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

Schätzen Sie Ihre Gedanken und wertvollen Beiträge diesbezüglich.

Danke!

Hallo zusammen,

Hier finden Sie die Informationen und PR des Graphql-Supports im Zusammenhang mit der Version WSO2 APIM 3.0.0. Da wir WSO2 APIM 3.0.0 unter einer neuen React-basierten Benutzeroberfläche veröffentlichen werden, wurden im Folgenden Screenshots der neuen Benutzeroberfläche hinzugefügt.

API-Herausgeber
Beschreibung:
Wenn der API-Ersteller das graphQL-Schema in den API-Publisher hochlädt, werden Abfrage- und Mutationsvorgänge im Publisher-Portal aufgelistet. Dann erlaubt er/sie, die Bereiche zu definieren, Richtlinien zu drosseln und die Sicherheit für die Vorgänge zu aktivieren/deaktivieren.

Funktionalitäten beim Verlag.

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-Store
Sobald die API von einem Publisher-Benutzer veröffentlicht wurde, wurden alle Vorgänge im SDL-Schema im Entwicklerportal ausgefüllt und die Schemadatei steht auch zum Download bereit. Entwickler können die Vorgänge mithilfe der Tryout-Konsole mit den Anforderungstypen GET und POST testen.

Funktionalitäten im Shop.

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

Screenshots von Ansichten

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

Aufrufzeit der Graphql-API

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 finden Sie unter 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)

Schätzen Sie Ihre Gedanken und wertvollen Beiträge diesbezüglich.

Danke!

Hallo @HiranyaKavishani ,
Führt diese Unterstützung die Veröffentlichung vorhandener GraphQL-APIs über APIM ein, wie wir es normalerweise für vorhandene APIs über wso apim tun?

Gibt es auch eine Beta/Alpha-Version, um die Funktion zu testen?

Danke !

Hallo @arvindkannan ,

Für die vorhandenen Graphql-APIs müssen die APIs neu erstellt und erneut veröffentlicht werden, da Graphql im Vergleich zu den übrigen APIs eine andere Unterstützung bietet. In diesem Fall sollte jedoch sichergestellt werden, dass sich bestehende Token und bestehende URLs nicht ändern, da dies Auswirkungen auf bestehende Kunden hat.

Die Funktion wird mit APIM 3.0.0 verfügbar sein, das im Oktober veröffentlicht wird.

Danke!

Schließen Sie das Problem, da diese Unterstützung in der Beta-Version von APIM 3.0.0 verfügbar ist