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

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 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