Couldn’t attend Transform 2022? Discover all the summit sessions now in our on-demand library! Look here.
GraphQL is fast becoming a go-to query language for businesses to interact with their data. Although data management is a top concern for many businesses, many people don’t really understand what GraphQL does or why it’s so popular.
On average, the world generates about 2.5 quintillion bytes of data per day. Businesses need a way to collect this data and use it effectively. A lot of data is generated in apps (for example, a smartphone customer service app that lets customers tell you if they’re happy or if they’re having problems and need help with troubleshooting). Applications need a way to pass information to the backend; i.e. data management and storage tools. Then the data can be analyzed to uncover problems and develop solutions. And of course, it is bi-directional. Not only do apps send data to backends, but apps need data from the backend. For example, recommendations, delivery status, account balances. And that’s what GraphQL is for: getting data to and from the backend. This is a more modern API that connects apps to backends.
Although many tech leaders have heard of GraphQL, they’ve probably heard a lot more about SQL (Structured Query Language). SQL is essentially the industry standard for querying databases, although GraphQL is growing in popularity.
How does GraphQL compare to SQL, and is there a way to get the benefits of both when running queries?
GraphQL vs SQL: the overview
GraphQL has a relatively simple and readable format for data access. The unique format allows for something called “nesting”. Nesting is like asking a question inside another question to get a more specific answer. For example, instead of just asking for a list of all the dogs in a particular shelter, you can ask for a list of all the dogs and nested details about the breeds of those dogs (taken from a whole other, or even a a third party data source).
GraphQL’s ability to nest queries allows a frontend developer to retrieve relevant information from an API in a single query. Since GraphQL is almost a universal query language, easily handling different data sources, you can also query multiple APIs and other data sources at the same time. GraphQL is therefore the right query language for heterogeneous backends, i.e. backends with different types of data sources in addition to databases.
SQL is extremely popular as a query language for databases. Unfortunately, it doesn’t work for nested queries over heterogeneous data the same way GraphQL does. Also, the syntax of SQL can be complicated. Finally, SQL was never meant to be universal. SQL works very well for different databases, but not so well for APIs.
GraphQL vs SQL in action
Suppose you are working to restock your company’s inventory and need to know the tracking number and expected delivery date for two different orders shipped by two different companies. GraphQL would be able to get all of this information in a single query.
GraphQL also shows you this information in a hierarchical structure that makes it easy to see the relationship between the data items you’ve requested. In other words, you can see that the delivery date of your package is related to the tracking number you received.
For SQL, you may need to query your database for general information about the two different commands. Then you may need to sort through this information to find the shipping company names, followed by another request to each shipping company for tracking numbers. Finally, depending on the tracking number, you can make another request to get the expected delivery dates. Getting all this information would take a lot of code, and it might not be easy to get the syntax right. Personally, I’ve worked with SQL databases for decades, and even I often have to research the syntax for complex queries.
Why is SQL still so popular?
A GraphQL API schema only allows a subset of operations, depending on the developers implementing that API. In other words, the flexibility of your queries depends on the flexibility of API developers. For example, an API only allows you to search for customers by email. To search for customers by city, the app should collect all customers and then filter them one by one. Talk about complicated.
Or if you deal with sensitive data, you may need to configure your queries and APIs for factors such as controlling who can access the data or how long the data is cached (temporarily saved) on the backend . Such configurations are a tall order for the average business, but many technologies are now available to manage and configure GraphQL queries and APIs for you. These technologies make GraphQL a viable option for querying APIs, but without these technologies configuration can be difficult.
In contrast, SQL is more expressive out of the box, which means it’s easier to tell the system what you want without a lot of extra configuration. One can easily ask any database “for customer John Doe, give me orders over $100”, using a single line of code. SQL will give you what you need, regardless of the database structure.
The way I like to put it is this: GraphQL allows flexible queries within the framework defined by the developer who built the API. SQL allows universal querying on any database model. So if you’re primarily querying databases, SQL will do the job well.
Is there a way to bridge the gap?
What if you could take advantage of the expressive attributes of SQL and the flexibility of GraphQL at the same time? There are technologies available that claim to do this, but they are unlikely to become popular as they end up being clunky and complex. The annoyance comes from trying to force SQL constructs into GraphQL. But they are different query languages with different purposes. If developers need to learn how to do SQL constructs in GraphQL, they can just as easily use SQL and connect directly to the database.
However, all is not lost. We believe GraphQL will become more expressive over time. There are proposals to make GraphQL more expressive. These could eventually become standards. But fundamentally, SQL and GraphQL have different worldviews, respectively: uniform backends versus diverse backends, tables versus hierarchical data, and universal queries versus bounded queries. Therefore, they serve different purposes.
GraphQL, despite its popularity as an API query language, is not going to overthrow SQL as the primary language for database access.
Welcome to the VentureBeat community!
DataDecisionMakers is where experts, including data technicians, can share data insights and innovations.
If you want to learn more about cutting-edge insights and up-to-date information, best practices, and the future of data and data technology, join us at DataDecisionMakers.
You might even consider writing your own article!
Learn more about DataDecisionMakers