Support for graphql

[YannickB]

Hello all,

I'd like to know if any strong support for GraphQL APIs is planned for the future of WSO2 ? GraphQL has an ever growing adoption among API developer with strong arguments against REST.
There is a lot of great tools for GraphQL today, but imho the big bottleneck for massive adoption is the very poor support by API gateways today.

Of course it still works. A GraphQL endpoint is REST compliant, you just have to create a REST endpoint on WSO2 APIM. But today this is far for optimum and by design you can't use correctly most of WSO2 APIM features.

The reason is, you usually have the whole schema of your API cluster in a single endpoint. Even if you have dozens of microservices serving their own GraphQL APIs, the good practice is to aggregate them through an API router like Apollo tools https://www.apollographql.com/docs/graphql-tools/schema-stitching.html.

Because of this, we can't properly use throttling and monetization features in WSO2, which are configured by endpoint but in GraphQL we want to be able to configure them by GraphQL functions. Configuring an GraphQL endpoint today defeat most of the usefulness of an API gateway, except maybe for the anti-DDOS needs.

I'd love to be able to create my GraphQL microservices, aggregate them with an Apollo server and properly securing, monetize and monitor with WSO2 gateway. I understand this is a lot of work, but today the support for GraphQL APIs among API gateways is so poor that I hope this can be a strong competitive advantage for WSO2 and a big opportunity. Even for analytics, today there is no open-source analytics for GraphQL, the only analytics I can think is apollo Optics and it's closed-source.

Thanks for listening to my point, I'm looking forward to know more about your roadmap if this is something planned.

Best regards,

[marcboivin]

+1

[jcoa]

+1

[calvma]

+1

[7ou7a7es]

+1

[hansbot]

+1

[ilya86oz]

+1

[febinrejoe]

👍

[nuwand]

Hi @YannickB,

Thanks for bringing this up. We would like to add this to our roadmap.

I haven't used GraphQL much and hence having some trouble understanding the exact scope of the requirement. For some clarity, could you explain the exact limitations of the current functionality using an example maybe? Basically what is exposed through the Apollo server and how would you have to expose this through the API Gateway today vs what would have been the ideal way of exposing it through the API Gateway.

Thanks,
Nuwan.

[vijay-sundareshwaran]

+1

[YannickB]

Hi @nuwand,

First as disclaimer, even if I opened the ticket I'm not sure I am the best person to describe how the feature should work. Think of me as someone studying to build a really good software architecture, so including stuff like GraphQL and API Gateway, and as I was studying this I became obvious to me that no API Gateways on the market today was designed to fully support GraphQL. Hence I have no real use case in production as of yet, but I'll do my best to help.

I agree the best way to explain will be an example so here it is :

Let's say you have an API providing CRUD functions for two objects, product and invoice.

With a Rest API, you'd have two endpoints to use, http://myapi.com/api/product and http://myapi.com/api/invoice, and you then do GET/POST/PUT/DELETE operations on them.
In WSO2, you can configure each endpoint independently, one for product and one for invoice, and then give a specific configuration for each of them to manage independently the security/throttling/monetization/etc... features provided by WSO2.

But if we are providing a GraphQL API we are currently much much more limited. This is due to the fact both objects will be accessible in the same endpoint http://myapi.com/graphql. And there is no way to create several endpoints http://myapi.com/graphql/product and http://myapi.com/graphql/invoice, this is completely anti-pattern with the best practices of GraphQL and will make most the tools in its ecosystem to stop working. Moreover, I believe all HTTP operations are POST.

So as example, we may want to do theses requests on the GraphQL endpoint :

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

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

The first request will query the informations of the specified product, and the second will create an invoice for this product. Both queries are executed on http://myapi.com/graphql endpoint.

So with current state of WSO2 Gateway, which if I'm not wrong only allow to configure per endpoint, if I want for example to monetize at 0.01cent each call to createInvoice by configuring the http://myapi.com/graphql endpoint, then the call to product will also be monetized at 0.01cent. With REST, you'd just configure the 0.01cent to the http://myapi.com/api/invoice on POST and that would be all.
I hope this is enough for you to understand my point, this is a simple example but we can find plenty others, at current state it's impossible to use the Gateway features with GraphQL due to lack of flexibility in configuration. And it's not your fault, I believe all other API Gateway in the market have the same problem.

So the solution IMHO is allowing to attach WSO2 configuration not only to endpoint, but to GraphQL functions as well. This may prove to be a technical challenge I think, but there is definitely a need for this in the market because currently GraphQL just does not work with API Gateways, or in a very degraded way.

It seems this suggestion attracted quite some attention. To people following this issue, I invite you to give some informations about your use case and how WSO2 should design this feature. I hope I did my best to describe the situation, but I believe they'll need some real example to properly implement this.

Best regards,
Yannick

[ghost]

As temporary solution it would be great to have at least possibility to import in WSO2-AM graphql endpoints, in order to use it as Service Directory while waiting for a full support into the API Gateway

[nuwand]

Hi @YannickB,

Thanks for you explanation. Forgive me, but I'm still trying to figure out the limitations with the endpoints. Let me explain the capability API Manager has with regard to endpoints and then maybe you can pin point the limitation.

Assume you have two endpoints as http://myapi.com/api/invoice and http://myapi.com/api/product. Note that I'm using the same example as you did, on which both endpoints seem to be on the same host (myapi.com). If your requirement is to have a single API on API Manager to proxy both endpoints, what you have to do is to create two resources, one as POST /invoice and the other as POST /product and specify http://myapi.com/api/ as the endpoint of the respective API. This will enable you to access both endpoints above using a single API. For example, if your gateway host is gateway.myapi.com and the context of the API you create is /graphql and its version is 1.0.0, the following requests would proxy each to the appropriate endpoint as below.

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

Note that you only have to create 1 API (/graphql/1.0.0) to proxy both endpoints. I'm sorry if I'm repeating something you already know :), but if you could pin point the limitation on our resource to mapping that makes it impossible to use GraphQL that would help me to understand the problem better.

Thanks,
Nuwan.

[bartvanvlierberghe]

nuwand, i'm less technical than you. But in my understanding with an APIM / Identity server we define on API Level the management of an API (security, throttling, ... ..) . GraphQL is a kind of 'super' language combining API's via a 'meta' language . What would be of interest of me is to understand how the concepts of GraphQL and the concepts of a WS02 APIM is matched. and if both concepts will be integrated. Offcourse you can consider the GraphQL als 1 resource which itself manage everything .... but than the value of WS02 is limited if all my 'legacy'services will be accessible via the graphql server.

[vinnyvoffice]

+1

[fourth44]

With GraphQL, there really is only a single endpoint, so there is no such thing as myapi.com/graphql/invoice and graphql/product, the endoint is just "myapi.com/graphql", and nothing after that. It is literally the same URL for each query and mutation, with the operations defined inside the body of the request.

Some api management features then would require introspection of the request body, knowledge of the graphql schema, etc. Let's assume that this is not feasible on a short term: WSO2 should almost become a GraphQL server/gateway in itself (or integrate one).

Instead, we should focus on what API management features are possible. I guess we need co-operation between WSO2 and the actual GraphQL server/gateway, e.g. by setting headers. For example monetization: the GraphQL server can compute the complexity of the query, add this information as a HTTP header to the response, where WSO2 translates this value into a price. Similarly for monitoring, the GraphQL server can 'convert' the JSON-shaped query into (a list of) rest-like pseudo-endpoint(s), which WSO2 reads from the response header to update the monitoring information. The same thing can be done for security, maybe in 2 phases: 1st ask the GraphQL server to convert the query into rest-like endpoints, WSO2 decides to pass or not, forwarding the query to the actual endpoint.

I'm completely new to WSO2 and haven't read most of the documentation, so maybe these features are already in WSO2 (more specifically: for any functionality of WSO2 that is usually derived from the exact REST endpoint URI, whether that same functionality can be derived in a alternative way (e.g. a header value or some other API to WSO2 itself)). It is likely that a GraphQL server needs to be modified to support these WSO2-specific features. The question is: what low hanging fruit can we start with?

(Of course I would like to see WSO2 make a big commitment into GraphQL... but we need to start somehwere, right?)

[bartvanvlierberghe]

Great feedback , i feel the same ;) Op di 6 nov. 2018 om 12:06 schreef fourth44 <notifications@github.com>:

…

With GraphQL, there really is only a single endpoint, so there is no such thing as myapi.com/graphql/invoice and graphql/product, the endoint is just "myapi.com/graphql", and nothing after that. It is literally the same URL for each query and mutation, with the operations defined inside the body of the request. Some api management features then would require introspection of the request body, knowledge of the graphql schema, etc. Let's assume that this is *not* feasible on a short term: WSO2 should almost become a GraphQL server/gateway in itself (or integrate one). Instead, we should focus on what API management features *are* possible. I guess we need co-operation between WSO2 and the actual GraphQL server/gateway, e.g. by setting headers. For example monetization: the GraphQL server can compute the complexity of the query, add this information as a HTTP header to the response, where WSO2 translates this value into a price. Similarly for monitoring, the GraphQL server can 'convert' the JSON-shaped query into (a list of) rest-like pseudo-endpoint(s), which WSO2 reads from the response header to update the monitoring information. The same thing can be done for security, maybe in 2 phases: 1st ask the GraphQL server to convert the query into rest-like endpoints, WSO2 decides to pass or not, forwarding the query to the actual endpoint. I'm completely new to WSO2 and haven't read most of the documentation, so maybe these features are already in WSO2 (more specifically: for any functionality of WSO2 that is usually derived from the exact REST endpoint URI, whether that same functionality can be derived in a alternative way (e.g. a header value or some other API to WSO2 itself)). It is likely that a GraphQL server needs to be modified to support these WSO2-specific features. The question is: what low hanging fruit can we start with? (Of course I would like to see WSO2 make a big commitment into GraphQL... but we need to start somehwere, right?) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3184 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Ad4tuNmWvNcpkc1Nk5y46DljcQeM9RPwks5usW0kgaJpZM4TLf2Q> .

-- Bart Van Vlierberghe

[stfgit]

Hello,
Here is an extract of the Apollo Server documentation:
"If you’re using a REST API that has built-in authorization, like with an HTTP header, you have one more option. Rather than doing any authentication or authorization work in the GraphQL layer (in resolvers/models), it’s possible to simply pass through the headers or cookies to your REST endpoint and let it do the work."
If the API key is the same for all endpoints involved by your graphql queries, it seems that could do the trick.
Any thoughts about this "workaround" (put Apollo server in front of API-M) ?

[wasuradananjith]

Requirement Analysis

• GraphQL is developed by Facebook which is an alternative to REST. It is a query language for APIs where a particular user can specify exactly what data is needed from an API.
• We know that we can use a Swagger Definition (Open API Specification) to design a REST API. But in GraphQL, we can use Schema Definition Language (SDL) to write the schema for a GraphQL API.
• Invoking a GraphQL API simply means fetching data using GraphQL queries and writing data using GraphQL mutations.
• In here our requirement is to give the support from WSO2 APIM in order to create and publish a GraphQL API and to invoke it over https/http.

Suggested Approach

• When publishing a GraphQL API we request the user (publisher) to upload the schema file which consists the definition. Then the user can fill the details about the API such as name, version, context etc. But user will not be asked to create the resources for GET, POST methods when creating the API.
  

• Next, in the Implement tab, if user selects,

  • Manage API

    • Endpoint Type should be set to HTTP/REST Endpoint automatically. (The user must not have the ability to change this)
    • User must have the ability to change the Endpoint (Production and Sandbox) as usual.
    • Other fields should remain the same.
      

  • Prototyped API

    • In Inline implementation method, two GET and POST methods must be automatically created and displayed as displayed in the following screenshot.
      

• If you choose Manage API option then you have to set the settings in Manage tab.

  • In here the same procedure must be followed.
  • Specially as in Inline prototype method, two GET and POST methods must be automatically created and displayed as in the following screenshot.
    

• After the API is published or prototyped

  • The API should be labeled as a GraphQL API in API Store.
  • A consumer must have the ability to download the schema file of that API through API Store.

[berlotti]

Looks great

[nuwanbando]

@wasuradananjith can you also post how a GraphQL API looks like in the store ? Is querying available in the API Portal, probably with the schema ?

[tomdavidson]

At least Apollo supports using GET for the GraphQL data request.

[HiranyaKavishani]

Hi all,

Please find the information and PR of Graphql support related to the WSO2 APIM 3.0.0 release. Since we are going to release WSO2 APIM 3.0.0 under a new React-based UI, screenshots of new UI have been added in follows.

API publisher
Description:
When API creator uploads graphQL schema into API publisher, query and mutation operations will be listed in the publisher portal. Then he/she will allow to defines the scopes, throttling policies, enable/disable security against the operations.

Functionalities at the publisher.

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
Once the API is published by a publisher user, all the operations at the SDL schema have been populated at the developer portal and the schema file also available to download. Developer can test the operations using Tryout console with GET and POST request types.

Functionalities at the store.

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 of views

1. Create GrpahQL API page

2. Upload schema page

3. Click next and populate a form to fill details

4. Created GraphQL API overview page

5. GraphQL API operation view

6. Uploaded schema definition

7. Add/Update scopes,throttling,security

8. Store operation overview

9. Schema download

10. Developer Console

Invocation time of 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 will be found at 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. Enable GraphQL API management to perform static query analysis for Rate Limiting #5432
2. Support GraphQL Subscriptions for inbound Endpoints #5431
3. Support API Micro Gateway for GraphQL backends product-microgateway#773
4. Support APIM Analytics for GraphQL APIs analytics-solutions#310

Appreciate your thoughts and valuable inputs regarding this.

Thanks!

[arvindkannan]

Hi all,

Please find the information and PR of Graphql support related to the WSO2 APIM 3.0.0 release. Since we are going to release WSO2 APIM 3.0.0 under a new React-based UI, screenshots of new UI have been added in follows.

API publisher
Description:
When API creator uploads graphQL schema into API publisher, query and mutation operations will be listed in the publisher portal. Then he/she will allow to defines the scopes, throttling policies, enable/disable security against the operations.

Functionalities at the publisher.

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
Once the API is published by a publisher user, all the operations at the SDL schema have been populated at the developer portal and the schema file also available to download. Developer can test the operations using Tryout console with GET and POST request types.

Functionalities at the store.

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 of views

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

Invocation time of 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 will be found at 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)

Appreciate your thoughts and valuable inputs regarding this.

Thanks!

Hi @HiranyaKavishani ,
Does this support introduces publishing existing GraphQL API's via APIM like we normally do for existing API via wso apim ?

Also is there any Beta/Alpha Release to test out the feature ?

Thanks !

[HiranyaKavishani]

Hi @arvindkannan,

For the existing Graphql APIs, it is needed to recreate the APIs and republish since the graphql has different support when it compared to the rest APIs. But If do so, it should need to make sure that existing tokens and existing URLs are not going to change with this as it will be affected to existing customers.

The feature will available with APIM 3.0.0 which will be going to release in October.

Thanks!

[HiranyaKavishani]

Close the issue as this support available in APIM 3.0.0 Beta version