GraphQL was created in 2012 by Facebook as a way to make it easier for developers to fetch the data they need from the Facebook API. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.
What Is really GraphQL?
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.
What makes GraphQl different from REST?
- GraphQL is a query language for your API, not just a data format. This means that you can query for exactly what you need, and get back clean, easy-to-use data.
- is type-safe. This means that you can be sure that the data you're getting back from your API is the data you expect, and that it's valid.
- is self-documenting. When you query the GraphQL API, you also get back documentation for the fields and types that are available.
- is backed by a single endpoint. This means that you don't need to worry about maintaining multiple endpoints for different data types, or versions of your API.
- is extensible. You can add your own types and fields to the GraphQL schema, and query them just like any other data.
In other words, the old REST model is like ordering pizza from multiple shops, each with their own phone number. This can be time-consuming and frustrating, especially if you change your mind about the toppings halfway through. With GraphQL, it's like ordering a pizza from one shop. You tell them what toppings you want, and they'll get you the pizza with the toppings you want. If you change your mind, you can just ask for different toppings. No need to start from scratch.
The Basics in three words
- It lets the client specify exactly what data it needs.
- It makes it easier to aggregate data from multiple sources.
- It uses a type system to describe data.
More technical terms..
Three main compements:
Schema, queries and resolver.
Queries..
A query is the request the client makes. Query fields can point to arrays and support arguments.
A typical querie in Qraphql look likes this.
query{
object {
table
}
}
Resolver
Resolvers are responsible for fetching the data for a specific field. Without a resolver, the GraphQL server would not know what to do with the data corresponding to a field. By decoupling the API schema and the database schema, GraphQL allows you to use the former to modify the contents of the latter.
Query: { post(root, args) { return Posts.find({ id: args.id }); }}
Resolver can also be used to modify data in which case theyβre known as mutation resolvers.
mutation {
createUser (userName:"user1") {
userName
}
}
Schema
A schema is a blueprint for a GraphQL API. It defines the types of data that can be fetched from the API, and how that data can be mutate.
GraphQL is not as popular as REST, but it is very efficient and it is growing in popularity. GraphQL is a good choice for modern development and it is worth learning.
I will publish next week a new article about API security and graphQL.
See you next week :)
Top comments (22)
Just my opinion, but GraphQL and REST are different things. The one is not supposed to replace the other.
Also I want to add that REST can be easier to use, but you can also correct me. Having different URLs for different kinds of records is not necessarily worse.
Great post, but I don't think Graphql is more efficient than REST, both have cons and pros, and they are different tools, the purpose of Graphql wasn't replace REST, I wrote this article describing both honeybadger.io/blog/graphql-apis-f... so happy to share ideas π
Nice blog, it depends on the use case, but GraphQL defenitely shines for frontend API's. Recently updated a bank demo. For Spring Boot there are also good options, with Netflix DGS and Spring GraphQL. Most interesting things with GraphQL happen in js through. The work The Guild put in is amazing.
Nice write up. I'm not so sure I'm sold on Graph yet. For me the trade offs aren't ideal. I've only dabbled but from what I remember, Graph put a lot of pressure on the persistence layer and dictated some things there that were annoying. I guess anything that weaves it's way through to the backend gives me some concern. I like to keep things as decoupled as possible.
It's been a few years and I have yet to see any real-world problem that GraphQL solves that hadn't been solved by SQL several decades ago.
SQL is for databases, GraphQL (mainly) for frontends. It's apples and oranges.
It's because this post failed to highlight the actual strength and use case of GraphQL and tried to present GraphQL as a replacement for REST which is not true. But once you actually learn it and use it, you'll appreciate what it allows you to do.
That very much aligns with my point though; GraphQL is not a replacement forΒ REST because they're different things.Β GraphQL is a query language, just like SQL is. So it's those two that should be compared, while REST has little to do with either of them.
I would argue they are 3 different, which each there own good use cases.
You query your front-ends for data?
No.. But traffic between a backend service and frontend, or backend service and a database, is something different right?
No, not really. In the end, you're querying data. It's the same thing. This should be made abundantly clear by simply comparing GraphQL and SQl. The former is little more than a simplified version of the latter forcefully pressed into a more JSON-like syntax.
Not really, security, error handling, depreciation, are all totally different.
this is a good way to express valuable information to a rational people they can understand it easily . black magic removal in Kerala
Thank you ! But please remove your link
thank
what is bad in this link .
REST is an architecture. RESTful is a rest architecture over http. GraphQL is only a data format. So, compare apples to pears.
I agree they are different, and it can be difficult to compare them. But Both apple and pear are fruits that were made to be eaten..
The end goal looks alike with different data structure and ways to bring data . That is my opinion.
you're already talking about data, so it's time to start comparing the same things.
GraphQL uses the REST architecture (in particular, restful if it uses http as a portable protocol).
The difference is in the form of the data used. in other words, you can compare GraphQL with JSON or SOAP.
Graphql is not meant to replace rest. If it is, then why hasn't it? It's been 10 years and even Facebook itself is sending an http request to an endpoint to mark a chat message as seen when I open the corresponding chat box. -- fun fact: find this endpoint, block it, and the messages you receive will never be marked as seen.
With GraphQL, you will need to maintain multiple resolvers, that's literally how GraphQL works behind the scene, resolvers. And yeah you can use other GraphQL engines out there but they are not without limitations, they are actually very limited in functionality, unlike building your own, hence, they allowed custom mutation and queries.
This post is very misleading and should either be corrected by the author or taken down, otherwise inexperienced devs who will read this will be mislead.
about facebook's bug you should report it ...
REST and GraphQL are two different things. However, they can be mutually beneficial. You can use a REST API to create a GraphQL API in example stepzen.com/getting-started?detail...