Apollo-link-rest: A Possible support for Dgraph through Raw HTTP endpoint

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_)
    }
  }
}

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.

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.

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

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?

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--

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.