Last week I was awestruck by the idea of using GraphQL in API’s. I was surprised how we can eliminate some of the RESTful problems in Microservices.
RESTful web services have inherent disadvantages like multiple round trips, over-fetching, and versioning. GraphQL addresses these concerns by shifting the non-essential complexities onto the client side. Wiring up custom endpoints to return data per client seems laborious in RESTful API’s.
GraphQL is a query language used to query for data against an API. Just like how we query the database using “select id, name, price from products”; GraphQL will allow us to query the API.
GraphQL is neither a database nor a storage engine. It is a pluggable component that can make our existing application “queryable”. What we accomplish from GraphQL can be custom coded with the same results. However, exploiting an existing framework would mean not re-inventing the wheel (again).
GraphQL enables us to get predictable results by following these 2 steps.
1. Describe your data.
2. Ask for what you want.
Describe your data:
With GraphQL, we define our model/schema using type system. We create a class and add all field types and names. These could be simple types like numbers, strings or complex types like objects or collection of objects. Also, as part of hydration, we create a query syntax class when we hydrate each field from its dependencies. This is ideal in cases where we have stitched together data from multiple downstream applications. Sometimes this may also require multiple round-trips.
Ask for what you want:
With GraphQL, the client is now responsible for specifying the data volume and as well as composition. Based on what was asked for, API will hydrate the response accordingly.
Say client only require product id and name, they only those 2 fields will be provided in response. Say client ask for id, name, and price — then it fetched from price API. This will reduce over-fetching and conserve server computer power.
Versioning:
With GraphQL, you will never require managing versions of API’s as you are free to add as many newer fields without affecting existing functionality. Your clients will continue to query for older fields and newer fields as well. This flexibility helps the development team make changes faster and with more confidence.
To read more about GraphQL visit the official docs at http://graphql.org/learn. By the way, there are now .NET libraries we could use to start using GraphQL in existing API’s.
Originally published at code.sagar.buzz on June 27, 2017.
