graphqlapi management through static analysis · 2019-01-03 · § in graphql, rates, prices, or...
TRANSCRIPT
© 2018 IBM Corporation
GraphQL API Management Through Static Analysis
Erik Wittern, Alan Cha, Jim Laredo, Louis Mandel, and Guillaume BaudartIBM Research
2Page© 2018 IBM Corporation
GraphQL is a query language and implementation paradigm for data-centric web APIs
{user (id: “123”) {nameaddress: { street }
}}
GraphQL query (sent via HTTP POST);adheres to server’s schema
{“data”: {“user”: {
“name”: ”Erik”,“address”: { “street”: “E 10th St.” }
}}
}
Response with requested data
ServerClient
3Page© 2018 IBM Corporation
A challenge for managing GraphQL backends is to
understand what requests intend to do
§ API Management provides threat prevention, rate limiting, pricing, access control etc.
§ In GraphQL, rates, prices, or access
rules depend on the query:
POST ../graphqlquery { me { name, age }}
POST ../graphqlmutation {
createK8Cluster (name: "c1"){clusterId
}}
vs.
GET …/profiles/me
vs.POST …/resources/k8cluster
§ In REST APIs, rates, prices, or access
rules are defined for endpoints:
4Page© 2018 IBM Corporation
Demo
5Page© 2018 IBM Corporation
Static analysis provides basis for defining higher-level policies
{"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…
{users (limit: 5) {
nameemployerCompany {
name}
}}
6Page© 2018 IBM Corporation
We decouple GraphQL management from GraphQLserver implementations
GraphQLManagement
Runtime gateway
Initiali-zation
introspection
query(if allowed)
Server
Policy definition & configuration
policy, config.
Policy enforcementquery
inspection
Query inspection
Static analysis
schema
GraphQL client
7Page© 2018 IBM Corporation
We find our static analysis succeeds to determine complexity upper bounds
Evaluation based on 3040 randomly generated queries against the GitHub GraphQL API v4
Thank you!
9Page© 2018 IBM Corporation
(Some) advantages of GraphQL§ Developer experience
• Exploring API with tools like GraphiQL• Documentation is always in sync with the
implementation• Aliases allow bridging of syntactic gaps• Typed interface helps avoid errors• API evolution
– Extending schema does not break (even strongly typed) clients
– Deprecation messages built-in
§ Optimized payload-size (think mobile apps)§ Reduced roundtrips (clients) and unneeded
data-lookups (providers)§ Resource composition (APIs, DBs, cloud
functions…)
query result
docs
10Page© 2018 IBM Corporation
Processing times – JavaScript implementation, GitHub experiments, on 2014 15” MacBook Pro
Query processing percentiles:0.90 0.9 ms0.95 22.68 ms0.99 262 ms
Response processing percentiles:0.90 2.28 ms0.95 24.2 ms0.99 176.46 ms
12Page© 2018 IBM Corporation
GraphQL trade-offs
+ Query related data in single request (àless roundtrips)
+ Fine-grained control over what data to return (à smaller responses)
+ Typed schema helps avoid bugs+ Great client tooling (especially GraphiQL)+ Documentation built-in & always in sync+ Great insights into customers’ data-needs
- No HTTP caching (GraphQL uses POST) à caching in frontend required
- GraphQL API management is (still) challenging:• What are the implications of a query?• How to control / react to them?
- File uploads not natively supported- Response structure determined by query
structure- GraphQL may be overkill in certain cases
13Page© 2018 IBM Corporation
When is GraphQL a good fit?
§ APIs for interacting with data – not APIs used to control functionalities or resources
§ APIs offering nested data, where GraphQL can avoid multiple roundtrips
§ APIs offering small or preprocessed data – data in GraphQL is normalized, so large
volumes are a bad fit – GraphQL is not a data-analysis tool
§ APIs being used by multiple clients, with diverse and/or changing requirements§ APIs that compose multiple systems / backends, whose data is related to another
§ APIs that evolve over time§ Up-to-date, correct documentation matters
§ Exemplary bad fit: APIs for…
• Executing functionalities (e.g., managing
resources, controlling/configuring systems,
payment systems etc.)
• Flat data
§ Exemplary good fit: APIs for…
• Fetching data for UIs
• Social networks, news feeds
• Connected, graph (-like) data