Optimising response
times with GraphQL
an experiment with MongoDB and ElasticSearch
(These slides were adapted to be suitable offline)
Intuitions: GraphQL faster
• less requests
• smaller responses
Reality Eats
Intuitions
for Breakfast
Not obvious
• Client has to send more info
• query contains list of fields
• -> biggest requests payloads
• Server has more work to do
• query validation
• customise response
Do not
guess it,
test it
–A client
“I want the id and the versions of all products”
30000 50000 100000
MongoDB ES
Perf of REST endpoints
query($offset: Int!, $limit: Int!) {
products(offset: $offset, limit: $limit) {
results {
id
version
}
}
}
In GraphiQL
GaphQL query
Client
App
Server
Data
storage
Optimisation between client
and application server
30000 50000 100000
MongoDB ES MongoDB GraphQL ES GraphQL
• smallest responses -> better performances
• difference not as important as expected
Client
App
Server
Data
storage
Optimisation between application
server and data storage
select * from products;
select id, version from products;
Optimise DB queries
http://sangria-graphql.org/learn/#projections
In Mongo
db
.getCollection('products')
.find({})
db
.getCollection('products')
.find({}, {_id: 1, version: 1})
30000 50000 100000
Mongo Mongo GraphQL Mongo GraphQL projections
In Elasticsearch
{
"_source": true,
"query" : […]
}
{
"_source": [ "id", "version"],
"query" : […]
}
30000 50000 100000
ES ES GraphQL ES GraphQL projections
30000 50000 100000
Mongo ES
Mongo GraphQL projections ES GraphQL projections
• Optimising database queries have an important
impact on performances
• GraphQL allows to optimise from client to data
storage
• Tested use-case intentionally picked to be
favorable to GraphQL (test assumption)
• Test yourself for your use-case
• Should not choose GraphQL primary for
performances but for features
Further optimisations
• Pre-computed queries
• client sends only values of variables
• queries already validated
• Binary serialisation format

Performance optimisation with GraphQL