Ready for GraphQL Sidebar: GraphQL vs. SPARQL?
Is GraphQL like SPARQL? The same idea? A competitor? We have heard questions like these more than once in the past few weeks as we’ve worked on this series.
The short answer is yes. Same idea.
The long answer is not exactly.
Executive Summary
- GraphQL and SPARQL are both computer languages for developing semantic queries and returning results in an orderly structure to client software.
- The two languages take very different approaches to do some of the same things.
- Since they do some of the same things, most organizations wouldn’t expend heavy resources on both; for instance, to train technical people on both GraphQL and SPARQL would be unusual.
- As a result, the two languages do compete from an organizational standpoint in an indirect but important way.
As for the for the “not exactly”…
More Details
SPARQL and GraphQL come from different worlds to solve problems within the same general category; let’s call that category “semantic data querying.”
Semantic data querying is an attractive goal whenever communications between two or more data-oriented systems could be better facilitated by making the systems aware of the structure and meaning of data being stored and accessed.
Two parts to making semantic data queries work are schema and query languages. The semantic query system needs a way to describe the data being stored and addressed; this is where the schema language comes in. Then, in order to address that schema, a system needs a specific syntax to form requests that work with the schema. This is the role of the query language. Put them together with a little technical magic and, voilà, we have a semantic data querying system.
SPARQL is generally more powerful than GraphQL since it was defined to work with the extensive schema organization of RDF and is designed to cover most of the possibilities arising from that language. RDF is more complete and capable than GraphQL schemas, because RDF’s primary purpose is to provide a system for building completely-detailed structures from the meaning of the data.
Conversely, GraphQL has fewer capabilities.¹ It is also far simpler to learn and use, a result of its syntax being intentionally human-oriented, rather than predicate calculus-oriented.
Also, SPARQL has nothing to do with software interfaces, whereas GraphQL specifically lives as a web API system. Thus, GraphQL relates to web standards like REST in ways that are totally unrelated to SPARQL.
SPARQL has long been a leading method of delivering querying capabilities for systems using semantically-organized data structures, like the ones found in many graph databases today. Though SPARQL has always maintained the mantle of being the “primary” semantic query language, competing systems have followed with regularity over the past decade. To quote from one of these projects:
Most popular (Web) application frameworks, such as React and Angular have limited support for querying the Web of Linked Data, which leads to a high-entry barrier for Web application developers. Instead, these developers increasingly use the highly popular GraphQL query language for retrieving data from GraphQL APIs, because GraphQL is tightly integrated into these frameworks.
This is a portentous analysis. You could replace “Web of Linked Data” in that passage with “SPARQL + RDF” or “JSON-LD” or “Cypher” or any other semantically-powered framework combos you could find today, and it would be just as true.
GraphQL has about the lightest-weight semantic footprint that would be workable and useful. As a result, it is very likely that existing semantic frameworks, like Web of Linked Data, will continue to seek to integrate GraphQL and shift toward providing niche capabilities for applications where the added semantic horsepower is needed.
Bottom Line
SPARQL is unlikely to go away entirely anytime soon, and may actually see its lifespan extended as new GraphQL users run into edge cases where SPARQL shines.² On the other hand, GraphQL’s usage and ecosystem is expanding much more quickly than SPARQL’s has since it was defined over a decade ago.
In terms of being the primary semantic query language, GraphQL is likely to replace SPARQL, and in many cases already is doing so.
Notes:
- It’s worth mentioning at least in this footprint that GraphQL does have a few technical capabilities that SPARQL painfully lacks. There’s a detailed technical discussion here.
- Pun intended. Sorry.
This post was generated using MarkdownToMedium.
