Would you like to ascend your development process to the next level? Is GraphQL another buzzword or will it replace REST like REST replaced SOAP?
What GraphQL is
The most important thing to mention is that GraphQL is not another framework! It’s a query language and execution engine created in 2012 by Facebook. GraphQL’s specification (in short: description of behaviors, data format, etc.) became an open standard in 2015.
One can even boldly say that this is the way we think of creating applications.
Making it simple, a typical GraphQL API consists of the following components:
- Schema – core, it describes types and capabilities of API
- Query – root type for queries (data fetching)
- Mutation – root type for mutations (modifying data)
We are constantly using GraphQL on both client and server sides.
For .NET projects, we use HotChocolate (https://hotchocolate.io/) framework with all .NET features cooperating greatly with the GraphQL.
For node and frontend projects – we get well along with Apollo (https://apollographql.com/).
Top reasons to use it in your next project
Strongly typed schema
For me, a long-time C# veteran, the coolest thing is a type system. It’s a lot less error-prone compared to the classic REST approach, and fewer bugs means less time spent on fixing them.
API straightforwardly defines allowed operations and data models.
The type system allows us to generate some parts of code, letting the development team focus on your specific problems (not infrastructure ones), and further increase development speed.
What you query for is what you get
Let’s assume that we are creating another blogging application. Imagine that we have a page which displays multiple blog entries and the respective author’s name.
In classic REST API we would have some set of endpoints, e.g.:
GET posts
GET author?{id}
Frontend will request for a list of posts and for each post’s author respectively.
In this case, the so-called underfetching occurred. It means that one endpoint cannot supply us with the required amount of data and it leads to performing additional, unnecessary requests (in our case – querying for author’s name).
However, at the same time, the so-called overfetching occurred because we have transferred all the author’s data, including those currently redundant (the author may have such things as a photo, description, etc.)
What could a similar graphql query look like?
query GetPostsWithAuthorNames { posts { title content author { name } } }We are explicitly declaring what we want to receive from API.
Better overall performance
Performing one round trip to a server, in most scenarios, is much more performant than doing multiple requests. Not to mention that less data is transferred over the network.
In REST api you could have something like user/basicdata and user/details to preserve some transfer but due to REST API nature – it leads to code bloating.
Hosting GraphQL API in the cloud might be cheaper than its REST equivalent!
Versioning
In REST APIs versioning is based on duplicating the code and endpoints (v1/users, v2/users etc.).
GraphQL API is backward compatible. You can freely expand it as you wish because API consumers can query what they would like to get.
It requires a lot less effort to evolve your GraphQL API which basically means a faster development process.
And after some time, you can freely drop the deprecated field.
Documentation
Thanks to the strongly typed schema, we are able to generate documentations with “one click”.
Existence of tools like GraphiQL or GraphQL Playground grants us a possibility to write queries with autocomplete help, view schema, and docs.
On the other hand, GraphQL Voyager generates a beautiful schema visualization/map.
Simpler and more beautiful code
Code, on both server and client-side, is much more brief and simple which in consequence means it’s easier to maintain and modify. Simple code is also a morale booster for the development team.
…And there are no endpoints so frontend and backend devs aren’t fighting for API structure (that much).
Flexibility
Still, remember the blog posts with the author’s name example? What if we would additionally display the author’s description and his few top-rated posts?
In GraphQL, we might be able to do this without touching a server-side, while in classic REST approach it would probably end with expanding one endpoint (which might be inappropriate) or adding another one.
Making changes is just easier and faster.
Let’s assume we would like to rebuild the whole app layout. Due to the flexibility of GraphQL and it’s queries – probably we might be able to avoid complex works on the server-side.
This basically means that frontend work can start right away!
Rapid MVP development
Taking into account the flexible nature of GraphQL, it fits well with rapid MVPs development, where many requirements may change during the work.
Microservices…
This is where GraphQL shines brightly! Thanks to so-called schema stitching (or Apollo Federation for node implementation) – we are able to simplify communication with server-side applications by joining services into one.
This basically means that the frontend apps are querying data from one API.
Schema stitching allows us to stitch a legacy API and hide it behind GraphQL schema too!
If you’re curious about other insights from our team of developers, check the Development section in our blog.
