9. Protection against complex queries
{
products {
results {
id
version
}
}
}
needs more resources to run
{
products {
results {
id
version
productType {
name
}
}
}
}
fetch the productType
10. Protection against malicious queries
• Query complexity analysis based on schema and resolution strategies
• Too complex queries are blocked
• more info:
• https://www.apollographql.com/blog/securing-your-graphql-api-from-
malicious-queries-16130a324a6b/
• https://sangria-graphql.github.io/learn/#protection-against-malicious-
queries
11. Add info to HTTP log entries
method path status code
GET /products 200
POST /carts 201
GET /reviews/79323 404
DELETE /product-discounts/47393 500
12. Add info to HTTP log entries
method path status code
POST /graphql 200
POST /graphql 200
POST /graphql 200
POST /graphql 200
operation
type
top level fields complexity
number of
errors
Query
products,
category
650 0
Mutation cart 140 0
Query review 340 0
Mutation productDiscount 500 1
14. Slow logs
• log slow queries
• ‼ do not log sensitive data ‼
15. Scaling up operations
• protection against malicious queries
• more info to http logs
• metrics
• slow logs
• confidence in operating a GraphQL API at scale
17. Internal usage
• Internal applications are using the GraphQL API
(merchant center, demo shop)
• shorter feedback loops
• improve API design
• Frontend and Backend working together
18. API consistency - schema validations
• General conventions for API consistency
• Internal validations based on the schema
[ERROR] Caused by: sangria.schema.SchemaValidationException: Schema does not pass validation. Violations:
[ERROR] Output object 'Category' contains a localized string field named 'name' which does not follow the 'xxx' !-> String + 'xxxAllLocales' !-> List(LocalizedString) naming convention.
[ERROR] at sangria.schema.SchemaValidationRule$.validateWithException(SchemaValidationRule.scala:42)
[ERROR] at sangria.schema.Schema.<init>(Schema.scala:939)
19. Automation of GraphQL Schema
• Our REST API is following a CQRS architecture
• different models for queries and mutations
• Based on this model, generate GraphQL schema
• Use schema introspection to test what is exposed
20. Automation of API release notes
• Production schema !== in development schema
• Based on the differences, generate markdown file for public release notes
22. Scaling up API development
• Faster feedback loops
• internal usage
• Faster development
• generating GraphQL types from REST API models
• schema validations for API consistency
• public release notes
• Using deprecations to evolve
• Graphql coverage is almost complete
28. Scaling up performances
• Give tools for users of the API
• Optimize database queries based on GraphQL query
• Inspect live servers
• Continuous process
29. Evolving a public Graph API
from experimental to production ready
needs investments in different areas