Apollo-link-rest: Возможная поддержка Dgraph через конечную точку Raw HTTP

Я обнаружил, что мы можем передать запрос Dgraph через "необработанное тело" в Postman. Так что это признак того, что возможно 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 + -». Это граф БД с языком графов. Однако есть много функций, которых нет в GraphQL, но которые по-прежнему совместимы. И действительно, это большой проект.

Я думаю, что мы можем работать над Dgraph для поддержки apollo-link-rest, но я хотел понять, могу ли я уже что-то сделать с тем, что доступно (например, «Взлом»). Я не нашел никаких настраиваемых примеров, которые могли бы отправлять "Body", как я показал, используя Postman.

Внедрение 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, потому что Dgraph GraphQL + - несовместим с graphql-tag, хотя.

Раньше я безуспешно пытался попасть по ссылке Apollo с конечной точкой Dgraph, и тело запроса было другим. Хотя / graphql принимает запрос в «ключе запроса», Dgraph не имеет поля «Запрос», только RAW. Но я думаю, это можно оценить. Я не разработчик Dgraph, но я говорю об этой ситуации с командой.

Таким образом, основные отличия заключаются в теге graphql и положении полезной нагрузки запроса. Поскольку 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'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--

Переход непосредственно к DGraph от клиента кажется проблемой, и она может не оставлять места для таких понятий, как авторизация или бизнес-логика. Не то чтобы в этом точно не было бы полезности - ссылка, подобная описанной вами, отлично подойдет для создания клиента, который легко исследует общедоступный граф напрямую.

Я заинтересован в использовании DGraph в качестве основного хранилища данных для потребительского приложения, поэтому я использую другой подход и пытаюсь упростить интерфейс стандартного приложения Apollo Server с серверной частью DGraph путем преобразования входящих запросов GraphQL в запросы DGraph. используя собственный AST (вдохновленный такими проектами, как join-monster ). Тем не менее, в свободное время я все еще обсуждаю эту идею, так что никаких обещаний по доставке нет.

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

Возможно, любой уровень преобразования запросов, который я создаю, можно было бы переносить и на клиентскую сторону, чтобы его можно было извлечь в повторно используемую библиотеку, которую также мог бы использовать гипотетический apollo-link-dgraph . Однако в настоящее время я очень сильно полагаюсь на то, что могу прочитать саму схему для создания этого AST.