IBM API Connect

API Connect is making GraphQL safer for the enterprise

By ROB THELEN posted Tue June 16, 2020 01:57 PM

  
IBM and API Connect are very happy to announce support for GraphQL proxies in API Connect and DataPower.  Check out GraphQL in the Docs here: DOCS

API Connect and DataPower add value in 4 huge ways to your GraphQL strategy:

1. You can add your GraphQL strategy TO your API Strategy.  Just add your GraphQL API to existing products, catalogs, and dev portals and your current users can use the Same API key, Oauth, or any global policies you have already set up.  From 0 to hero!  You can also have graphQL standalone.

2. One of the biggest reasons why enterprises have not gone live with their GraphQL projects are fear that queries will overwhelm their backend.  One GraphQL query could have the same backend load as 10,000 API Calls.  IBM has introduced a new type of rate-limit that focuses on the cost (backend cost) of a GraphQL transaction.  DataPower parses the graphQL query and determine the cost based on weights set in API Connect.  

3. Another concern is that the always agile digital side of the house will add new fields and types into GraphQL that should not be public.  API Connect and DataPower make it easy to control the schema at the Gateway level. Adding governance.  

4. API development debugging and API consumer "try it".  API Connect has the GraphiQL user-interface built into the new debug area of API Connect so API Developers can quickly test and iterate their GraphQL Proxies.  Additionally, the API Connect Developer Portal gives consumers the opportunity to try a GraphQL schema in a GraphiQL interface, a much more native experience. 

Some more background: 

GraphQL is a query language for APIs that gives an application client greater control over what data it retrieves in an API request when compared with a REST API request. 
IBM® API Connect enables you to create a GraphQL API proxy definition that proxies a backend GraphQL server, and to define rate limiting controls that reflect the amount of data that is returned from the server by a request to the GraphQL API.

GraphQL provides particular advantages over REST APIs:

  • The application client can request only the data that it needs. For example, when retrieving bank account records, request only the account number and current balance for each account, but not the customer name and address details. With a REST API request, either the backend REST service must provide separate endpoints for different data subsets, or the application client must retrieve the complete records and then discard the unwanted data.
  • The application client can retrieve multiple related resources in a single request. For example, a customer's bank account record might include an array that references other finance products that the customer holds. If an application client wants to retrieve the bank account details for a specific customer, and details of the other finance products for that customer, then with a REST API the client would first retrieve the bank account details, then make separate requests for each of the other products. A GraphQL API can be designed to allow the client to retrieve all this information in a single request.

However, this flexibility presents rate limiting challenges, because two seemingly very similar requests might return vastly different amounts of data, and what might have required multiple REST API requests, each counting towards the rate limit, might require only a single GraphQL API request. It is important therefore that rate limiting controls are imposed that reflect the amount of data that is retrieved. API Connect extends the GraphQL standard by providing, in a GraphQL API definition, the ability to configure a range of settings that are used to calculate the complexity of a GraphQL request and an associated cost that counts towards the rate limit.

Check out an end-to-end video below.  






Check out what else is new here: https://www.ibm.com/support/knowledgecenter/SSMNED_v10/com.ibm.apic.overview.doc/overview_whatsnew.html


0 comments
17 views

Permalink