Product-apim: Suporte para graphql

+1

+1

+1

+1

+1

+1

:+1:

Olá @YannickB ,

Obrigado por trazer isso à tona. Gostaríamos de adicioná-lo ao nosso roteiro.

Eu não usei muito o GraphQL e, portanto, tive alguns problemas para entender o escopo exato do requisito. Para maior clareza, você poderia explicar as limitações exatas da funcionalidade atual usando um exemplo, talvez? Basicamente, o que é exposto por meio do servidor Apollo e como você teria que expor isso por meio do API Gateway hoje versus qual seria a maneira ideal de expô-lo por meio do API Gateway.

Obrigado,
Nuwan.

+1

Olá @nuwand ,

Primeiro como isenção de responsabilidade, mesmo que eu tenha aberto o ticket, não tenho certeza se sou a melhor pessoa para descrever como o recurso deve funcionar. Pense em mim como alguém estudando para construir uma arquitetura de software realmente boa, incluindo coisas como GraphQL e API Gateway, e enquanto eu estudava isso, fiquei óbvio para mim que nenhum API Gateway no mercado hoje foi projetado para oferecer suporte total ao GraphQL. Portanto, ainda não tenho nenhum caso de uso real em produção, mas farei o possível para ajudar.

Eu concordo que a melhor maneira de explicar será um exemplo, então aqui está:

Digamos que você tenha uma API fornecendo funções CRUD para dois objetos, produto e fatura.

Com uma API Rest, você teria dois endpoints para usar, http://myapi.com/api/product e http://myapi.com/api/invoice , e então faria operações GET/POST/PUT/DELETE neles.
No WSO2, você pode configurar cada endpoint de forma independente, um para produto e outro para fatura, e então dar uma configuração específica para cada um deles para gerenciar independentemente os recursos de segurança/limitação/monetização/etc... fornecidos pelo WSO2.

Mas se estamos fornecendo uma API GraphQL, estamos atualmente muito mais limitados. Isso se deve ao fato de que ambos os objetos estarão acessíveis no mesmo endpoint http://myapi.com/graphql. E não há como criar vários endpoints http://myapi.com/graphql/product e http://myapi.com/graphql/invoice , isso é totalmente anti-padrão com as melhores práticas do GraphQL e fará a maioria dos ferramentas em seu ecossistema pararem de funcionar. Além disso, acredito que todas as operações HTTP são POST.

Então, como exemplo, podemos querer fazer essas solicitações no endpoint GraphQL:

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

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

A primeira solicitação consultará as informações do produto especificado e a segunda criará uma fatura para esse produto. Ambas as consultas são executadas no ponto de extremidade http://myapi.com/graphql .

Assim com o estado atual do WSO2 Gateway, que se não me engano só permite configurar por endpoint, se eu quiser por exemplo rentabilizar a 0,01cent cada chamada para createInvoice configurando o endpoint http://myapi.com/graphql , então a chamada para o produto também será monetizada em 0,01 centavo. Com REST, você apenas configuraria o 0.01cent para o http://myapi.com/api/invoice no POST e isso seria tudo.
Espero que isso seja suficiente para você entender meu ponto, este é um exemplo simples, mas podemos encontrar muitos outros, no estado atual é impossível usar os recursos do Gateway com o GraphQL devido à falta de flexibilidade na configuração. E a culpa não é sua, acredito que todos os outros API Gateways do mercado tenham o mesmo problema.

Portanto, a solução IMHO permite anexar a configuração do WSO2 não apenas ao endpoint, mas também às funções do GraphQL. Isso pode ser um desafio técnico, eu acho, mas definitivamente há uma necessidade disso no mercado porque atualmente o GraphQL simplesmente não funciona com API Gateways, ou de uma maneira muito degradada.

Parece que esta sugestão atraiu bastante atenção. Para as pessoas que acompanham esta edição, convido você a fornecer algumas informações sobre seu caso de uso e como o WSO2 deve projetar esse recurso. Espero ter feito o meu melhor para descrever a situação, mas acredito que eles precisarão de algum exemplo real para implementar isso adequadamente.

Atenciosamente,
Yannick

Como solução temporária, seria ótimo ter pelo menos a possibilidade de importar em endpoints WSO2-AM graphql, para usá-lo como Service Directory enquanto aguarda um suporte completo no API Gateway

Olá @YannickB ,

Obrigado pela sua explicação. Perdoe-me, mas ainda estou tentando descobrir as limitações com os endpoints. Deixe-me explicar a capacidade que o API Manager tem em relação aos endpoints e, em seguida, talvez você possa identificar a limitação.

Suponha que você tenha dois endpoints como http://myapi.com/api/invoice e http://myapi.com/api/product. Observe que estou usando o mesmo exemplo que você, em que ambos os endpoints parecem estar no mesmo host (myapi.com). Se o seu requisito é ter uma única API no API Manager para fazer proxy de ambos os endpoints, o que você precisa fazer é criar dois recursos, um como POST /invoice e o outro como POST /product e especificar http://myapi.com/ api/ como o endpoint da respectiva API. Isso permitirá que você acesse os dois endpoints acima usando uma única API. Por exemplo, se seu host de gateway for gateway.myapi.com e o contexto da API que você criar for /graphql e sua versão for 1.0.0, as solicitações a seguir fariam proxy de cada uma para o endpoint apropriado conforme abaixo.

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

Observe que você só precisa criar 1 API (/graphql/1.0.0) para fazer proxy de ambos os endpoints. Desculpe se estou repetindo algo que você já sabe :), mas se você pudesse apontar a limitação do nosso recurso de mapeamento que impossibilita o uso do GraphQL isso me ajudaria a entender melhor o problema.

Obrigado,
Nuwan.

Nuwand, sou menos técnico que você. Mas no meu entendimento com um servidor APIM/Identidade definimos no nível da API o gerenciamento de uma API (segurança, throttling, ... ..) . GraphQL é um tipo de linguagem 'super' que combina APIs por meio de uma linguagem 'meta'. O que me interessaria é entender como os conceitos do GraphQL e os conceitos de um APIM WS02 são combinados. e se ambos os conceitos serão integrados. Claro que você pode considerar o recurso GraphQL als 1 que gerencia tudo .... mas o valor do WS02 é limitado se todos os meus serviços 'legados' forem acessíveis através do servidor graphql.

+1

Com o GraphQL, há realmente apenas um único ponto de extremidade, portanto, não existe myapi.com/graphql/invoice e graphql/product, o endoint é apenas "myapi.com/graphql" e nada depois disso. É literalmente a mesma URL para cada consulta e mutação, com as operações definidas dentro do corpo da solicitação.

Alguns recursos de gerenciamento de API exigiriam introspecção do corpo da solicitação, conhecimento do esquema graphql, etc. Vamos supor que isso _não_ seja viável em curto prazo: o WSO2 deve quase se tornar um servidor/gateway GraphQL em si (ou integrar um).

Em vez disso, devemos nos concentrar em quais recursos de gerenciamento de API _são_ possíveis. Acho que precisamos de cooperação entre o WSO2 e o servidor/gateway real do GraphQL, por exemplo, definindo cabeçalhos. Por exemplo monetização: o servidor GraphQL pode calcular a complexidade da consulta, adicionar essa informação como um cabeçalho HTTP à resposta, onde o WSO2 traduz esse valor em um preço. Da mesma forma para monitoramento, o servidor GraphQL pode 'converter' a consulta em forma de JSON em (uma lista de) pseudo-endpoints semelhantes a descanso, que o WSO2 lê do cabeçalho de resposta para atualizar as informações de monitoramento. A mesma coisa pode ser feita para segurança, talvez em 2 fases: 1º pedir ao servidor GraphQL para converter a consulta em endpoints do tipo rest, WSO2 decide passar ou não, encaminhando a consulta para o endpoint real.

Sou completamente novo no WSO2 e não li a maior parte da documentação, então talvez esses recursos já estejam no WSO2 (mais especificamente: para qualquer funcionalidade do WSO2 que geralmente é derivada do URI do ponto de extremidade REST exato, se essa mesma funcionalidade pode ser derivado de uma forma alternativa (por exemplo, um valor de cabeçalho ou alguma outra API para o próprio WSO2)). É provável que um servidor GraphQL precise ser modificado para oferecer suporte a esses recursos específicos do WSO2. A questão é: com que fruta fácil podemos começar?

(Claro que eu gostaria de ver o WSO2 fazer um grande compromisso com o GraphQL... mas precisamos começar de alguma forma, certo?)

Ótimo feedback, eu sinto o mesmo ;)

Op de 6 nov. 2018 às 12:06 schreef four44 [email protected] :

Com o GraphQL, realmente existe apenas um único endpoint, então não existe tal
coisa como myapi.com/graphql/invoice e graphql/product, o endoint é
apenas "myapi.com/graphql", e nada depois disso. É literalmente o
mesma URL para cada consulta e mutação, com as operações definidas dentro
o corpo do pedido.

Alguns recursos de gerenciamento de API exigiriam a introspecção do
corpo da solicitação, conhecimento do esquema graphql, etc. Vamos supor que isso
não é viável a curto prazo: WSO2 deve quase se tornar um GraphQL
servidor/gateway em si (ou integre um).

Em vez disso, devemos nos concentrar em quais recursos de gerenciamento de API são possíveis.
Acho que precisamos de cooperação entre o WSO2 e o GraphQL real
servidor/gateway, por exemplo, definindo cabeçalhos. Por exemplo, monetização: o
O servidor GraphQL pode calcular a complexidade da consulta, adicione isso
informações como um cabeçalho HTTP para a resposta, onde WSO2 traduz isso
valor em preço. Da mesma forma para monitoramento, o servidor GraphQL pode
'converter' a consulta em forma de JSON em (uma lista de) rest-like
pseudo-endpoint(s), que o WSO2 lê do cabeçalho de resposta para atualizar o
informações de monitoramento. A mesma coisa pode ser feita para segurança, talvez em 2
fases: 1º peça ao servidor GraphQL para converter a consulta em rest-like
endpoints, o WSO2 decide passar ou não, encaminhando a consulta para o
ponto final.

Sou completamente novo no WSO2 e não li a maior parte da documentação, então
talvez esses recursos já estejam no WSO2 (mais especificamente: para qualquer
funcionalidade do WSO2 que geralmente é derivada do ponto de extremidade REST exato
URI, se essa mesma funcionalidade pode ser derivada de forma alternativa
(por exemplo, um valor de cabeçalho ou alguma outra API para o próprio WSO2)). É provável que
um servidor GraphQL precisa ser modificado para dar suporte a esses
recursos. A questão é: com que fruta fácil podemos começar?

(É claro que eu gostaria de ver o WSO2 fazer um grande compromisso com o GraphQL...
mas precisamos começar de algum lugar, certo?)

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/wso2/product-apim/issues/3184#issuecomment-436215537 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/Ad4tuNmWvNcpkc1Nk5y46DljcQeM9RPwks5usW0kgaJpZM4TLf2Q
.

--
Bart Van Vlierberghe

Olá,
Aqui está um extrato da documentação do Apollo Server:
_"Se você estiver usando uma API REST com autorização integrada, como com um cabeçalho HTTP, terá mais uma opção. Em vez de fazer qualquer autenticação ou autorização na camada GraphQL (em resolvedores/modelos), é possível para simplesmente passar pelos cabeçalhos ou cookies para seu endpoint REST e deixá-lo fazer o trabalho."_
Se a chave da API for a mesma para todos os endpoints envolvidos por suas consultas graphql, parece que isso pode resolver o problema.
Alguma ideia sobre essa "solução alternativa" (coloque o servidor Apollo na frente da API-M)?

Análise de Requisitos

• GraphQL é desenvolvido pelo Facebook, que é uma alternativa ao REST. É uma linguagem de consulta para APIs em que um usuário específico pode especificar exatamente quais dados são necessários de uma API.
• Sabemos que podemos usar uma definição de Swagger (especificação de API aberta) para projetar uma API REST. Mas no GraphQL, podemos usar Schema Definition Language (SDL) para escrever o esquema para uma API do GraphQL.
• Invocar uma API GraphQL significa simplesmente buscar dados usando consultas GraphQL e gravar dados usando mutações GraphQL.
• Aqui, nosso requisito é fornecer suporte do WSO2 APIM para criar e publicar uma API GraphQL e invocá-la por https/http.

Abordagem sugerida

• Ao publicar uma API GraphQL, solicitamos ao usuário (editor) que carregue o arquivo de esquema que consiste na definição. Em seguida, o usuário pode preencher os detalhes sobre a API, como nome, versão, contexto etc. Mas o usuário não será solicitado a criar os recursos para os métodos GET, POST ao criar a API.
  

• Em seguida, na guia Implementar , se o usuário selecionar,

  • Gerenciar API

    • O tipo de ponto de extremidade deve ser definido como ponto de extremidade HTTP/REST automaticamente. (O usuário não deve ter a capacidade de alterar isso)
    • O usuário deve ter a capacidade de alterar o Endpoint (Produção e Sandbox) como de costume.
    • Outros campos devem permanecer os mesmos.
      

  • API prototipada

    • No método de implementação Inline , dois métodos GET e POST devem ser criados automaticamente e exibidos conforme exibido na captura de tela a seguir.
      

• Se você escolher a opção Gerenciar API , deverá definir as configurações na guia Gerenciar .

  • Aqui o mesmo procedimento deve ser seguido.
  • Especialmente como no método de protótipo Inline , dois métodos GET e POST devem ser criados e exibidos automaticamente como na captura de tela a seguir.
    

• Depois que a API for publicada ou prototipada

  • A API deve ser rotulada como uma API GraphQL na API Store.
  • Um consumidor deve ter a capacidade de baixar o arquivo de esquema dessa API por meio da API Store.

Parece ótimo

@wasuradananjith você também pode postar como uma API GraphQL se parece na loja? A consulta está disponível no Portal da API, provavelmente com o esquema ?

Pelo menos o Apollo oferece suporte ao uso de GET para a solicitação de dados do GraphQL.

Olá a todos,

Por favor, encontre as informações e PR do suporte ao Graphql relacionado à versão WSO2 APIM 3.0.0. Como vamos lançar o WSO2 APIM 3.0.0 sob uma nova interface do usuário baseada em React, as capturas de tela da nova interface do usuário foram adicionadas a seguir.

Editor de API
Descrição:
Quando o criador da API carrega o esquema graphQL no publicador da API, as operações de consulta e mutação serão listadas no portal do publicador. Então permitirá definir os escopos, políticas de limitação, habilitar/desabilitar a segurança contra as operações.

Funcionalidades na editora.

1. Crie uma API do GraphQL importando o esquema SDL do GraphQL
2. Valide o esquema e extraia suas operações da definição do esquema
3. Recupere/importe/baixe o esquema SDL no editor.
4. Mostra operações em vez de recursos
5. Adicionar/atualizar limitação, escopos, segurança contra operações
6. Veja as APIs do graphQL rotulando 'GRAPHQL' na página de listagem da API

Loja de API
Depois que a API for publicada por um usuário publicador, todas as operações no esquema SDL foram preenchidas no portal do desenvolvedor e o arquivo de esquema também estará disponível para download. O desenvolvedor pode testar as operações usando o console Tryout com os tipos de solicitação GET e POST.

Funcionalidades na loja.

1. Veja as APIs do graphQL rotulando 'GRAPHQL' na página de listagem da API
2. Visualizar operações para uma API específica
3. Capaz de baixar o esquema de recuperação do esquema SDL
4. Forneça o console do desenvolvedor com GET e POST para invocar a API

Capturas de tela de visualizações

1. Criar página de API do GrpahQL
   

1. Carregar página de esquema
   

2. Clique em próximo e preencha um formulário para preencher os detalhes
   

3. Página de visão geral da API GraphQL criada
   

4. Visualização da operação da API GraphQL
   

5. Definição de esquema enviada
   

6. Adicionar/atualizar escopos, limitação, segurança
   

7. Visão geral da operação da loja
   

8. Download do esquema
   

9. Console do desenvolvedor
   

Tempo de invocação da API Graphql

1. Autorização - API Creator pode adicionar escopos por operações no editor
   Quando o usuário do APP invoca a API graphQL com operação de consulta/mutação (somente leitura/leitura-gravação), o gateway da API identificará quais operações estão contidas na carga útil e as corresponderá de acordo com o escopo do token do usuário. Se a carga contiver várias operações com vários escopos, o token deverá ter pelo menos uma união dos escopos da operação.
   Ex:- Digamos quando uma consulta contém, (operação A - escopo 1, operação B - escopo 2)
   o token do usuário que vai executar a consulta deve ter os dois escopos (escopo1 e escopo2)

2. Segurança - o API Creator pode ativar/desativar a segurança por operações no editor.
   Quando uma solicitação de consulta vem com vários nomes de operação, a segurança foi considerada como a união da segurança das operações. Se uma operação tiver ativado a segurança, oferecemos suporte à segurança para toda a solicitação.

3. Limitação - o Criador de API pode adicionar política de limitação por operações no editor.
   Quando uma solicitação de consulta vem com vários nomes de operação, as políticas de limitação serão aplicadas por operação. Se um nome de operação da solicitação tiver sido estrangulado de acordo com sua política, toda a solicitação será estrangulada no caso de operação estrangulada.

PR será encontrado em https://github.com/wso2/carbon-apimgt/pull/6784.

• Neste nível, não vamos dar suporte à inspeção e análise de consultas, suporte à API MicroGateway para terminais GraphQL, suporte a assinaturas Graphql com os terminais de entrada (APIs de soquete da Web), Incluir um widget extra para APIs Graphql para ver a contagem de invocação de operação com base nos tipos de operação, etc. Portanto, novos problemas foram abertos para adicionar suporte relevante ao nosso roteiro futuro.

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

Aprecie seus pensamentos e contribuições valiosas sobre isso.

Obrigado!

Olá a todos,

Por favor, encontre as informações e PR do suporte ao Graphql relacionado à versão WSO2 APIM 3.0.0. Como vamos lançar o WSO2 APIM 3.0.0 sob uma nova interface do usuário baseada em React, as capturas de tela da nova interface do usuário foram adicionadas a seguir.

Editor de API
Descrição:
Quando o criador da API carrega o esquema graphQL no publicador da API, as operações de consulta e mutação serão listadas no portal do publicador. Então permitirá definir os escopos, políticas de limitação, habilitar/desabilitar a segurança contra as operações.

Funcionalidades na editora.

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

Loja de API
Depois que a API for publicada por um usuário publicador, todas as operações no esquema SDL foram preenchidas no portal do desenvolvedor e o arquivo de esquema também estará disponível para download. O desenvolvedor pode testar as operações usando o console Tryout com os tipos de solicitação GET e POST.

Funcionalidades na loja.

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 tela de visualizações

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

Tempo de invocação da 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 será encontrado em 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)

Aprecie seus pensamentos e contribuições valiosas sobre isso.

Obrigado!

Olá @HiranyaKavishani ,
Esse suporte introduz a publicação de APIs GraphQL existentes via APIM, como normalmente fazemos para APIs existentes via wso apim?

Também existe alguma versão Beta/Alfa para testar o recurso?

Obrigado !

Olá @arvindkannan ,

Para as APIs Graphql existentes, é necessário recriar as APIs e republicá-las, pois o graphql tem suporte diferente quando comparado às demais APIs. Mas, se fizer isso, deve ser necessário garantir que os tokens e URLs existentes não sejam alterados com isso, pois serão afetados aos clientes existentes.

O recurso estará disponível com o APIM 3.0.0, que será lançado em outubro.

Obrigado!

Feche o problema, pois este suporte está disponível na versão beta do APIM 3.0.0