Apollo-link-rest: Un support possible pour Dgraph via le point de terminaison HTTP brut

J'ai découvert que nous pouvons passer la requête Dgraph via le "corps brut" dans Postman. C'est donc un signe que Dgraph pourrait peut-être fonctionner avec apollo-link-rest

PS. Je pense que le "bodyBuilder: $customBuilder" peut être la solution. Mais je ne sais pas comment cela fonctionne.

BTW, vous pouvez tester sur https://play.dgraph.io/query
pointez simplement le facteur sur ce point de terminaison, définissez "POST" et dans Body, définissez RAW et collez la requête ci-dessous.

Faites attention que l'UID peut changer à l'avenir

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

Cela ressemble à un grand projet. -- Je ne pense pas que la partie difficile soit d'utiliser apollo-link-rest -- comme vous l'avez dit, il s'agit essentiellement d'utiliser la customBodyBuilder , ou d'utiliser une implémentation de customFetch . -- Je pense que la partie la plus difficile sera de "générer" les bonnes charges utiles compatibles Dgraph .

S'il vous plaît laissez-nous savoir ce que vous comprenez - mais il me semble que vous devrez créer un "générateur de requêtes" assez complet qui serait utilisé comme implémentation customFetch.

Dgraph est une base de données dont le langage est inspiré de GraphQL. Cela s'appelle "GraphQL + -". C'est un graphe DB avec un langage graphique. Cependant, de nombreuses fonctionnalités n'existent pas dans GraphQL, mais sont toujours compatibles. Et effectivement c'est un gros projet.

Je pense que nous pouvons travailler sur Dgraph pour prendre en charge apollo-link-rest, mais je voulais comprendre si je peux déjà faire quelque chose avec ce qui est disponible (comme un "Hack"). Je n'ai trouvé aucun exemple personnalisable qui pourrait envoyer le "Corps" comme je l'ai illustré en utilisant Postman.

Injecter le corps avec du texte RAW serait un moyen facile de faire fonctionner Dgraph avec apollo-link-rest. Parce que la réponse est en JSON. Il n'y a pas de secret.

En regardant ce projet Apollo, je vois un grand potentiel avec Dgraph.

Acclamations.

@MichelDiz -- si c'est le cas, on dirait presque que vous voudrez peut-être forker apollo-link-rest et créer apollo-link-dgraph

La meilleure solution serait peut-être de forker apollo-link-http ? -- cette couche parle GraphQL, donc générer une sortie de type GraphQL à partir de GraphQL pourrait être plus simple ?

Pas sûr d'apollo-link-http, car Dgraph GraphQL+- n'est pas compatible avec graphql-tag tho.

J'avais déjà essayé sans succès d'atteindre le lien Apollo avec le point de terminaison de Dgraph, et le corps de la requête est différent. Alors que /graphql accepte la requête en "clé de requête", Dgraph n'a pas de champ "Requête", juste un champ RAW. Mais je pense que cela peut être évalué. Je ne suis pas le dev (go lang) de Dgraph, mais je parle de cette situation avec l'équipe.

Les principales différences sont donc la balise graphql et la position de la charge utile de la requête. Comme apollo-link-rest utilise également graphql-tag, j'ai pensé à créer une directive @' pour injecter la requête Dgraph (en tant que corps) et utiliser également GraphQL. Tout comme vous le faites dans "path:". Mais ce n'est que spéculation. L'idée est encore prématurée.

par exemple:

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

Vous trouverez ci-dessous la différence entre le corps de requête de Dgraph et de GraphQL.

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

GraphQL de Dgraph+-

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

Passer directement à DGraph depuis le client semble être un défi, et qui peut ne pas laisser de place à des concepts tels que l'autorisation ou la logique métier. Non pas que cela n'aurait pas d'utilité, bien sûr - un lien comme celui que vous décrivez serait idéal pour créer un client qui explore facilement un graphe public directement.

Je suis intéressé par l'utilisation de DGraph comme magasin de données principal pour une application grand public, donc j'adopte une approche différente et j'essaie de rendre très facile l'interface d'une application Apollo Server standard à un backend DGraph en convertissant les requêtes GraphQL entrantes en requêtes DGraph en utilisant un AST personnalisé (inspiré de projets comme join-monster ). Cependant, je suis toujours en train de mettre l'idée sur un tableau blanc pendant mon temps libre, donc aucune promesse de livraison.

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

Peut-être que toute couche de conversion de requête que je crée pourrait également être portable côté client, de sorte qu'elle puisse être extraite dans une bibliothèque réutilisable qu'un hypothétique apollo-link-dgraph pourrait également utiliser. Actuellement, cependant, je compte beaucoup sur la capacité de lire le schéma lui-même pour générer cet AST.