You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Laura Morales <la...@mail.com> on 2017/04/30 09:53:58 UTC
Would it make sense to use GraphQL with Fuseki as a backend?
Would it make sense to use GraphQL with Fuseki as a backend?
Re: Would it make sense to use GraphQL with Fuseki as a backend?
Posted by 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?
Posted by 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.
Re: Would it make sense to use GraphQL with Fuseki as a backend?
Posted by "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?
Posted by james anderson <ja...@dydra.com>.
good afternoon;
> On 2017-04-30, at 11:53, Laura Morales <la...@mail.com> wrote:
>
> Would it make sense to use GraphQL with Fuseki as a backend?
you posed the question in different terms some time ago.
now, after wrangling sparql for two months, you remain unconvinced and raise the question again?
there are those who take the argument further, to suggest that it would be a great service to the entire semantic data processing ecosystem for rdf store developers to support graphql.
the argument is threefold
1. graphql “as-a-language” lowers the threshold to access and broadens the prospective client developer community.
2. graphql affords embedding in a wider range of development stacks and enables powerful development tools.
3. graphql is close enough to sparql on an abstract level, that the implementation effort would lie within reasonable boundaries.
the arguments are all good but, so far as i am aware just one implementation has ventured around that corner.
best regards, from berlin,
---
james anderson | james@dydra.com | http://dydra.com