Align GraphQL+- with the GraphQL spec where possible

[dpeek]

It seems like there is a huge advantage to sticking to the GraphQL spec where possible, in order to reduce the amount of mapping required by GraphQL clients talking to dgraph. A number of current
query features could be implemented to the spec without a worse DX.

Firstly, avoid function call style filters and queries in favour of a more declarative approach:

me(query:{name_anyof:"something"}) {}
// instead of
me(func:anyof(name, "something")){}

And

me(query:{type_eq: "foo"}, filter:{name_eq:"something"}){}
// instead of
me(func:eq(type, "foo") @filter(eq(name, "something"){}

Obviously this needs some careful thought to find the right balance, but being able to leverage a larger part of the GraphQL ecosystem seems like a huge win.

More ideas here:
https://www.graph.cool/docs/tutorials/designing-powerful-apis-with-graphql-query-parameters-aing7uech3/

[manishrjain]

I think the GraphQL spec is not versatile. Everything has to be keys and values; there are no functions and no function chaining. Let's look at this issue with examples.

func: anyof(name, "something"): Here the predicate name is a separate clear field, compared to name_anyof, where we're appending the instruction to the name of the field itself. And of course, the name of the predicate itself could have the instruction as a suffix, so something might look like this:

name_anyof_anyof: where name_anyof is the predicate name, and the second _anyof is the instruction. That is not clean, it's hacky.

Looking at filters: me(query:{type_eq: "foo"}, filter:{name_eq:"something"}){}. Here, you can only have one filter. If you want to add more filters, it becomes more convoluted.

So, in that case, let's look at the GraphQL docs page:

query combineMovies {
  allMovies(
    filter: {
      OR: [{
        AND: [{
          releaseDate_gte: "2009"
        }, {
          title_starts_with: "The Dark Knight"
        }]
      }, {
        title: "Inception"
      }]
    }
  ) {
    title
    releaseDate
  }
}

In this one, we just added a simple filter, and already the query looks out of control. This is how it would be represented by GraphQL+-.

query {
  allMovies () @filter( 
    (ge(releaseDate, 2009) and regexp(title, "The Dark Knight.*")) or
    anyofterms(title, "Inception")) {
  title
  releaseDate
  }
}

The s-query like syntax for filters is a lot more intuitive than forcing everything into a JSON value, so that the key-value requirement of GraphQL is satisfied.

I'll leave you with what's possible with GraphQL+-, which I doubt GraqhQL would be able to do at all.

{
	A as var(func: anyof(name.en, "hanks pitt damon dicaprio")) {
		actor.film {
			F as performance.film
		}
	}

	directors(func: anyof(name.en, "spielberg nolan tarantino"))
	@filter(gt(count(director.film), 10)) {
		director: name.en

		director.film @filter(id(F) and
					gt(initial_release_date, 1990) and
					lt(initial_release_date, 2015))
		(orderdesc: initial_release_date) {
			film: name.en
			release: initial_release_date

			# Actor information is 2 levels deep from movie in Freebase.
			starring {
				performance.actor @filter(id(A)) {
					actor: name.en
				}
			}
		}
	}
}

And on top of that GraphQL has a lot of unnecessary stuff that we've decided to avoid implementing at all. So, I doubt we'd be able to reach parity with GraphQL. I think what we can do is to build a JS library that helps people interact with Dgraph.

[manishrjain]

I haven't heard since. Closing this issue for now. I think discuss.dgraph.io, might be a better p-platform for this discussion.

[loganpowell]

How about a compiler? https://github.com/kensho-technologies/graphql-compiler

supporting blog post: https://blog.kensho.com/compiled-graphql-as-a-database-query-language-72e106844282