GraphQL Vs REST and What is GraphQl?
Hi, I am Malathi Boggavarapu working at Volvo Group and i live in Gothenburg, Sweden. I have been working on Java since several years and had vast experience and knowledge across various technologies.
In this post we discuss little bit about GraphQl versus REST.
My goal here is not to say REST is not good, use GraphQl. It's like more exploration of how we currently fetch data for apps right now and how GraphQl can help and what it does differently.
So i want to start with a simple UI component and walk through about how we get data to populate that component. Let's take an example of Shopping cart. See the below picture
We need lot of data to render the products in the above picture. So what kind of data exactly we need? If we see the picture we have Cart which hold some Products and each Product have title, descrition, price and bunch of other things and also the Product image which have Url of the image and it's metadata.
So we can make a REST call to get all sort of data about the Products to display for the user with just one REST call.
For example carts/1?expand=products could help you acheive this. Here we pass query parameter expand with value products. That works but you risk over-fetching because you only need the Price or Name of the Product but now you stuck with whole resource.
We can be little clever and ask for only the required fields instead of returning the whole Product resource. See below REST endpoint to acheive this.
/carts/1?fields=products(name, description, price)
But it is just only one level deep. If it has nested associations, it becomes little annoying because i have seen that sometimes Xpath being used.
Another Solution we tend to use is Custom endpoints. We can create custom endpoints where it gets all the required data. For example we can create an endpoint called /cart_with_all_stuff_i_need which returns all the stuff i need to show without passing query paramaeters. It works perfect but then there would be more custom endpoints added depending on data that we need to show on each single page. This approach becomes too messy and application becomes very hard to manage.
let's explore some examples of Custom endpoints:
If we need to show a page to the user where we need to display all the Products from the Cart we should create a custom endpoint /cart_with_all_stuff_i_need.
If we need to show a page to the user where we need to display only few products from the Cart then we should create an another custom endpoint /cart_version2_with_all_things
Similarly if we need to show a page to the user where we need to display only the products and images without price and taxes then we should create yet another custom endpoint /cart_with_products_and_images_without_price_taxes
And the list goes on like below
/cart_with_products_and_images_with_price_taxes_but_no_description
/cart_with_products_and_images_with_price_taxes_but_no_description_v2
So GraphQl is here to help us.
Actually let's start with what GraphQl is NOT. GraphQl is NOT a database. It is not a special kind of graph database. It is not a library. We can't install graphql for instant results. It's not language specific. It is not a Ruby thing or Javascript thing or Java thing.
It is query language that allows you to fetch like deeply nested associations. We select exactly what we want plus a specification for a service to execute these queries. So it is just a specification so you see implementation in Ruby, Javascript server and any other language.
The advantage of GraphQl over REST is the flexibility of the queries. We can query for very specific type of data, say only one property of the query like only the Firstname and not all the properties.
However GraphQl is not best solution in all cases.
If you are building small application or API, REST could be your much better approach. Consider the cost of developing the graphQl to versus the value it may provide. If you are going to scale an application beyond simple queries and already had a big implementation THEN Yes GraphQl may make sense. My advice to you is Start small with REST and Grow with GraphQl.
Hope the post is helpful.
In this post we discuss little bit about GraphQl versus REST.
My goal here is not to say REST is not good, use GraphQl. It's like more exploration of how we currently fetch data for apps right now and how GraphQl can help and what it does differently.
So i want to start with a simple UI component and walk through about how we get data to populate that component. Let's take an example of Shopping cart. See the below picture
We need lot of data to render the products in the above picture. So what kind of data exactly we need? If we see the picture we have Cart which hold some Products and each Product have title, descrition, price and bunch of other things and also the Product image which have Url of the image and it's metadata.
So we can make a REST call to get all sort of data about the Products to display for the user with just one REST call.
For example carts/1?expand=products could help you acheive this. Here we pass query parameter expand with value products. That works but you risk over-fetching because you only need the Price or Name of the Product but now you stuck with whole resource.
We can be little clever and ask for only the required fields instead of returning the whole Product resource. See below REST endpoint to acheive this.
/carts/1?fields=products(name, description, price)
But it is just only one level deep. If it has nested associations, it becomes little annoying because i have seen that sometimes Xpath being used.
Another Solution we tend to use is Custom endpoints. We can create custom endpoints where it gets all the required data. For example we can create an endpoint called /cart_with_all_stuff_i_need which returns all the stuff i need to show without passing query paramaeters. It works perfect but then there would be more custom endpoints added depending on data that we need to show on each single page. This approach becomes too messy and application becomes very hard to manage.
let's explore some examples of Custom endpoints:
If we need to show a page to the user where we need to display all the Products from the Cart we should create a custom endpoint /cart_with_all_stuff_i_need.
If we need to show a page to the user where we need to display only few products from the Cart then we should create an another custom endpoint /cart_version2_with_all_things
Similarly if we need to show a page to the user where we need to display only the products and images without price and taxes then we should create yet another custom endpoint /cart_with_products_and_images_without_price_taxes
And the list goes on like below
/cart_with_products_and_images_with_price_taxes_but_no_description
/cart_with_products_and_images_with_price_taxes_but_no_description_v2
So GraphQl is here to help us.
What is GraphQl?
Actually let's start with what GraphQl is NOT. GraphQl is NOT a database. It is not a special kind of graph database. It is not a library. We can't install graphql for instant results. It's not language specific. It is not a Ruby thing or Javascript thing or Java thing.
It is query language that allows you to fetch like deeply nested associations. We select exactly what we want plus a specification for a service to execute these queries. So it is just a specification so you see implementation in Ruby, Javascript server and any other language.
The advantage of GraphQl over REST is the flexibility of the queries. We can query for very specific type of data, say only one property of the query like only the Firstname and not all the properties.
However GraphQl is not best solution in all cases.
If you are building small application or API, REST could be your much better approach. Consider the cost of developing the graphQl to versus the value it may provide. If you are going to scale an application beyond simple queries and already had a big implementation THEN Yes GraphQl may make sense. My advice to you is Start small with REST and Grow with GraphQl.
Hope the post is helpful.
Comments
Post a Comment