Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

APIdays Helsinki 2019 - Beyond REST: GraphQL API Management with Amit Acharya, IBM

75 views

Published on

Beyond REST: GraphQL API Management, Amit Acharya, Head of Product – API Management (API Connect) & Gateways at IBM

Published in: Technology
  • Be the first to comment

  • Be the first to like this

APIdays Helsinki 2019 - Beyond REST: GraphQL API Management with Amit Acharya, IBM

  1. 1. IBM Confidential GraphQL API Management Amit P. Acharya Head of Product – API Management (API Connect) & Gateways IBM linkedin.com/in/amitpa @amitacharya
  2. 2. The Next 35 25 minutes… 2 1. Why GraphQL? It’s for the end-user silly! 2. Wait..What about REST? It isn’t going anywhere 3. SoWhat’sAPI Management for GraphQL? It’s no rocket science
  3. 3. REST Get ../books/ Get ../authors/ Get results. Iterate to display “My favorite authors” GraphQL – The Value GraphQL Query { Books { author { … } Benefits for API Consumer • Get exactly what you ask for • Query in. Result out • Roundtrip reduction
  4. 4. • Do we really need GraphQL? • Technology is always providing developers new solutions to existing problems • Lets step back and understand how we got here The Need…
  5. 5. • API interface represents the “contract” (ie WSDL) created by the API Provider • API Provider exposes contract for API consumer • API Consumer consumes service based on “the contract” The 1.0 of APIs == Service Oriented Architecture (SOA)
  6. 6. • API Provider controls the service interface • API Consumer does not have much input into the design of the “contract” Advantage: API Provider
  7. 7. • API interface represented by open standard (OpenAPI), JSON payloads, YAML configurations • API Provider exposes standard RESTful interface • API Consumer discovers APIs via self-service onboarding and developer portal The 2.0 of APIs == REST
  8. 8. • API Provider engages API Consumer in API design • API Provider provides simpler interface of service implementation • API Consumer consumes APIs via self-discovery and use modern standards Advantage: API Provider and API Consumer
  9. 9. • Query language and implementation paradigm for data-centric APIs • API Consumer defines the data they need (and nothing more) • API Provider handles complexity of obtaining data from backend systems The 3.0 of APIs = GraphQL and Async Endpoints
  10. 10. • API Consumer maintains control over the data definition • API Consumer does not care about the internal data structure within systems • API Provider endpoint completely driven by API consumer needs Advantage: API Consumer
  11. 11.  In GraphQL, profiles, or resource access rules depend on the query: POST ../graphql { me { name, age }} POST ../graphql mutation { createK8Cluster (name: "c1"){ clusterId } } vs. GET …/profiles/me vs. POST …/resources/k8cluster  In RESTAPIs, profiles, or resource access rules are defined for endpoints: Question: Is GraphQL replacing REST? • No. RESTAPIs are well-defined interfaces with standard error codes • Easily cached and optimized for the HTTP protocol GraphQL provides an alternative query-based approach, optimized for data-intensive operations REST v/s And GraphQL
  12. 12. • SingleGraphQL transaction may invoke multiple backends POST /sports/graphql? HTTP/1.1 query { Players (name: "John T") { name league team { name arena { name … } city } }} Server 1. GET …/players/ 2. GET …/team/player.name=? 3. GET …/arena/team.name=? GraphQL Endpoints De-constructed
  13. 13. • Learnings from query languages (i.e. SQL) • Can a “poor Query” overwhelm backend systems? • Bad queries can be malicious or unintentional Select * From Transactions SELECT cust.name, address.name, …. {infinite attributes} FROM cust, address, … {infinite tables}, WHERE cust.name = address.name AND …. {infinite joins} Selecting all data from a database Complex and nested queries with multiple table joins Queries And Implications
  14. 14. • Multiple nested backend calls triggered by single GraphQL API call • Throttling – Protect backends when system usage spike • Variable compute time to resolve query depends on query complexity • Rate limits provide ability to limit number of transactions per consumer Server Protection Via Throttling & Rate Limits
  15. 15. • Threat Protection • Rate Limit • Versioning & Lifecycle API Management of GraphQL
  16. 16. GraphQL Management Runtime gateway Init introspection query (if allowed) Server Policy definition & configuration policy, config Policy enforcement query inspection Query inspection Static analysis GraphQL client GraphQL Management
  17. 17. { "maxNesting": 2, "operationType": "query", "resolveCounts": { "query:users": 1, "user:employerCompany": 5 }, "typeCounts": { "user": 5, "company": 5 }, "typeComplexity": 10, "resolveComplexity": 6 } Think threat prevention… Think rates… Think access control or pricing… Query Analysis For Protection and SLA
  18. 18. • Detect and reject requests with complex nesting • Pre-calculate load to determine if query will overwhelm backends • Use point/weight system to calculate “cost” for different query parameters (e.g. GitHub GraphQL APIs) Threat Protection
  19. 19. Essentials Business (includes Essentials) Enterprise (includes Business) { REST } API Plans
  20. 20. Gold Platinum Levels = 10 Levels = 100 Differentiated API Plans
  21. 21. • GraphQL enables API consumer to easily retrieve exactly the data it requires (from data intensive backends) • GraphQL management requires insight into the impact of a query on backend systems • GraphQL API management enables differentiated API plans & new threat protection policies Summary

×