Apollo-link-rest: A Mögliche Unterstützung für Dgraph über den Raw-HTTP-Endpunkt

Ich habe herausgefunden, dass wir die Dgraph-Abfrage durch den "Rohkörper" in Postman weiterleiten können. Das ist also ein Zeichen dafür, dass möglicherweise Dgraph mit apollo-link-rest funktioniert

PS. Ich denke, dass der "bodyBuilder: $customBuilder" der Weg sein könnte. Aber ich bin mir nicht sicher, wie es funktioniert.

Übrigens, Sie können gegen https://play.dgraph.io/query testen
Richten Sie den Postboten einfach auf diesen Endpunkt, setzen Sie "POST" und in Body stellen Sie RAW ein und fügen Sie die Abfrage unten ein.

Beachten Sie, dass sich die UID in Zukunft ändern kann

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

Das klingt nach einem großen Projekt. -- Ich glaube nicht, dass der schwierige Teil darin besteht, apollo-link-rest -- wie Sie sagten, verwenden Sie im Grunde die customBodyBuilder -Implementierung oder die Verwendung einer customFetch Implementierung. -- Ich denke, der schwierige Teil wird darin bestehen, die richtigen Dgraph -kompatiblen Nutzlasten zu "generieren".

Bitte lassen Sie uns wissen, was Sie herausgefunden haben - aber für mich hört es sich so an, als müssten Sie einen ziemlich umfangreichen "Query-Generator" erstellen, der als customFetch-Implementierung verwendet wird.

Dgraph ist eine Datenbank, deren Sprache von GraphQL inspiriert ist. Es heißt "GraphQL + -". Es ist ein DB-Graphen mit einer Graphensprache. Es gibt jedoch viele Funktionen, die in GraphQL nicht vorhanden sind, aber dennoch kompatibel sind. Und tatsächlich ist es ein großes Projekt.

Ich denke, wir können an Dgraph arbeiten, um apollo-link-rest zu unterstützen, aber ich wollte verstehen, ob ich mit dem, was verfügbar ist, bereits etwas machen kann (wie ein "Hack"). Ich habe keine anpassbaren Beispiele gefunden, die den "Body" senden könnten, wie ich es mit Postman veranschaulicht habe.

Das Injizieren des Bodys mit RAW-Text wäre eine einfache Möglichkeit, Dgraph mit apollo-link-rest zum Laufen zu bringen. Denn die Antwort ist in JSON. Es gibt kein Geheimnis.

Wenn ich mir dieses Apollo-Projekt anschaue, sehe ich großes Potenzial in Dgraph.

Beifall.

@MichelDiz – wenn das der Fall ist, sieht es fast so aus, als ob Sie apollo-link-rest forken und apollo-link-dgraph erstellen möchten

Möglicherweise besteht die beste Lösung darin, apollo-link-http abzuzweigen? -- diese Schicht spricht GraphQL, so dass das Generieren einer GraphQL-ähnlichen Ausgabe von GraphQL am einfachsten ist?

Bei apollo-link-http bin ich mir nicht sicher, da Dgraph GraphQL+- nicht mit dem graphql-tag kompatibel ist.

Ich hatte zuvor ohne Erfolg versucht, den Apollo-Link mit dem Endpunkt von Dgraph zu treffen, und der Anforderungstext ist anders. Während /graphql die Abfrage im "Abfrageschlüssel" akzeptiert, hat Dgraph kein "Abfrage"-Feld, sondern nur ein RAW-Feld. Aber ich denke, das kann man bewerten. Ich bin nicht der Entwickler von Dgraph (go lang), aber ich spreche über diese Situation mit dem Team.

Die Hauptunterschiede sind also das graphql-Tag und die Position der Abfragenutzlast. Da apollo-link-rest auch das graphql-Tag verwendet, dachte ich daran, eine @'-Direktive zu erstellen, um die Dgraph-Abfrage (als Körper) einzufügen und auch GraphQL zu verwenden. Genau wie Sie es in "Pfad:" tun. Aber das ist nur Spekulation. Die Idee ist noch verfrüht.

z.B:

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

Unten ist der Unterschied zwischen dem Anforderungstext von Dgraph und 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+- von 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--

Der direkte Weg vom Kunden zu DGraph scheint eine Herausforderung zu sein, die möglicherweise keinen Raum für Konzepte wie Autorisierung oder Geschäftslogik lässt. Nicht, dass es keinen Nutzen hätte, sicherlich - ein Link wie Sie ihn beschreiben, wäre großartig, um einen Client zu erstellen, der einen öffentlichen Graphen direkt untersucht.

Ich bin daran interessiert, DGraph als primären Datenspeicher für eine Verbraucher-App zu verwenden, daher verfolge ich einen anderen Ansatz und versuche, die Anbindung einer Standard-Apollo-Server-App an ein DGraph-Backend durch die Konvertierung eingehender GraphQL-Abfragen in DGraph-Abfragen sehr einfach zu machen mit einem benutzerdefinierten AST (inspiriert von Projekten wie join-monster ). Ich schreibe die Idee jedoch immer noch in meiner Freizeit auf ein Whiteboard, daher keine Lieferversprechen.

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

Vielleicht könnte jede von mir erstellte Abfragekonvertierungsschicht auch auf die Clientseite portiert werden, sodass sie in eine wiederverwendbare Bibliothek extrahiert werden könnte, die auch ein hypothetisches apollo-link-dgraph könnte. Derzeit verlasse ich mich jedoch ziemlich stark darauf, das Schema selbst lesen zu können, um diesen AST zu generieren.