In my last post, I explored the pros and cons of the current RESTful style. If you missed it, catch up here.
In this post, I’ll be answering the question: what is GraphQL and where does it come into play?
GraphQL is basically two things in one name:
- A simple query language for APIs
- A server-side runtime that can automatically parse and resolve those queries
Created by Facebook in 2012, it was publicly released in 2015 with other companies from the social landscape jumping onto the new hype, such as GitHub, Yelp or Twitter, plus some bigger players like PayPal and Sky.
The way it works is quite simple: you start by defining the schema that the engine should be able to respond against, which turns to be listed of nested object structures, ultimately becoming a graph (hence its name!).
Each object structure contains a list of typed fields, plus a set of functions to either encapsulate complex queries or even to ask for modifications in entities (“mutations”).
Once the schema is defined and made available to the server-side engine, it will be ready to start responding to queries from clients, automatically parsed by the engine – no need for manual filtering or sorting – and will delegate any backend datasource to modify or retrieve the raw information before processing it and sending it over the wire.
These pre and post processing capabilities make it much easier to implement on API using GraphQL. But wait, there are even more benefits!
Stay tuned for my next post, where I’ll look at: How does GraphQL solve some of the pain points currently found in RESTful APIs?
GraphQL will start responding to queries from clients, automatically parsed by the engine –no need for manual filtering or sorting– and delegating on any backend to modify or retrieve the raw information before processing it and sending it optimised over the wire