Optimising response times with GraphQLan 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
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 ESMongo 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
