The first question I had when I started to work with GraphQL was off course: ‘What is GraphQL?’
GraphQL is one of the many available languages, more specifically a query language.
So, a query language almost says it all, it’s a language to query a provider of data for information.
When Facebook’s mobile app uses it, it must have something good to offer right? (That being said, guess who developed it!)
As a consumer the main benefit I realized instantly (though I personally use the language to write for the provider’s side) is that I can give a contract/schema to my consumers of an upcoming change, addition or an entirely new service I will be providing.
So, while I am still working on getting the API up and running, as a consumer you can already start working thanks to the contract: you will know how to structure the request, and if done correctly, what response to expect.
As such, consumer and provider can almost simultaneously start working and testing, that’s pretty neat! Plus, it’s a very uniform query language to boot; meaning there is no reason why you shouldn’t be able to produce data in Java, but consume for example in C#, Angular, whatever you like really!
Queries can be finetuned, so you only receive the data asked for and nothing extra, which is of course beneficial to both speed and stability. This can really simplify data transfer between two parties. With one simple GraphQL query, many resources can be returned which, if using REST for example, might need many calls to end up with the same result.
Finetuned and stable results would appear to be the language’s speciality. I am inclined to agree, though I cannot consider myself an expert yet but I can already see the benefits.
So, schemas, that’s one of the first things I mentioned and so it makes sense to continue my explanation with an example. Now I could think of my own, but why do that when https://graphql.org/ itself has already provided many good ones:
A schema contains all possible data a client can receive using the particular API it references to. This using objects structures not much unlike JSON, as shown below.
{
hero {
name
friends {
name
homeWorld {
name
climate
}
species {
name
lifespan
origin {
name
}
}
}
}
}
type Query {
hero: Character
}
type Character {
name: String
friends: [Character]
homeWorld: Planet
species: Species
}
type Planet {
name: String
climate: String
}
type Species {
name: String
lifespan: Int
origin: Planet
}
When a query (/request) comes in, GraphQL validates this query to the schema, to ensure it is something the service is providing and once validated without issue, the request can be executed.
Each field in the schema will be attached to a function and upon execution shall produce the value for the fields, using, in what GraphQL defines as, a resolver. Aside from all over this, the decision of how to store the data, what network to use etc. is left to the developer of either side. It also has very little requirements, which leaves your options as a developer wide open. Something you may love or hate, depending on how much you like having a lot of choice.
Most queries will follow the typical CRUD-operations, or mutations in this case. What else are we suppose to do with data, after all?
There are enough examples to find on the net, so I won’t bore you with any of those. But as a developer I found it rather fun to work with GraphQL, the fact it has a single source of truth (schema) and gives exactly what the consumer wants, makes it a lot easier to understand their needs as well.
An analyst can provide me a schema filled with objects of how a consumer would like to receive X, Y, Z and I can immediately start working. Miscommunication through faulty requests or responses is therefor also limited.
The logic beyond GraphQL, of course, requires more analysis, but that’s mysterious fun beyond its scope.
Also, something I forgot to mention, existing queries do not break when you decide to update them. It’s rather easy to deprecate certain fields but keep that version of the schema useable for a client.
While there might be plenty more to be said, this is mostly my experience from working with the language with a bit of research before I started doing so. If you’re a noobie like me when it comes to query languages, give it a go! It was surprisingly easy to pick up and really makes the communication side of client/provider a lot more pleasant.
