Re: Would it make sense to use GraphQL with Fuseki as a backend?

["Lorenz B." <bu...@informatik.uni-leipzig.de>]

Do you have any implementation for GraphQL on Jena?

> Would it make sense to use GraphQL with Fuseki as a backend?
>
-- 
Lorenz B�hmann
AKSW group, University of Leipzig
Group: http://aksw.org - semantic web research center

Re: Would it make sense to use GraphQL with Fuseki as a backend?

[james anderson <ja...@dydra.com>]

good afternoon;

> On 2017-05-01, at 09:58, Laura Morales <la...@mail.com> wrote:
> 
>> Do you have any implementation for GraphQL on Jena?
> 
> Nope. I was simply wondering if it would make sense to define an API with GraphQL, and use Fuseki (via HTTP requests) as a "resolver" function for the various GraphQL "types". I have this question because from my understanding, GraphQL calls several "resolvers" one after another to retrieve all the data asked by the user, which I think is very handy in the context of RDBMSes because you don't have to deal with complex, multi-JOINs, queries. However in the context of graph databases it seems rather inefficient because I could already traverse the graph using a single, simple SPARQL query. What would be useful I guess is a converter from GraphQL query language to SPARQL. But it's just an idea, a random thought that I had while thinking about GraphQL+graph-databases.

plugging a sparql processor into a graphql server affords access to rdf stores as one element in heterogeneous graphql combinations.
that is an attractive capability.
the limitation is that while "you don't have to deal with complex, multi-JOINs”, the described control model for graphql resolvers (as per the api definitions) entails implementing what are necessarily, internally joins as nested loops.
it is as if one were to segment a sparql query into nested service clauses and stipulate that the implementation must pass exactly one values clause with each remote service invocation.
this does not tend to be the best approach for an rdf store.

the graphql->sparql translation process is more likely to yield an effective implementation and it would be nice if one could integrate that into the resolver architecture, but it is not clear whether the api affords access to the necessary query state to be able to perform a high-level translation.

best regards, from berlin,


---
james anderson | james@dydra.com | http://dydra.com

Re: Would it make sense to use GraphQL with Fuseki as a backend?

[Laura Morales <la...@mail.com>]

> Do you have any implementation for GraphQL on Jena?

Nope. I was simply wondering if it would make sense to define an API with GraphQL, and use Fuseki (via HTTP requests) as a "resolver" function for the various GraphQL "types". I have this question because from my understanding, GraphQL calls several "resolvers" one after another to retrieve all the data asked by the user, which I think is very handy in the context of RDBMSes because you don't have to deal with complex, multi-JOINs, queries. However in the context of graph databases it seems rather inefficient because I could already traverse the graph using a single, simple SPARQL query. What would be useful I guess is a converter from GraphQL query language to SPARQL. But it's just an idea, a random thought that I had while thinking about GraphQL+graph-databases.