Introducing GraphQL at a Party
GraphQL and REST are two paradigms used to create APIs for web applications.
REST is a set of unique identifiers (URLs) that applications use to request and send data.
GraphQL is a query language that allows client applications to precisely specify the data they need from a single endpoint.
These are related technologies, they are used mainly for the same things (or they can coexist), but they are very different.
Sounds a little fresh, right? Let's explain their differences in a more interesting way, which can help you better understand GraphQL, and maybe just amuse it.
You came to the party to do networking, so you need information about the people around you. There are five more guests nearby.
Their name stickers are as follows:
Richy REST
Friend of Richy REST
Employer of Richy REST
Georgia GraphQL
Being an active and sociable party-goer, you go straight to Richie Rest and say: “Hi, I’m Adam Epilation, and who are you?” Richie Rest’s answer is:
You thought to yourself, “Wow, too much information right away.” Trying to avoid awkward silence, you recall that Richie Rest mentioned that he works, and asks: “Where do you work?”
Surprisingly, Richie Rest has no idea where he works. Maybe employer Richie Resta in the know?
You ask the same question to Employer Ritchie Resta, who is happy to answer your question:
By this moment you are already exhausted. You don’t even want to meet a friend of Richie Resta! It can take forever, waste all your energy, and besides, you no longer have time.
However, Georgia GrafKewel stands very close by and you decide to chat with her.
"Hi what's your name?"
"Where are you from and how old are you?"
“How many hobbies and friends do you have and what is the name of your friends?”
Georgia GrafKewEl is incredible, clearly articulates thoughts, concise and accurate. You definitely want to exchange business cards with her and work together on future projects.
This story includes the experience of developers working with GraphQL and REST. GraphQL allows developers to formulate what they want with a neat query and get only what they specify in response. These queries are dynamic, so only one endpoint is required. REST, on the contrary, has predefined answers and requires applications to use multiple endpoints to fully query the data.
For further disclosure of the concepts presented in the metaphor of the party, we turn specifically to the two limitations that often arise when using REST.
1. Multiple hits on getting related resources
Data management for mobile and web applications often requires related resources and data sets. Thus, obtaining data using the REST API can entail numerous requests for multiple endpoints. For example, a Post request and its associated Author can be made by two requests to different endpoints:
Repeated calls to the API affect application performance. This is even more important for devices with low bandwidth (for example, smart watches, IoT, old mobile devices, etc.).
2. Over-fetching and under-fetching
Over-fetching / under-fetching is inevitable when using the RESTful API. Using the above example, the domainName.com/posts/:id endpoint retrieves data for a specific record. Each entry consists of attributes such as id, body, title, publishingDate, authorId, and others. In REST, a response is predefined and the same data object is always returned.
In situations where only the title and text of the recording are required, over-fetching occurs because more data is sent over the network than is actually used.
When the entire publication is required, along with related data about its author, there is insufficient under-fetching - because less data is sent over the network than is actually used. Insufficient under-fetching of data leads to an increase in the number of API requests and, as a result, excessive use of Internet resources.
GraphQL presents a unique approach that gives tremendous flexibility to client applications. With GraphQL, the request is sent to your API, and exactly what you need is returned - no more, no less - in one request. The query results are returned in the same form as the query itself, ensuring that the response structure is always predictable. These factors allow applications to run faster and be more stable as they control the data they receive, not the server.
Now you probably think that working with GraphQL is as easy as slicing warm butter with a samurai sword. This may be true for front-end developers. However, when it comes to configuring the server side, someone has to do the most difficult work. Our friend Georgia GrafKewEl has put a lot of effort into becoming a classy professional.
Creating the Server side GraphQL API takes time, effort, and experience. Nevertheless, those who are ready for testing are able to cope with this. There are many different ways to do this, for example:
On your own : if you really want to do everything yourself, try building the GraphQL API with packages. Using Rails? Try graphql-ruby. Love Node.js? Try express-graphql.
With : if flexible hosting setup is your priority, something like Graph.cool can help you get started with the GraphQL project.
Instant : Tired of writing a CRUD template and want to get started quickly? 8base provides an instant GraphQL API and a server backend that can be extended.
For web services, REST was a significant step forward, making it easy to create APIs to access the necessary resources. However, its design did not take into account the current proliferation of mobile devices, with various restrictions on data download volume and requirements. This omission led to the growing popularity of GraphQL, which Facebook made open source in 2015, primarily due to the flexibility that it gives front-end developers. Working with GraphQL is a fantastic experience for both individual developers and teams.
REST is a set of unique identifiers (URLs) that applications use to request and send data.
GraphQL is a query language that allows client applications to precisely specify the data they need from a single endpoint.
These are related technologies, they are used mainly for the same things (or they can coexist), but they are very different.
Sounds a little fresh, right? Let's explain their differences in a more interesting way, which can help you better understand GraphQL, and maybe just amuse it.
Are you at a cocktail party
You came to the party to do networking, so you need information about the people around you. There are five more guests nearby.
Their name stickers are as follows:
Richy REST
Friend of Richy REST
Employer of Richy REST
Georgia GraphQL
Being an active and sociable party-goer, you go straight to Richie Rest and say: “Hi, I’m Adam Epilation, and who are you?” Richie Rest’s answer is:
{ name: "Richy REST", age: 33, married: false, hometown: "Circuits-ville", employed: true // ... 20 other things about Richy REST }
You thought to yourself, “Wow, too much information right away.” Trying to avoid awkward silence, you recall that Richie Rest mentioned that he works, and asks: “Where do you work?”
Surprisingly, Richie Rest has no idea where he works. Maybe employer Richie Resta in the know?
You ask the same question to Employer Ritchie Resta, who is happy to answer your question:
{ company: "Mega Corp", employee_count: 11230, head_quarters: "1 Main Avenue, Big City, 10001, PL" year_founded: 2005, revenue: 100000000, // ... 20 other things about Richy REST Employer }
By this moment you are already exhausted. You don’t even want to meet a friend of Richie Resta! It can take forever, waste all your energy, and besides, you no longer have time.
However, Georgia GrafKewel stands very close by and you decide to chat with her.
"Hi what's your name?"
{ name: "Georgia GraphQL" }
"Where are you from and how old are you?"
{ hometown: "Pleasant-Ville", age: 28 }
“How many hobbies and friends do you have and what is the name of your friends?”
{ hobbies_count: 12, friends_count: 50, friends: [ { name: "Steve" }, { name: "Anjalla" }, // ...etc ] }
Georgia GrafKewEl is incredible, clearly articulates thoughts, concise and accurate. You definitely want to exchange business cards with her and work together on future projects.
This story includes the experience of developers working with GraphQL and REST. GraphQL allows developers to formulate what they want with a neat query and get only what they specify in response. These queries are dynamic, so only one endpoint is required. REST, on the contrary, has predefined answers and requires applications to use multiple endpoints to fully query the data.
Finish with metaphors. Let's get down to business
For further disclosure of the concepts presented in the metaphor of the party, we turn specifically to the two limitations that often arise when using REST.
1. Multiple hits on getting related resources
Data management for mobile and web applications often requires related resources and data sets. Thus, obtaining data using the REST API can entail numerous requests for multiple endpoints. For example, a Post request and its associated Author can be made by two requests to different endpoints:
someServer.com/authors/:id someServer.com/posts/:id
Repeated calls to the API affect application performance. This is even more important for devices with low bandwidth (for example, smart watches, IoT, old mobile devices, etc.).
2. Over-fetching and under-fetching
Over-fetching / under-fetching is inevitable when using the RESTful API. Using the above example, the domainName.com/posts/:id endpoint retrieves data for a specific record. Each entry consists of attributes such as id, body, title, publishingDate, authorId, and others. In REST, a response is predefined and the same data object is always returned.
In situations where only the title and text of the recording are required, over-fetching occurs because more data is sent over the network than is actually used.
When the entire publication is required, along with related data about its author, there is insufficient under-fetching - because less data is sent over the network than is actually used. Insufficient under-fetching of data leads to an increase in the number of API requests and, as a result, excessive use of Internet resources.
Client Queries with GraphQL
GraphQL presents a unique approach that gives tremendous flexibility to client applications. With GraphQL, the request is sent to your API, and exactly what you need is returned - no more, no less - in one request. The query results are returned in the same form as the query itself, ensuring that the response structure is always predictable. These factors allow applications to run faster and be more stable as they control the data they receive, not the server.
“Results are returned in the same form as queries”
/* Query */ { myFriends(first: 2) { items { name age } } }
/* Response */ { "data": { "items": [ { "name": "Steve", "age": 27 }, { "name": "Kelly", "age": 31 } ] } }
Reality check
Now you probably think that working with GraphQL is as easy as slicing warm butter with a samurai sword. This may be true for front-end developers. However, when it comes to configuring the server side, someone has to do the most difficult work. Our friend Georgia GrafKewEl has put a lot of effort into becoming a classy professional.
Creating the Server side GraphQL API takes time, effort, and experience. Nevertheless, those who are ready for testing are able to cope with this. There are many different ways to do this, for example:
On your own : if you really want to do everything yourself, try building the GraphQL API with packages. Using Rails? Try graphql-ruby. Love Node.js? Try express-graphql.
With : if flexible hosting setup is your priority, something like Graph.cool can help you get started with the GraphQL project.
Instant : Tired of writing a CRUD template and want to get started quickly? 8base provides an instant GraphQL API and a server backend that can be extended.
In conclusion
For web services, REST was a significant step forward, making it easy to create APIs to access the necessary resources. However, its design did not take into account the current proliferation of mobile devices, with various restrictions on data download volume and requirements. This omission led to the growing popularity of GraphQL, which Facebook made open source in 2015, primarily due to the flexibility that it gives front-end developers. Working with GraphQL is a fantastic experience for both individual developers and teams.
All Articles