Full Stack Developer
GraphQL is a query language and server-side runtime for application programming interfaces (APIs) that prioritizes giving clients exactly the data they request and no more.
GraphQL is designed to make APIs fast, flexible, and developer-friendly. It can even be deployed within an integrated development environment (IDE) known as GraphiQL. As an alternative to REST, GraphQL lets developers construct requests that pull data from multiple data sources in a single API call.
Additionally, GraphQL gives API maintainers the flexibility to add or deprecate fields without impacting existing queries. Developers can build APIs with whatever methods they prefer, and the GraphQL specification will ensure they function in predictable ways to clients.
GraphQL offers many benefits over REST APIs. One of the main benefits is clients can dictate exactly what they need from the server, and predictably receive that data.
For example, imagine you have the following schema:
type Query {
me: User
}
type User {
id: ID
name: String
city: String
state: String
friends: [User]
}
Now let’s say that you just needed to get a User‘s name. If you had a REST API, you would typically receive the entire User object back in your response. This leads to over-fetching and can result in performance issues. With GraphQL, you only receive the data you explicitly request.
Here’s what our User name query would look like:
{
me {
name
}
}
And here’s what our response would look like:
{
"me": {
"name": "John Doe"
}
}
Another big benefit is the ability to retrieve many resources in a single request. Continuing with our example schema, imagine we want to also fetch the names of our User‘s friends as well. For a traditional REST API, we would probably need to make an additional request to a /friends?id=X endpoint, passing in our User‘s ID.
We can simply append our friend's property to our query and receive all our names in a single request:
{
me {
name
friends {
name
}
}
}
And here’s what our response would look like:
{
"me": {
"name": "Jason Roy"
"friends": [
{
"name": "James Roy"
},
{
"name": "Jimmy Roy"
}
]
}
}
Another benefit is that it is strongly typed which allows API consumers to know exactly what data is available, and in what form it exists. According to the docs: “Every GraphQL service defines a set of types which completely describe the set of possible data you can query on that service. Then, when queries come in, they are validated and executed against that schema.”
While GraphQL has many advantages over traditional REST APIs, there are several key disadvantages as well.
One disadvantage is that queries always return an HTTP status code of 200, regardless of whether or not that query was successful. If your query is unsuccessful, your response JSON will have top-level errors key with associated error messages and stack trace. This can make it much more difficult to do error handling and can lead to additional complexity for things like monitoring.
Another disadvantage is the lack of built-in caching support. Because REST APIs have multiple endpoints, they can leverage native HTTP caching to avoid re-fetching resources. With GraphQL, you will need to set up your caching support which means relying on another library or setting up something like globally unique IDs for your backend.
This leads us to the final disadvantage: complexity. If you have a simple REST API and deal with data that is relatively consistent over time, you would be better off sticking with your REST API. For companies that deal with rapidly-changing data, and have the engineering resources to devote to rearchitecting their API platforms, GraphQL can solve many of the pain points experienced with REST APIs.
GraphQL provides an interesting solution to common hurdles faced when using REST APIs. While using GraphQL has several downsides, if you find yourself working with rapidly-changing data at scale, it could be a great solution for your business. To learn more about it, check out the docs. And if you’re looking for a more fully-fledged GraphQL solution, Apollo provides an easy way to get started on both the client and server sides.
SQL stands for Structured Query Language which is a language used by databases. This language allows to handle the information using tables and shows a language to query these tables and other objects related (views, functions, procedures, etc.). Most of the databases like SQL Server, Oracle, PostgreSQL, MySQL, MariaDB handle this language (with some extensions and variations) to handle the data.
If you have no logic between your GraphQL resolvers and your backend’s database, one can just translate the GraphQL query to a SQL statement. That’s why it’s so “easy” for GraphQL solutions like Hasura to create GraphQL CRUD operations for you.
However, in most cases, your GraphQL resolvers have business logic. For instance, maybe you don’t want to fetch all books by an author, but some statistics for your frontend visualization to learn more about the books written by an author. Then the GraphQL resolver would fetch all books by an author from the database, but prepare the data for the visualization before passing it to the frontend.