If your team is building an API, there’s a good chance you’re thinking about embracing GraphQL. If you’re a developer who wants to search for data, there’s a good chance the next generation of databases will want you to send your request in GraphQL. However you look at it, the query language is one of the hotter options for organizing how we search for data.

GraphQL was first created by Facebook in 2012 because the company needed a succinct and powerful way to search data structures in its immense social graph. Facebook (now Meta Platforms, Inc.) started sharing it publicly in 2015, and the company donated control to the nonprofit GraphQL Foundation in 2019. Today, dozens of companies are building out data search services using some form of GraphQL. The query language itself continues to evolve and the GraphQL Foundation has released a steady stream of ideas and improvements in new specifications.

Is GraphQL right for your next project? To help you decide, we’ve compiled a list of five reasons developers love GraphQL, and five reasons they don’t.

Love: GraphQL is succinct

Developers who need to search for data love the compact form of GraphQL—especially those on the front end who are constantly adding new features and bits of data to enhance a user interface. The syntax is one of the simplest ways to request answers from complex, sometimes nested data structures. That makes it easy to ask for a bit more data without rewriting your code.

GraphQL’s query mechanism is also designed to hide much of the complexity of traditional querying. Some developers struggle with inner and outer joins in queries to the database. Others get tired of sending three or four requests to find the data in three or four different databases around the world. GraphQL tucks all of that complexity out of sight, so you don’t have to think about it. 

Hate: It makes querying dangerously easy

Developers love how easy it is to add more fields to GraphQL requests knowing that the back end will handle all the complexity. Then, they’re surprised when the results slow down by a factor of five, 10, or maybe 100. All those new queries add joins to processes and send the back end scurrying, seemingly to Timbuktu and back. Database administrators are rightfully angry when the server load spikes, but how was the developer to know? GraphQL hid everything.

It gets worse, though, because some implementations in the cloud are now billing by the workload. A query that asks for a bit more could turn into a fat cloud bill at the end of the month. Little did you know how much you (or your company) would have to pay for the exfiltration fees and computations, all because the Kubernetes cluster silently spun up more instances to service your request.

Love: GraphQL is evolving

GraphQL is still pretty new and the committees designing it are still working on it. That means new features are being added frequently. The GraphQL release log from October 2021 included more than 100 changes and enhancements, and the work to improve GraphQL is ongoing.

Hate: API versioning is confusing

While many teams are able to constantly improve and enhance their GraphQL APIs, not all can manage it gracefully. Some talk about sneaking in “null” responses for fields that have disappeared. Others include dummy data. Some speak of sliding explicit version tags into the path (e.g., “/v3/data”) and creating a single tree with different versions on different branches. The developers running the API can find themselves stuck adding but never subtracting information and supporting requests for fields just because someone, somewhere, still asks for them.

Love: GraphQL has power under the hood

Many developers, especially those who just want to get data out of an API, marvel at GraphQL’s querying power. It takes just a few keystrokes to change around a query and command the API to deliver something entirely different.

GraphQL’s real power, though, lies under the hood. A smart back end can use GraphQL to make good decisions about the best way to gather information. Its optimization routines can run static analysis on a request and make relatively accurate predictions, which the back end can use to choose the fastest path. GraphQL can also assemble fixed queries and keep a careful list of cached objects to add more speed.

Hate: Power can be dangerous

Everyone loves power until it unleashes forces that they can’t control. With GraphQL, this looks like a query that runs off and chews up far too much bandwidth, compute resources, or both. But there are other dangers like releasing information that’s supposed to be kept private. Or even triggering updates for data that’s supposed to remain unchanged.

Love: Data for the people

Data is only good if it’s used, which means putting the data in the hands of the people in the trenches. That is why front-end developers focus on crafting nice interfaces for the masses. When GraphQL makes life easier for them, they, in turn, can make life easier for everyone else. Building an open and accessible mechanism for data retrieval can also lead to a renaissance in data usage throughout the firm.

Hate: No schema

One common complaint from developers is that there’s no obvious map or schema to guide them through the tree of data. The right string might be there, but on which branch? At least a relational database arranges everything in nice, rectangular tables with columns that are well-defined and fairly consistent. This may be more the fault of a complex graph data structure than the language itself, but that doesn’t make life easier for developers.

Love: Using supergraphs to bridge your back ends

GraphQL lovers like to talk about gluing together all of an enterprise’s data into one grand supergraph. They will take several legacy systems and mix in some new fields to create a comprehensive writ of all common wisdom and a single source of truth. Every data warehousing team can create a grand portal where they will house all their pearls.

Hate: Supergraphs only look easy

The vision of creating a supergraph that combines all your data into one grand interface is rarely as simple as it sounds. Just as physicists have been working on their Grand Unified Theory for decades, data teams can spend a lot of time fussing over the details of such an integration. Developers, for example, often complain that the type systems of the different branches are askew. One branch may store dates in text format while another uses a numerical standard. If the supergraph unifies data stored in different countries or continents, there’s a good chance that you will have to manage branches in different languages. It’s easy to glue together various data sources to look like a single interface, but actually unifying the data is much more complicated.

Conclusion

The bottom line with GraphQL is that it is both powerful and succinct, but it’s almost too easy to misuse that power. Developers and teams considering GraphQL should be prepared to put in the time to really learn its ins and outs. Treating GraphQL as a simple and easy solution is tempting, but it could cost you in cloud bills and security headaches.