Queries/Fragments Stored Server-Side

Issues Dgraph
, ,
1

Moved from GitHub dgraph/5040

Posted by erhlee-bird:

Experience Report

Note: Feature requests are judged based on user experience and modeled on Go Experience Reports. These reports should focus on the problems: they should not focus on and need not propose solutions.

What you wanted to do

Leverage a complicated GraphQL± query and easily share with peers.

What you actually did

Incur encoding and network transmission costs for a large query.
Copy and paste snippets to others.

Why that wasn’t great, with examples

Would be great to effectively create shared query primitives that can be used by peers.
Almost like a plugin system.

By keeping the query stored server-side, we’d benefit from caching the query.
Even if the encoding and transmission costs are fairly negligible, would help simplify developing more and more complex queries.

register(pagerank query, query body...)

query({
  q(func: pagerank(...)) {
    ...
  } 
})

Any external references to support your case

2

MichaelJCompton commented :

Yeah, I think some sort of ‘stored procedure’ system or some way of registering query blocks and then composing those into a query would be interesting.

It’s not clear if this should be supported for GraphQL± or as a way of extending a GraphQL API with custom queries.

We’ll add it to suggestions and consider it.

If you have more info on use cases to support this, that would be great.

3

erhlee-bird commented :

We’re specifically looking to use this with GraphQL± and are not using the GraphQL endpoints.

One potential example would be that until certain algorithms are supported natively like k-shortest-path, we can contrive them by writing GraphQL± queries for algorithms like PageRank.

We would want to write such a query and store it so others could use it and not have to reserialize and send the full query if the query gets complex.

4

manishrjain commented :

@MichaelJCompton could fragments be used here? GraphQL± already supports them.

5

MichaelJCompton commented :

Yep fragments would work, but you’d need to add them into your query client-side. The issue is asking for being able to store those server-side so there’s no need to send on each request.

As a work around, yes, you can definitely have fragments that you include in your queries client side.

This does also interact with GraphQL though, because it would be neat to be able to define a GraphQL± ‘stored procedure’/fragment and then use that as the definition of of a GraphQL field/query.