SPARQL demands a certain data model (triple stores). Also, everything about it smells like ivory-tower academic snobbery + ultra-large-enterprise crap. GraphQL does neither.
GraphQL also demands a certain data model. Just that it is not standardized. And no, RDF/XML is not the only representation for SPARQL. It can deal also with JSON.
I think you should read it directly from the website: "GraphQL is a query language for your API, and a server-side runtime for executing queries by using a type system you define for your data." You need a type system to bypass the datamodel. Just pushing the issue around.
No, it doesn't, it is agnostic. There's an adapter for every major database out there. Oh, yeah, graphql also has momentum and strong adoption, unlike SPARQL.
Oh yeah, GraphQL is backed by Facebook (may that be a hint of its momentum, like its support for React?) , unlike SPARQL which is a _standard_. You can also convert from PostgreSQL, MySQL, DB/2 and others to SPARQL. Still, only difference seems 1. Facebook pushing its non-standardized tech around and 2. Losing any benefits from HATEOAS from the usage of GraphQL.
Sure but I use GraphQL as middleware when fetching from elasticsearch, or redis, or flat files. It is not something you hook up directly to your database, it's a way to help define an api for your application.
Most of the time, in my app, resource names do not even correspond to single tables or backend data structures but are simply presented that way for ease of use for external consumers.
Subjectively, Implementing it feels more like old school COBRA than REST or SQL.
You’re getting caught up in the “graph” part. GraphQL is unfortunately named, because it doesn’t actually have any “graph” related semantics or features in the graph database sense. The “graph” in GraphQL just refers to the fact that you can use it to retrieve nested data. On the other hand, SPARQL and Tinkerpop (the “true GraphQL” imo) are actually about graphs and related data in the graph database/semantic web sense. GraphQL and SPARQL have nothing to do with each other.
GraphQL is not a generic query API language. One of the most unfortunate things about GraphQL is the presence of "QL" in the name makes people think it is somehow comparable to SQL or SPARQL.
Maybe because it IS a query language? From the website: "GraphQL is a query language for your API"... just that it is _not_ a standardized API, so we won't take advantage of HATEOAS.
I recommend this talk to see what both technologies can still "learn" from each other - https://youtu.be/LUF7plExdv8. I don't think SPARQL or GraphQL completely replace one another.
I think GraphQL is just an way to bully the efforts of the W3C to standardize web technologies. It not just is non-standard, also is breaks any advantage of the HATEOAS principle.
I have written HATEOAS APIs (not just “RESTish” APIs). I prefer writing GraphQL APIs by far.
If I have to write something that’s REST-ish, I’ll do my damnedest to make sure it’s HATEOAS, but in my experience, the number of developers who can consistently produce useful and consistent HATEOAS APIs is…vanishingly small.
I can learn more about an API from its GraphQL schema than most of the other API documentation (like OAS/Swagger or RAML) out there.
Yeah, if you are writing HATEOAS APIs just by personal preference then you are using the wrong technology. You should write HATEOAS to make sure your API will be consistent, standard and automatically browsable on the long term.
As someone who used to write SPARQL queries for a living with some of the most established players in the Semantic Web game, the idea of SPARQL and GraphQL serving the same purpose is pure misconception (usually by folks who haven't yet taken the dive into GraphQL).
GraphQL allows the backend to say "here's the data I offer and how it's structured, pick which fields you want from that" and the frontend query just specifies the "what." It's like picking from a menu (although fields can have parameters), and the results you get back are structured objects with nesting.
On the other hand, the data offered by a SPARQL endpoint has no inherent structure, the query is what gives the data structure. You not only ask what you want (the projection) but how to resolve the fields using (often complex) relational logic. It's orders of magnitude more powerful, which is awesome, but also more work and more confusing. Its biggest downside is that, like SQL, the results are row-oriented. For anything other than completely simplistic queries, the resulting data often needs to go through a transform/reducer step instead of being used directly, because real-world needs aren't always row-oriented (especially on the frontend). If you want to request information about both entities and the "children" of those entities, the projection is going to be (1) incredibly messy and (2) full of duplicate data, or you're making multiple queries.
I wouldn't want my frontend communicating with a raw SPARQL endpoint for the same reason I wouldn't want to expose a raw SQL endpoint (and basically nobody does). GraphQL puts the frontend "on rails" so to speak and lets the backend worry about the "how." That can be a positive or a negative depending on what you want to do, but in the frontend world (where REST is the norm), folks consider that a positive and it's the direction they've generally chosen.
SPARQL results DO have an inherent structure. Even more, this is why projects like Eclipse Lyo can automatically convert SPARQL results directly to Java Objects. So no, SPARQL it is not intended to be used directly but as a product for a library to be converted into objects or rows or graphs or anything the client needs.
On the other hand, GraphQL pushes its complexity (to worry about the "how") into the server's implementation. The complexity is still there. And it's impossible to be automatically browseable.
Semantic Web is only an application of SPARQL, not the only one.
The name doesn't make it so. It defines a syntax and a single operator (nesting), but nothing else. You can't use it to "query" arbitrary data sources in the sense that other query languages such as SQL do, since there are no operators, functions, subqueries/arbitrary joins etc. It's an alternative to REST, not SQL.
