Apollo-link-rest: RawHTTPエンドポイントを介したDgraphのサポートの可能性

Postmanの「Rawbody」を介してDgraphクエリを渡すことができることがわかりました。 これは、Dgraphがapollo-link-restで動作する可能性があることを示しています。

PS。 「bodyBuilder：$ customBuilder」がその方法かもしれないと思います。 しかし、それがどのように機能するかはわかりません。

ところで、 https： //play.dgraph.io/queryに対してテストでき
Postmanをそのエンドポイントにポイントし、「POST」を設定し、BodyにRAWを設定して、以下のクエリを貼り付けます。

UIDは将来変更される可能性があることに注意してください

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

これは大きなプロジェクトのように聞こえます。 -難しい部分はapollo-link-restを使用しているとは思いません-あなたが言ったように、それは基本的にcustomBodyBuilderを使用しているか、 customFetch実装を使用しています。 -難しいのは、正しいDgraph互換のペイロードを「生成」することだと思います。

あなたが理解していることを教えてください-しかし、customFetchの実装として使用されるかなり大規模な「クエリジェネレータ」を作成する必要があるように思えます。

Dgraphは、GraphQLに触発された言語を持つデータベースです。 これは「GraphQL +-」と呼ばれます。 グラフ言語を使用したDBグラフです。 ただし、GraphQLには存在しないが、互換性のある機能はたくさんあります。 そして確かにそれは大きなプロジェクトです。

Dgraphでapollo-link-restをサポートできると思いますが、利用可能なもの（「ハック」など）ですでに何かできるかどうかを理解したかったのです。 Postmanを使用して例示したように、「Body」を送信できるカスタマイズ可能な例は見つかりませんでした。

BodyにRAWテキストを挿入すると、Dgraphをapollo-link-restで機能させる簡単な方法になります。 応答はJSONです。 秘密はありません。

このApolloプロジェクトを見ると、Dgraphには大きな可能性があります。

乾杯。

@ MichelDiz-その場合は、 apollo-link-restをフォークして、apollo-link-dgraphを作成することをお勧めします。

おそらく最善の解決策はapollo-link-httpをフォークすることかもしれませんか？ -そのレイヤーはGraphQLを話すので、GraphQLからGraphQLのような出力を生成するのが最も簡単かもしれませんか？

apollo-link-http、cuz Dgraph GraphQL +-はgraphql-tagthoと互換性がありません。

以前に試したことがありましたが、DgraphのエンドポイントでApolloリンクをヒットしましたが、リクエストの本文が異なります。 / graphqlは「querykey」のクエリを受け入れますが、Dgraphには「Query」フィールドはなく、RAWフィールドだけがあります。 しかし、これは評価できると思います。 私はDgraphの開発者ではありませんが（go lang）、この状況についてチームと話し合っています。

したがって、主な違いは、graphql-tagとクエリペイロードの位置です。 apollo-link-restもgraphql-tagを使用するため、@ 'ディレクティブを作成してDgraphクエリを（本文として）挿入し、GraphQLも使用することを考えました。 「path：」で行うのと同じように。 しかし、これは単なる憶測です。 アイデアはまだ時期尚早です。

例えば：

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

以下は、Dgraphと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++

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

クライアントからDGraphに直接アクセスするのは難しいように思われ、承認やビジネスロジックなどの概念の余地を残さない可能性があります。 確かに、実用性がないわけではありません。あなたが説明するようなリンクは、公開グラフを直接簡単に探索できるクライアントを作成するのに最適です。

コンシューマーアプリのプライマリデータストアとしてDGraphを使用することに興味があるので、別のアプローチを取り、着信GraphQLクエリをDGraphクエリに変換することで、標準のApolloサーバーアプリをDGraphバックエンドに非常に簡単にインターフェースできるようにしようとしています。カスタムASTを使用する（ join-monsterなどのプロジェクトに触発された）。 しかし、私はまだ自由な時間にアイデアをホワイトボードに載せているので、納品の約束はありません。

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

おそらく、私が作成したクエリ変換レイヤーは、クライアント側にも移植可能であり、仮想のapollo-link-dgraphも利用できる再利用可能なライブラリに抽出できます。 ただし、現在、私はスキーマ自体を読み取ってそのASTを生成できることにかなり依存しています。