A Possible support for Dgraph through Raw HTTP endpoint

[MichelDiz]

This would be like a mix of GraphQL with GraphQL + - from Dgraph. However, if we could inject the Dgraph Query as we do in cURL. Dgraph would be fully compatible with Apollo.

curl -X POST -H 'X-Dgraph-LinRead: {"1": 12}' localhost:8080/query -d $'
{
  balances(func: anyofterms(name, "Alice Bob")) {
    uid
    name
    balance
  }
}' | jq

More info in: https://docs.dgraph.io/clients/#raw-http

e.g;

const query = gql`
  query Dgraph {
    apartments@rest(type: "query", path: "query", endpoint: "DgraphEnd") {
      bhk
      uid
    }
  }
`;

const query = gql`
  query Dgraph {
    apartments(func: eq(neighborhood.name, "Lutyens")) @rest(type: "query", path: "query", endpoint: "DgraphEnd") {
      bhk
      uid
    }
  }
`;

Mutation example:

curl -X POST localhost:8080/mutate -H 'X-Dgraph-MutationType: json' -H 'X-Dgraph-CommitNow: true' -d  $'
    {
      "set": [
      {"name": "Alice"},
      {"name": "Bob"}
    ]
      }' | jq

Cheers.

[MichelDiz]

I've find out that we can pass the Dgraph Query through the "Raw body" in Postman. So that's an sign that maybe possible Dgraph work with apollo-link-rest

PS. I think that the "bodyBuilder: $customBuilder" may be the way. But I'm not sure how it works.

BTW you can test against https://play.dgraph.io/query
just point the Postman to that endpoint, set "POST" and in Body set RAW and paste the Query below.

Pay attention that the UID may change in the future

{
  node(func: uid(0x36bb9)) {
    uid
    expand(_all_) {
      uid
      expand(_all_)
    }
  }
}

[fbartho]

This sounds like a big project. -- I don't think the hard part is using apollo-link-rest -- as you said, it's basically using the customBodyBuilder, or using a customFetch implementation. -- I think the hard part is going to be to "generate" the correct Dgraph-compatible payloads.

Please let us know what you figure out -- but it sounds to me like you'll need to make a pretty extensive "Query-Generator" that would be used as a customFetch implementation.

[MichelDiz]

Dgraph is a database that has its language inspired by GraphQL. It's called "GraphQL + -". It is a DB graph with a graph language. However, there are many features that do not exist in GraphQL, but are still compatible. And indeed it's a big project.

I think we can work on Dgraph to support apollo-link-rest, but I wanted to understand if I can already do something with what's available (Like a "Hack"). I did not find any customizable examples that could send the "Body" as I exemplified using Postman.

Injecting the Body with RAW text would be an easy way to make Dgraph work with apollo-link-rest. Cuz the response is in JSON. There's no secret.

Looking at this Apollo project I see great potential with Dgraph.

Cheers.

[fbartho]

@MichelDiz -- if that's the case, it almost looks like you might want to fork apollo-link-rest, and make apollo-link-dgraph

[fbartho]

Possibly the best fix might be to fork apollo-link-http ? -- that layer speaks GraphQL, so generating GraphQL-like output from GraphQL might be easiest?

[MichelDiz]

Not sure about apollo-link-http, cuz Dgraph GraphQL+- isn't compatible with graphql-tag tho.

I had tried before without success hit Apollo link with Dgraph's endpoint, and the request body is different. While /graphql accepts the query in "query key" Dgraph does not have a "Query" field, just a RAW one. But I think this can be evaluated. I'm not Dgraph's dev (go lang), but I'm talking about this situation with the team.

So the main differences are the graphql-tag and the position of the query payload. As apollo-link-rest also uses graphql-tag, I thought of creating a @'directive to inject the Dgraph query (as body) and use GraphQL too. Just like you do in "path:". But this is just speculation. The idea is still premature.

e.g:

const dgraphQ = ` 
{ 
  users (func: has(user), first:1000 ) {
   id : uid
   name
   email
}
}
`;

const query = gql`
      query dgraphTest(
        $customBuilder: any
      ) {
        users @rest(type: "User ", bodyBuilder: $customBuilder, method: "POST") { 
                                         #Maybe bodyKey?? I'll test it
          id
          name
          email
        }
      }
    `;

apolloClient.query({
  query: Query,
  variables: {
    input: { customBuilder: dgraphQ }
  }
}).then(response => {
  console.log(response);
});

Below is the difference between Dgraph's and GraphQL's request body.

GraphQL

POST /graphql HTTP/1.1
Host: api.githunt.com
Content-Type: application/x-www-form-urlencoded
cache-control: no-cache
Postman-Token: xxxxx
query=%7B%0A++++feed+(type%3A+NEW%2C+limit%3A+5)+%7B%0A++++++repository+%7B%0A++++++++owner+%7B+login+%7D%0A++++++++name%0A++++++%7D%0A%0A++++++postedBy+%7B+login+%7D%0A++++%7D%0A++%7D%0A++

Dgraph's GraphQL+-

POST /query HTTP/1.1
Host: play.dgraph.io
Content-Type: application/x-www-form-urlencoded
cache-control: no-cache
Postman-Token: xxxxx
{
  node(func: uid(0x36bb9)) {
    uid
    expand(_all_) {
      uid
      expand(_all_)
    }
  }
}------WebKitFormBoundary7MA4YWxkTrZu0gW--

[a-type]

Going directly to DGraph from the client seems like a challenge, and one which may not leave room for concepts like authorization or business logic. Not that it wouldn't have utility, for sure--a link like you describe would be great for creating a client which easily explores a public graph directly.

I'm interested in using DGraph as the primary datastore for a consumer app, so I'm taking a different approach and trying to make it super easy to interface a standard Apollo Server app to a DGraph backend by converting incoming GraphQL queries into DGraph queries using a custom AST (inspired by projects like join-monster). I'm still kind of whiteboarding the idea in my free time, though, so no promises on delivery.

https://github.com/a-type/dgraphql

Perhaps any query conversion layer which I create could be portable to the clientside too, such that it could be extracted into a reusable library which a hypothetical apollo-link-dgraph could also utilize. Currently, though, I rely pretty heavily on being able to read the schema itself to generate that AST.

[fbartho]

Closing this ticket since it's really about forking other libraries, and pretty out-of-scope for apollo-link-rest

[MichelDiz]

Long time no see! heheh, thanks for the heads up. Actually Dgraph now(about a year +) supports GraphQL natively and also have custom queries that you can add HTTP endpoints. This was a BIG change in Dgraph since late 2019 I guess. But We still use Apollo's tools, like client and so on. I always recommend Apollo.

Cheers!