Product-apim: Soporte para graphql

+1

+1

+1

+1

+1

+1

:+1:

Hola @YannickB ,

Gracias por mencionar esto. Nos gustaría agregar esto a nuestra hoja de ruta.

No he usado mucho GraphQL y, por lo tanto, tengo algunos problemas para comprender el alcance exacto del requisito. Para mayor claridad, ¿podría explicar las limitaciones exactas de la funcionalidad actual usando un ejemplo tal vez? Básicamente, lo que se expone a través del servidor Apollo y cómo tendría que exponerlo hoy a través de API Gateway frente a cuál habría sido la forma ideal de exponerlo a través de API Gateway.

Gracias,
Nuwan.

+1

Hola @nuwand ,

Primero como descargo de responsabilidad, incluso si abrí el ticket, no estoy seguro de ser la mejor persona para describir cómo debería funcionar la función. Piense en mí como alguien que estudia para construir una arquitectura de software realmente buena, por lo que incluye cosas como GraphQL y API Gateway, y mientras estudiaba esto, me di cuenta de que ningún API Gateway en el mercado actual fue diseñado para admitir completamente GraphQL. Por lo tanto, todavía no tengo un caso de uso real en producción, pero haré todo lo posible para ayudar.

Estoy de acuerdo en que la mejor manera de explicar será un ejemplo, así que aquí está:

Supongamos que tiene una API que proporciona funciones CRUD para dos objetos, producto y factura.

Con una API Rest, tendría dos puntos finales para usar, http://myapi.com/api/product y http://myapi.com/api/invoice , y luego realiza operaciones GET/POST/PUT/DELETE en ellos.
En WSO2, puede configurar cada punto final de forma independiente, uno para el producto y otro para la factura, y luego dar una configuración específica para que cada uno de ellos administre de forma independiente las funciones de seguridad/aceleración/monetización/etc... proporcionadas por WSO2.

Pero si proporcionamos una API GraphQL, actualmente estamos mucho más limitados. Esto se debe a que se podrá acceder a ambos objetos en el mismo punto final http://myapi.com/graphql. Y no hay forma de crear varios puntos finales http://myapi.com/graphql/product y http://myapi.com/graphql/invoice , esto es completamente antipatrón con las mejores prácticas de GraphQL y aprovechará al máximo herramientas en su ecosistema para dejar de funcionar. Además, creo que todas las operaciones HTTP son POST.

Entonces, como ejemplo, es posible que queramos hacer estas solicitudes en el punto final de GraphQL:

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

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

La primera solicitud consultará la información del producto especificado y la segunda creará una factura para este producto. Ambas consultas se ejecutan en el punto final http://myapi.com/graphql .

Entonces, con el estado actual de WSO2 Gateway, que si no me equivoco solo permite configurar por punto final, si quiero, por ejemplo, monetizar a 0.01 centavos cada llamada a createInvoice configurando el punto final http://myapi.com/graphql , entonces la llamada al producto también se monetizará a 0,01 céntimos. Con REST, solo configuraría 0.01cent en http://myapi.com/api/invoice en POST y eso sería todo.
Espero que esto sea suficiente para que entienda mi punto, este es un ejemplo simple pero podemos encontrar muchos otros, en el estado actual es imposible usar las funciones de Gateway con GraphQL debido a la falta de flexibilidad en la configuración. Y no es su culpa, creo que todos los demás API Gateway en el mercado tienen el mismo problema.

Entonces, la solución en mi humilde opinión permite adjuntar la configuración de WSO2 no solo al punto final, sino también a las funciones de GraphQL. Creo que esto puede resultar ser un desafío técnico, pero definitivamente hay una necesidad de esto en el mercado porque actualmente GraphQL simplemente no funciona con API Gateways, o de una manera muy degradada.

Parece que esta sugerencia atrajo bastante la atención. A las personas que siguen este problema, los invito a brindar información sobre su caso de uso y cómo WSO2 debería diseñar esta función. Espero haber hecho todo lo posible para describir la situación, pero creo que necesitarán un ejemplo real para implementar esto correctamente.

Atentamente,
Yannick

Como solución temporal, sería genial tener al menos la posibilidad de importar puntos finales WSO2-AM graphql, para usarlo como directorio de servicios mientras se espera un soporte completo en API Gateway.

Hola @YannickB ,

Gracias por tu explicación. Perdóname, pero todavía estoy tratando de descubrir las limitaciones con los puntos finales. Permítanme explicar la capacidad que tiene API Manager con respecto a los puntos finales y luego tal vez pueda señalar la limitación.

Suponga que tiene dos puntos finales como http://myapi.com/api/invoice y http://myapi.com/api/product. Tenga en cuenta que estoy usando el mismo ejemplo que usted, en el que ambos extremos parecen estar en el mismo host (myapi.com). Si su requisito es tener una sola API en API Manager para proxy de ambos puntos finales, lo que debe hacer es crear dos recursos, uno como POST/factura y el otro como POST/producto y especificar http://myapi.com/ api/ como punto final de la API respectiva. Esto le permitirá acceder a los dos puntos finales anteriores utilizando una sola API. Por ejemplo, si su host de puerta de enlace es gateway.myapi.com y el contexto de la API que crea es /graphql y su versión es 1.0.0, las siguientes solicitudes enviarían cada una de ellas al punto final apropiado, como se muestra a continuación.

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

Tenga en cuenta que solo tiene que crear 1 API (/graphql/1.0.0) para representar ambos puntos finales. Lo siento si estoy repitiendo algo que ya sabes :), pero si pudieras señalar la limitación de nuestro recurso para el mapeo que hace que sea imposible usar GraphQL, eso me ayudaría a comprender mejor el problema.

Gracias,
Nuwan.

Nuwand, soy menos técnico que tú. Pero, según tengo entendido, con un servidor APIM / Identity definimos en el nivel API la gestión de una API (seguridad, limitación, ... ..). GraphQL es una especie de lenguaje 'súper' que combina API a través de un lenguaje 'meta'. Lo que me interesaría es entender cómo se combinan los conceptos de GraphQL y los conceptos de un APIM WS02. y si se integrarán ambos conceptos. Por supuesto, puede considerar el recurso GraphQL als 1 que en sí mismo administra todo... pero el valor de WS02 es limitado si todos mis servicios 'heredados' serán accesibles a través del servidor graphql.

+1

Con GraphQL, en realidad solo hay un único punto final, por lo que no existe myapi.com/graphql/invoice y graphql/product, el punto final es simplemente "myapi.com/graphql", y nada después de eso. Es literalmente la misma URL para cada consulta y mutación, con las operaciones definidas dentro del cuerpo de la solicitud.

Algunas características de administración de API requerirían entonces la introspección del cuerpo de la solicitud, el conocimiento del esquema de graphql, etc. Supongamos que esto _no_ es factible a corto plazo: WSO2 casi debería convertirse en un servidor/puerta de enlace de GraphQL en sí mismo (o integrar uno).

En su lugar, debemos centrarnos en qué funciones de administración de API _son_ posibles. Supongo que necesitamos la cooperación entre WSO2 y el servidor/puerta de enlace de GraphQL real, por ejemplo, mediante la configuración de encabezados. Por ejemplo, monetización: el servidor GraphQL puede calcular la complejidad de la consulta, agregar esta información como un encabezado HTTP a la respuesta, donde WSO2 traduce este valor en un precio. De manera similar para el monitoreo, el servidor GraphQL puede 'convertir' la consulta en forma de JSON en (una lista de) pseudopuntos finales similares a descanso, que WSO2 lee del encabezado de respuesta para actualizar la información de monitoreo. Se puede hacer lo mismo por seguridad, tal vez en 2 fases: primero, solicite al servidor GraphQL que convierta la consulta en puntos finales similares a los de un descanso, WSO2 decide aprobar o no, reenviando la consulta al punto final real.

Soy completamente nuevo en WSO2 y no he leído la mayor parte de la documentación, por lo que tal vez estas características ya estén en WSO2 (más específicamente: para cualquier funcionalidad de WSO2 que generalmente se deriva del URI de punto final REST exacto, si esa misma funcionalidad puede derivarse de una forma alternativa (por ejemplo, un valor de encabezado o alguna otra API para el propio WSO2)). Es probable que sea necesario modificar un servidor GraphQL para admitir estas características específicas de WSO2. La pregunta es: ¿con qué fruta al alcance de la mano podemos empezar?

(Por supuesto que me gustaría ver a WSO2 hacer un gran compromiso con GraphQL... pero tenemos que empezar por algún lado, ¿no?)

Muy buenos comentarios, siento lo mismo ;)

Op. di 6 nov. 2018 a las 12:06 schreef cuarto44 [email protected] :

Con GraphQL, en realidad solo hay un único punto final, por lo que no existe tal
cosa como myapi.com/graphql/invoice y graphql/product, el endoint es
solo "myapi.com/graphql", y nada después de eso. es literalmente el
misma URL para cada consulta y mutación, con las operaciones definidas dentro
el cuerpo de la solicitud.

Algunas funciones de administración de API requerirían entonces una introspección de la
cuerpo de solicitud, conocimiento del esquema graphql, etc. Supongamos que esto
no es factible a corto plazo: WSO2 casi debería convertirse en un GraphQL
servidor/puerta de enlace en sí mismo (o integrar uno).

En su lugar, deberíamos centrarnos en qué características de gestión de API son posibles.
Supongo que necesitamos la cooperación entre WSO2 y GraphQL real.
servidor/puerta de enlace, por ejemplo, configurando encabezados. Por ejemplo, la monetización: el
El servidor GraphQL puede calcular la complejidad de la consulta, agregue esto
información como un encabezado HTTP a la respuesta, donde WSO2 traduce esto
valor en un precio. De manera similar para el monitoreo, el servidor GraphQL puede
'convertir' la consulta en forma de JSON en (una lista de) rest-like
pseudo-punto(s) final(es), que WSO2 lee del encabezado de respuesta para actualizar el
información de seguimiento. Se puede hacer lo mismo para la seguridad, tal vez en 2
fases: primero pídale al servidor GraphQL que convierta la consulta en reposo
endpoints, WSO2 decide pasar o no, reenviando la consulta al actual
punto final

Soy completamente nuevo en WSO2 y no he leído la mayor parte de la documentación, así que
tal vez estas características ya estén en WSO2 (más específicamente: para cualquier
funcionalidad de WSO2 que generalmente se deriva del punto final REST exacto
URI, si esa misma funcionalidad se puede derivar de una manera alternativa
(por ejemplo, un valor de encabezado o alguna otra API para WSO2 en sí)). Es probable que
un servidor GraphQL debe modificarse para admitir estos requisitos específicos de WSO2
características. La pregunta es: ¿con qué fruta al alcance de la mano podemos empezar?

(Por supuesto, me gustaría ver a WSO2 hacer un gran compromiso con GraphQL...
pero tenemos que empezar por algún lado, ¿no?)

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/wso2/product-apim/issues/3184#issuecomment-436215537 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/Ad4tuNmWvNcpkc1Nk5y46DljcQeM9RPwks5usW0kgaJpZM4TLf2Q
.

--
Bart Van Vlierberghe

Hola,
Aquí hay un extracto de la documentación del servidor Apollo:
_"Si está utilizando una API REST que tiene una autorización integrada, como un encabezado HTTP, tiene una opción más. En lugar de realizar cualquier trabajo de autenticación o autorización en la capa GraphQL (en resolutores/modelos), es posible para simplemente pasar los encabezados o las cookies a su punto final REST y dejar que haga el trabajo"._
Si la clave API es la misma para todos los puntos finales involucrados en sus consultas de graphql, parece que podría funcionar.
¿Alguna idea sobre esta "solución alternativa" (poner el servidor Apollo delante de API-M)?

Análisis de requisitos

• GraphQL es desarrollado por Facebook, que es una alternativa a REST. Es un lenguaje de consulta para API donde un usuario en particular puede especificar exactamente qué datos se necesitan de una API.
• Sabemos que podemos usar una Definición de Swagger (Especificación de API abierta) para diseñar una API REST. Pero en GraphQL, podemos usar el lenguaje de definición de esquemas (SDL) para escribir el esquema para una API de GraphQL.
• Invocar una API de GraphQL simplemente significa obtener datos mediante consultas de GraphQL y escribir datos mediante mutaciones de GraphQL.
• Aquí, nuestro requisito es brindar el soporte de WSO2 APIM para crear y publicar una API GraphQL e invocarla a través de https/http.

Enfoque sugerido

• Al publicar una API de GraphQL, solicitamos al usuario (editor) que cargue el archivo de esquema que contiene la definición. Luego, el usuario puede completar los detalles sobre la API, como el nombre, la versión, el contexto, etc. Pero no se le pedirá al usuario que cree los recursos para los métodos GET, POST al crear la API.
  

• A continuación, en la pestaña Implementar , si el usuario selecciona,

  • Administrar API

    • El tipo de punto final debe establecerse en punto final HTTP/REST automáticamente. (El usuario no debe tener la capacidad de cambiar esto)
    • El usuario debe tener la capacidad de cambiar el Endpoint (Producción y Sandbox) como de costumbre.
    • Otros campos deben permanecer igual.
      

  • API prototipo

    • En el método de implementación en línea , se deben crear y mostrar automáticamente dos métodos GET y POST como se muestra en la siguiente captura de pantalla.
      

• Si elige la opción Administrar API , debe establecer la configuración en la pestaña Administrar .

  • Aquí se debe seguir el mismo procedimiento.
  • Especialmente como en el método de prototipo en línea , se deben crear y mostrar automáticamente dos métodos GET y POST como en la siguiente captura de pantalla.
    

• Después de publicar o crear un prototipo de la API

  • La API debe estar etiquetada como una API de GraphQL en API Store.
  • Un consumidor debe tener la capacidad de descargar el archivo de esquema de esa API a través de API Store.

Se ve muy bien

@wasuradananjith , ¿puede publicar también cómo se ve una API de GraphQL en la tienda? ¿Está disponible la consulta en el portal API, probablemente con el esquema?

Al menos Apollo admite el uso de GET para la solicitud de datos de GraphQL.

Hola a todos,

Encuentre la información y las relaciones públicas del soporte de Graphql relacionado con el lanzamiento de WSO2 APIM 3.0.0. Dado que vamos a lanzar WSO2 APIM 3.0.0 con una nueva interfaz de usuario basada en React, se agregaron capturas de pantalla de la nueva interfaz de usuario a continuación.

editor de API
Descripción:
Cuando el creador de la API cargue el esquema de graphQL en el editor de la API, las operaciones de consulta y mutación se enumerarán en el portal del editor. Luego permitirá definir los alcances, políticas de aceleración, habilitar/deshabilitar la seguridad contra las operaciones.

Funcionalidades en el editor.

1. Cree una API de GraphQL importando el esquema SDL de GraphQL
2. Valide el esquema y extraiga sus operaciones de la definición del esquema
3. Recuperar/Importar/Descargar esquema SDL en el editor.
4. Muestra operaciones en lugar de recursos.
5. Agregar/Actualizar limitación, alcances, seguridad contra operaciones
6. Ver las API de graphQL etiquetando 'GRAPHQL' en la página de listado de API

Tienda API
Una vez que un usuario publicador publica la API, todas las operaciones en el esquema de SDL se completan en el portal para desarrolladores y el archivo de esquema también está disponible para descargar. El desarrollador puede probar las operaciones usando la consola Tryout con los tipos de solicitud GET y POST.

Funcionalidades en la tienda.

1. Ver las API de graphQL etiquetando 'GRAPHQL' en la página de listado de API
2. Ver operaciones para una API en particular
3. Capaz de descargar el esquema SDL recuperando el esquema
4. Proporcionar consola de desarrollador con GET y POST para invocar la API

Capturas de pantalla de vistas

1. Crear página API GrpahQL
   

1. Subir página de esquema
   

2. Haga clic en siguiente y complete un formulario para completar los detalles
   

3. Se creó la página de descripción general de la API de GraphQL
   

4. Vista de operaciones de la API de GraphQL
   

5. Definición de esquema cargada
   

6. Agregar/Actualizar alcances, limitación, seguridad
   

7. Descripción general del funcionamiento de la tienda
   

8. Descarga del esquema
   

9. Consola de desarrollador
   

Tiempo de invocación de la API de Graphql

1. Autorización: API Creator puede agregar alcances por operaciones en el editor
   Cuando el usuario de la aplicación invoca la API de graphQL con una operación de consulta/mutación (solo lectura/lectura-escritura), la puerta de enlace de la API identificará qué operaciones están contenidas en la carga útil y las comparará de acuerdo con el alcance del token del usuario. Si la carga útil contiene varias operaciones con varios ámbitos, el token debe tener al menos una unión de los ámbitos de operación.
   Por ejemplo: - Digamos que cuando una consulta contiene, (operación A - alcance 1, operación B - alcance 2)
   el token del usuario que va a ejecutar la consulta debe tener ambos ámbitos (scope1 y scope2)

2. Seguridad: API Creator puede habilitar/deshabilitar la seguridad por operaciones en el editor.
   Cuando una solicitud de consulta viene con múltiples nombres de operaciones, se ha considerado seguridad como la unión de la seguridad de las operaciones. Si se ha habilitado una operación de seguridad, admitimos la seguridad para toda la solicitud.

3. Limitación: API Creator puede agregar una política de limitación por operaciones en el editor.
   Cuando una solicitud de consulta viene con varios nombres de operación, se aplicarán políticas de aceleración por operación. Si un nombre de operación de la solicitud se limitó de acuerdo con su política, toda la solicitud se limitará en el caso de una operación limitada.

PR se encontrará en https://github.com/wso2/carbon-apimgt/pull/6784.

• En este nivel, no admitiremos la inspección y el análisis de consultas, admitiremos API MicroGateway para puntos finales de GraphQL, admitiremos suscripciones de Graphql con los puntos finales de entrada (API de socket web), Incluiremos un widget adicional para API de Graphql para ver el recuento de invocación de operaciones en función de los tipos de operación, etc. Por lo tanto, se han abierto nuevos problemas para agregar soporte relevante para nuestra hoja de ruta futura.

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

Agradezco sus pensamientos y valiosos aportes con respecto a esto.

¡Gracias!

Hola a todos,

Encuentre la información y las relaciones públicas del soporte de Graphql relacionado con el lanzamiento de WSO2 APIM 3.0.0. Dado que vamos a lanzar WSO2 APIM 3.0.0 con una nueva interfaz de usuario basada en React, se agregaron capturas de pantalla de la nueva interfaz de usuario a continuación.

editor de API
Descripción:
Cuando el creador de la API cargue el esquema de graphQL en el editor de la API, las operaciones de consulta y mutación se enumerarán en el portal del editor. Luego permitirá definir los alcances, políticas de aceleración, habilitar/deshabilitar la seguridad contra las operaciones.

Funcionalidades en el editor.

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

Tienda API
Una vez que un usuario publicador publica la API, todas las operaciones en el esquema de SDL se completan en el portal para desarrolladores y el archivo de esquema también está disponible para descargar. El desarrollador puede probar las operaciones usando la consola Tryout con los tipos de solicitud GET y POST.

Funcionalidades en la tienda.

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

Capturas de pantalla de vistas

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

Tiempo de invocación de la API de 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 encontrará en 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)

Agradezco sus pensamientos y valiosos aportes con respecto a esto.

¡Gracias!

Hola @HiranyaKavishani ,
¿Este soporte introduce la publicación de las API de GraphQL existentes a través de APIM como lo hacemos normalmente para las API existentes a través de wso apim?

¿También hay alguna versión Beta/Alpha para probar la función?

Gracias !

Hola @arvindkannan ,

Para las API de Graphql existentes, es necesario volver a crear las API y volver a publicar, ya que el soporte de graphql es diferente en comparación con el resto de las API. Pero si lo hace, debe asegurarse de que los tokens existentes y las URL existentes no cambien con esto, ya que afectará a los clientes existentes.

La función estará disponible con APIM 3.0.0, que se lanzará en octubre.

¡Gracias!

Cierre el problema ya que este soporte está disponible en la versión Beta de APIM 3.0.0