Product-apim: Prise en charge de graphql

+1

+1

+1

+1

+1

+1

:+1:

Bonjour @YannickB ,

Merci d'avoir soulevé cette question. Nous aimerions ajouter cela à notre feuille de route.

Je n'ai pas beaucoup utilisé GraphQL et j'ai donc du mal à comprendre la portée exacte de l'exigence. Pour plus de clarté, pourriez-vous expliquer les limitations exactes de la fonctionnalité actuelle en utilisant peut-être un exemple ? Fondamentalement, ce qui est exposé via le serveur Apollo et comment devriez-vous l'exposer via la passerelle API aujourd'hui par rapport à ce qui aurait été le moyen idéal de l'exposer via la passerelle API.

Merci,
Nuwan.

+1

Salut @nuwand ,

Tout d'abord en tant que clause de non-responsabilité, même si j'ai ouvert le ticket, je ne suis pas sûr d'être la meilleure personne pour décrire le fonctionnement de la fonctionnalité. Considérez-moi comme quelqu'un qui étudie pour construire une très bonne architecture logicielle, y compris des éléments comme GraphQL et API Gateway, et pendant que j'étudiais cela, il m'est devenu évident qu'aucune passerelle API sur le marché aujourd'hui n'a été conçue pour prendre pleinement en charge GraphQL. Par conséquent, je n'ai pas encore de cas d'utilisation réel en production, mais je ferai de mon mieux pour vous aider.

Je suis d'accord que la meilleure façon d'expliquer sera un exemple, alors le voici:

Supposons que vous disposiez d'une API fournissant des fonctions CRUD pour deux objets, produit et facture.

Avec une API Rest, vous auriez deux points de terminaison à utiliser, http://myapi.com/api/product et http://myapi.com/api/invoice , puis vous effectuez des opérations GET/POST/PUT/DELETE sur eux.
Dans WSO2, vous pouvez configurer chaque point de terminaison indépendamment, un pour le produit et un pour la facture, puis donner une configuration spécifique à chacun d'eux pour gérer indépendamment les fonctionnalités de sécurité/limitation/monétisation/etc... fournies par WSO2.

Mais si nous fournissons une API GraphQL, nous sommes actuellement beaucoup plus limités. Cela est dû au fait que les deux objets seront accessibles dans le même endpoint http://myapi.com/graphql. Et il n'y a aucun moyen de créer plusieurs points de terminaison http://myapi.com/graphql/product et http://myapi.com/graphql/invoice , ceci est complètement anti-modèle avec les meilleures pratiques de GraphQL et fera le plus outils de son écosystème pour arrêter de travailler. De plus, je crois que toutes les opérations HTTP sont POST.

Ainsi, à titre d'exemple, nous pouvons souhaiter effectuer ces requêtes sur le point de terminaison GraphQL :

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

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

La première requête interrogera les informations du produit spécifié, et la seconde créera une facture pour ce produit. Les deux requêtes sont exécutées sur le point de terminaison http://myapi.com/graphql .

Donc avec l'état actuel de WSO2 Gateway, qui si je ne me trompe pas ne permet de configurer que par point de terminaison, si je veux par exemple monétiser à 0.01cent chaque appel à createInvoice en configurant le point de terminaison http://myapi.com/graphql , alors l'appel au produit sera également monétisé à 0,01 centime. Avec REST, il vous suffirait de configurer le 0.01cent sur http://myapi.com/api/invoice sur POST et ce serait tout.
J'espère que cela vous suffira pour comprendre mon propos, c'est un exemple simple mais on peut en trouver plein d'autres, à l'état actuel il est impossible d'utiliser les fonctionnalités de Gateway avec GraphQL en raison d'un manque de flexibilité dans la configuration. Et ce n'est pas votre faute, je pense que toutes les autres passerelles API du marché ont le même problème.

Ainsi, la solution à mon humble avis permet d'attacher la configuration WSO2 non seulement au point de terminaison, mais également aux fonctions GraphQL. Cela peut s'avérer être un défi technique, je pense, mais il y a certainement un besoin pour cela sur le marché car actuellement GraphQL ne fonctionne tout simplement pas avec les passerelles API, ou de manière très dégradée.

Il semble que cette suggestion ait attiré pas mal d'attention. Aux personnes suivant ce problème, je vous invite à donner quelques informations sur votre cas d'utilisation et sur la façon dont WSO2 devrait concevoir cette fonctionnalité. J'espère que j'ai fait de mon mieux pour décrire la situation, mais je pense qu'ils auront besoin d'un exemple réel pour mettre cela en œuvre correctement.

Meilleures salutations,
Yannick

En tant que solution temporaire, il serait formidable d'avoir au moins la possibilité d'importer dans les points de terminaison graphql WSO2-AM, afin de l'utiliser comme répertoire de services en attendant une prise en charge complète dans la passerelle API

Bonjour @YannickB ,

Merci pour votre explication. Pardonnez-moi, mais j'essaie toujours de comprendre les limites des points de terminaison. Permettez-moi d'expliquer la capacité d'API Manager en ce qui concerne les points de terminaison, puis vous pourrez peut-être identifier la limitation.

Supposons que vous ayez deux points de terminaison comme http://myapi.com/api/invoice et http://myapi.com/api/product. Notez que j'utilise le même exemple que vous, sur lequel les deux points de terminaison semblent être sur le même hôte (myapi.com). Si votre exigence est d'avoir une seule API sur API Manager pour proxy les deux points de terminaison, ce que vous devez faire est de créer deux ressources, l'une en tant que POST /invoice et l'autre en tant que POST /product et spécifiez http://myapi.com/ api/ comme point de terminaison de l'API respective. Cela vous permettra d'accéder aux deux points de terminaison ci-dessus à l'aide d'une seule API. Par exemple, si votre hôte de passerelle est gateway.myapi.com et que le contexte de l'API que vous créez est /graphql et que sa version est 1.0.0, les requêtes suivantes seront transmises chacune par proxy au point de terminaison approprié, comme ci-dessous.

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

Notez que vous n'avez qu'à créer 1 API (/graphql/1.0.0) pour proxy les deux points de terminaison. Je suis désolé si je répète quelque chose que vous savez déjà :), mais si vous pouviez identifier la limitation de notre ressource à la cartographie qui rend impossible l'utilisation de GraphQL, cela m'aiderait à mieux comprendre le problème.

Merci,
Nuwan.

nuwand, je suis moins technique que vous. Mais dans ma compréhension avec un serveur APIM/Identity nous définissons au niveau API la gestion d'une API (sécurité, throttling, ... ..). GraphQL est une sorte de "super" langage combinant des API via un "méta" langage. Ce qui m'intéresserait, c'est de comprendre comment les concepts de GraphQL et les concepts d'un APIM WS02 sont appariés. et si les deux concepts seront intégrés. Bien sûr, vous pouvez considérer la ressource GraphQL als 1 qui elle-même gère tout .... mais la valeur de WS02 est limitée si tous mes services "hérités" seront accessibles via le serveur graphql.

+1

Avec GraphQL, il n'y a vraiment qu'un seul point de terminaison, donc il n'y a rien de tel que myapi.com/graphql/invoice et graphql/product, l'endoint est juste "myapi.com/graphql", et rien après cela. Il s'agit littéralement de la même URL pour chaque requête et mutation, avec les opérations définies dans le corps de la requête.

Certaines fonctionnalités de gestion d'api nécessiteraient alors une introspection du corps de la requête, une connaissance du schéma graphql, etc. Supposons que cela ne soit _pas_ faisable à court terme : WSO2 devrait presque devenir un serveur/passerelle GraphQL en soi (ou en intégrer un).

Au lieu de cela, nous devrions nous concentrer sur les fonctionnalités de gestion des API _sont_ possibles. Je suppose que nous avons besoin d'une coopération entre WSO2 et le serveur/passerelle GraphQL réel, par exemple en définissant des en-têtes. Par exemple la monétisation : le serveur GraphQL peut calculer la complexité de la requête, ajouter cette information sous forme d'en-tête HTTP à la réponse, où WSO2 traduit cette valeur en prix. De même pour la surveillance, le serveur GraphQL peut "convertir" la requête en forme de JSON en (une liste de) pseudo-points de terminaison de type repos, que WSO2 lit à partir de l'en-tête de réponse pour mettre à jour les informations de surveillance. La même chose peut être faite pour la sécurité, peut-être en 2 phases : 1er demander au serveur GraphQL de convertir la requête en points de terminaison de type repos, WSO2 décide de passer ou non, en transmettant la requête au point de terminaison réel.

Je suis complètement nouveau sur WSO2 et je n'ai pas lu la plupart de la documentation, donc peut-être que ces fonctionnalités sont déjà dans WSO2 (plus précisément : pour toute fonctionnalité de WSO2 qui est généralement dérivée de l'URI de point de terminaison REST exact, si cette même fonctionnalité peut être dérivée d'une autre manière (par exemple, une valeur d'en-tête ou une autre API vers WSO2 lui-même)). Il est probable qu'un serveur GraphQL doive être modifié pour prendre en charge ces fonctionnalités spécifiques à WSO2. La question est : par quel fruit à portée de main pouvons-nous commencer ?

(Bien sûr, j'aimerais voir WSO2 s'engager fortement dans GraphQL... mais nous devons commencer quelque part, n'est-ce pas ?)

Excellent retour, je ressens la même chose ;)

Op di 6 nov. 2018 à 12:06 schreef quatrième44 [email protected] :

Avec GraphQL, il n'y a vraiment qu'un seul point de terminaison, donc il n'y a pas de tel
chose comme myapi.com/graphql/invoice et graphql/product, l'endoint est
juste "myapi.com/graphql", et rien après ça. C'est littéralement le
même URL pour chaque requête et mutation, avec les opérations définies à l'intérieur
le corps de la requête.

Certaines fonctionnalités de gestion des API nécessiteraient alors une introspection de la
corps de la requête, connaissance du schéma graphql, etc. Supposons que cela
n'est pas faisable à court terme : WSO2 devrait presque devenir un GraphQL
serveur/passerelle en lui-même (ou en intégrer un).

Au lieu de cela, nous devrions nous concentrer sur les fonctionnalités de gestion des API qui sont possibles.
Je suppose que nous avons besoin d'une coopération entre WSO2 et le GraphQL réel
serveur/passerelle, par exemple en définissant des en-têtes. Par exemple la monétisation : le
Le serveur GraphQL peut calculer la complexité de la requête, ajoutez ceci
informations sous forme d'en-tête HTTP à la réponse, où WSO2 traduit cela
valeur en un prix. De même pour le monitoring, le serveur GraphQL peut
'convertir' la requête en forme de JSON en (une liste de) repos
pseudo-endpoint(s), que WSO2 lit à partir de l'en-tête de réponse pour mettre à jour le
informations de surveillance. La même chose peut être faite pour la sécurité, peut-être en 2
phases : 1ère demande au serveur GraphQL de convertir la requête en rest-like
terminaux, WSO2 décide de passer ou non, en transmettant la requête au véritable
point final.

Je suis complètement nouveau sur WSO2 et je n'ai pas lu la plupart de la documentation, donc
peut-être que ces fonctionnalités sont déjà dans WSO2 (plus précisément : pour tout
fonctionnalité de WSO2 qui est généralement dérivée du point de terminaison REST exact
URI, si cette même fonctionnalité peut être dérivée d'une autre manière
(par exemple, une valeur d'en-tête ou une autre API vers WSO2 lui-même)). Il est probable que
un serveur GraphQL doit être modifié pour prendre en charge ces spécificités WSO2
caractéristiques. La question est : par quel fruit à portée de main pouvons-nous commencer ?

(Bien sûr, j'aimerais voir WSO2 s'engager fortement dans GraphQL...
mais nous devons commencer quelque chose, n'est-ce pas ?)

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/wso2/product-apim/issues/3184#issuecomment-436215537 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/Ad4tuNmWvNcpkc1Nk5y46DljcQeM9RPwks5usW0kgaJpZM4TLf2Q
.

--
Bart Van Vlierberghe

Bonjour,
Voici un extrait de la documentation d'Apollo Server :
_"Si vous utilisez une API REST qui a une autorisation intégrée, comme avec un en-tête HTTP, vous avez une autre option. Plutôt que de faire un travail d'authentification ou d'autorisation dans la couche GraphQL (dans les résolveurs/modèles), c'est possible pour simplement transmettre les en-têtes ou les cookies à votre point de terminaison REST et le laisser faire le travail."_
Si la clé API est la même pour tous les points de terminaison impliqués par vos requêtes graphql, il semble que cela pourrait faire l'affaire.
Des idées sur cette "solution de contournement" (mettre le serveur Apollo devant l'API-M) ?

Analyse des besoins

• GraphQL est développé par Facebook qui est une alternative à REST. Il s'agit d'un langage de requête pour les API où un utilisateur particulier peut spécifier exactement quelles données sont nécessaires à partir d'une API.
• Nous savons que nous pouvons utiliser une définition Swagger (Open API Specification) pour concevoir une API REST. Mais dans GraphQL, nous pouvons utiliser Schema Definition Language (SDL) pour écrire le schéma d'une API GraphQL.
• Invoquer une API GraphQL signifie simplement récupérer des données à l'aide de requêtes GraphQL et écrire des données à l'aide de mutations GraphQL.
• Ici, notre exigence est de fournir le support de WSO2 APIM afin de créer et de publier une API GraphQL et de l'invoquer via https/http.

Approche suggérée

• Lors de la publication d'une API GraphQL, nous demandons à l'utilisateur (éditeur) de télécharger le fichier de schéma qui constitue la définition. Ensuite, l'utilisateur peut remplir les détails de l'API tels que le nom, la version, le contexte, etc. Mais l'utilisateur ne sera pas invité à créer les ressources pour les méthodes GET, POST lors de la création de l'API.
  

• Ensuite, dans l'onglet Mettre en œuvre, si l'utilisateur sélectionne,

  • Gérer l'API

    • Le type de point de terminaison doit être défini sur HTTP/REST Endpoint automatiquement. (L'utilisateur ne doit pas avoir la capacité de changer cela)
    • L'utilisateur doit avoir la possibilité de modifier le point de terminaison (production et bac à sable) comme d'habitude.
    • Les autres champs doivent rester les mêmes.
      

  • API prototype

    • Dans la méthode d'implémentation Inline , deux méthodes GET et POST doivent être automatiquement créées et affichées comme indiqué dans la capture d'écran suivante.
      

• Si vous choisissez l'option Gérer l'API , vous devez définir les paramètres dans l'onglet Gérer .

  • Ici, la même procédure doit être suivie.
  • Spécialement comme dans la méthode prototype Inline , deux méthodes GET et POST doivent être automatiquement créées et affichées comme dans la capture d'écran suivante.
    

• Une fois l'API publiée ou prototypée

  • L'API doit être étiquetée comme une API GraphQL dans API Store.
  • Un consommateur doit avoir la possibilité de télécharger le fichier de schéma de cette API via API Store.

A l'air bien

@wasuradananjith pouvez-vous également publier à quoi ressemble une API GraphQL dans le magasin ? L'interrogation est-elle disponible dans le portail API, probablement avec le schéma ?

Au moins, Apollo prend en charge l'utilisation de GET pour la demande de données GraphQL.

Salut tout le monde,

Veuillez trouver les informations et les relations publiques du support Graphql relatives à la version WSO2 APIM 3.0.0. Puisque nous allons publier WSO2 APIM 3.0.0 sous une nouvelle interface utilisateur basée sur React, des captures d'écran de la nouvelle interface utilisateur ont été ajoutées ci-dessous.

Éditeur d'API
La description:
Lorsque le créateur de l'API télécharge le schéma graphQL dans l'éditeur de l'API, les opérations de requête et de mutation seront répertoriées dans le portail de l'éditeur. Ensuite, il / elle permettra de définir les portées, les politiques de limitation, d'activer / désactiver la sécurité contre les opérations.

Fonctionnalités chez l'éditeur.

1. Créer une API GraphQL en important le schéma SDL GraphQL
2. Valider le schéma et extraire ses opérations de la définition de schéma
3. Récupérer/Importer/Télécharger le schéma SDL chez l'éditeur.
4. Affiche les opérations au lieu des ressources
5. Ajouter/Mettre à jour la limitation, les étendues, la sécurité contre les opérations
6. Voir les API graphQL étiquetées 'GRAPHQL' sur la page de liste des API

Magasin d'API
Une fois l'API publiée par un utilisateur éditeur, toutes les opérations du schéma SDL ont été renseignées sur le portail des développeurs et le fichier de schéma est également disponible au téléchargement. Le développeur peut tester les opérations à l'aide de la console Tryout avec les types de requête GET et POST.

Fonctionnalités en magasin.

1. Voir les API graphQL étiquetées 'GRAPHQL' sur la page de liste des API
2. Afficher les opérations pour une API particulière
3. Capable de télécharger le schéma SDL en récupérant le schéma
4. Fournir la console développeur avec GET et POST pour invoquer l'API

Captures d'écran des vues

1. Créer une page d'API GrpahQL
   

1. Télécharger la page de schéma
   

2. Cliquez sur suivant et remplissez un formulaire pour remplir les détails
   

3. Création de la page de présentation de l'API GraphQL
   

4. Vue des opérations de l'API GraphQL
   

5. Définition de schéma téléchargée
   

6. Ajouter/Mettre à jour les étendues, la limitation, la sécurité
   

7. Aperçu du fonctionnement du magasin
   

8. Téléchargement du schéma
   

9. Console développeur
   

Temps d'invocation de l'API Graphql

1. Autorisation : le créateur d'API peut ajouter des champs d'application par opération chez l'éditeur
   Lorsque l'utilisateur APP invoque l'API graphQL avec une opération de requête/mutation (lecture seule/lecture-écriture), la passerelle API identifiera les opérations contenues dans la charge utile et les fera correspondre en fonction de la portée du jeton de l'utilisateur. Si la charge utile contient plusieurs opérations avec plusieurs portées, le jeton doit avoir au moins une union des portées d'opération.
   Par exemple : - Disons qu'une requête contient, (opération A - portée 1, opération B - portée 2)
   le jeton de l'utilisateur qui va exécuter la requête doit avoir les deux portées (scope1 et scope2)

2. Sécurité - API Creator peut activer/désactiver la sécurité par opération chez l'éditeur.
   Lorsqu'une demande de requête est accompagnée de plusieurs noms d'opérations, la sécurité a été considérée comme l'union de la sécurité des opérations. Si une opération a été activée pour la sécurité, nous prenons en charge la sécurité pour l'ensemble de la demande.

3. Limitation - API Creator peut ajouter une politique de limitation par opération chez l'éditeur.
   Lorsqu'une demande de requête est fournie avec plusieurs noms d'opération, les stratégies de régulation s'appliquent par opération. Si un nom d'opération de la demande a été limité conformément à sa stratégie, l'ensemble de la demande sera limité dans le cas d'une opération limitée.

PR sera trouvé à https://github.com/wso2/carbon-apimgt/pull/6784.

• À ce niveau, nous n'allons pas prendre en charge l'inspection et l'analyse des requêtes, prendre en charge l'API MicroGateway pour les points de terminaison GraphQL, prendre en charge les abonnements Graphql avec les points de terminaison entrants (API de socket Web), inclure un widget supplémentaire pour les API Graphql pour voir le nombre d'invocations d'opérations en fonction des types d'opérations, etc. De ce fait, de nouvelles issues ont été ouvertes pour ajouter un support pertinent à notre future feuille de route.

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

Appréciez vos réflexions et vos précieuses contributions à ce sujet.

Merci!

Salut tout le monde,

Veuillez trouver les informations et les relations publiques du support Graphql relatives à la version WSO2 APIM 3.0.0. Puisque nous allons publier WSO2 APIM 3.0.0 sous une nouvelle interface utilisateur basée sur React, des captures d'écran de la nouvelle interface utilisateur ont été ajoutées ci-dessous.

Éditeur d'API
La description:
Lorsque le créateur de l'API télécharge le schéma graphQL dans l'éditeur de l'API, les opérations de requête et de mutation seront répertoriées dans le portail de l'éditeur. Ensuite, il / elle permettra de définir les portées, les politiques de limitation, d'activer / désactiver la sécurité contre les opérations.

Fonctionnalités chez l'éditeur.

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

Magasin d'API
Une fois l'API publiée par un utilisateur éditeur, toutes les opérations du schéma SDL ont été renseignées sur le portail des développeurs et le fichier de schéma est également disponible au téléchargement. Le développeur peut tester les opérations à l'aide de la console Tryout avec les types de requête GET et POST.

Fonctionnalités en magasin.

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

Captures d'écran des vues

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

Temps d'invocation de l'API Graphql

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 se trouve à 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)

Appréciez vos réflexions et vos précieuses contributions à ce sujet.

Merci!

Salut @HiranyaKavishani ,
Cette prise en charge introduit-elle la publication des API GraphQL existantes via APIM comme nous le faisons normalement pour les API existantes via wso apim ?

Existe-t-il également une version bêta/alpha pour tester la fonctionnalité ?

Merci !

Salut @arvindkannan ,

Pour les API Graphql existantes, il est nécessaire de recréer les API et de les republier car graphql a un support différent par rapport aux autres API. Mais si c'est le cas, il devrait s'assurer que les jetons existants et les URL existantes ne changeront pas avec cela car cela sera affecté aux clients existants.

La fonctionnalité sera disponible avec APIM 3.0.0 qui sortira en octobre.

Merci!

Fermez le problème car cette prise en charge est disponible dans la version bêta d'APIM 3.0.0