GraphQL Асинхронные результаты запроса

Question

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

В REST это тривиально. Вы возвращаете 202 и возвращаете заголовок Location, указывающий, куда клиент может go получить результат. GraphQL как спецификация, похоже, не имеет этого понятия; Похоже, что он всегда хочет, чтобы запросы обрабатывались синхронно.

Существует ли какое-либо соглашение для выполнения подобных действий в GraphQL? Мне очень нравится спецификация запроса, но я бы предпочел не оставлять клиентское HTTP-соединение открытым до нескольких минут, пока в бэкэнде выполняется большой запрос. Если что-то случится, чтобы разорвать это соединение, весь запрос нужно будет повторить, даже если сами результаты будут длительными.

Answer 1

То, что вы пытаетесь сделать, нелегко решить с помощью c -совместимого способа. Apollo представил идею директивы @ defer , которая в значительной степени выполняет то, что вы ищете, но все еще является экспериментальной функцией. Я полагаю, что Relay Modern пытается сделать нечто подобное .

Идея, по сути, та же - клиент использует директиву для пометки поля или фрагмента как отложенного. Сервер разрешает запрос, но оставляет отложенное поле пустым. Затем он отправляет одно или несколько исправлений клиенту с отложенными данными. Клиент может применять первоначальный запрос и исправления отдельно к своему кешу, вызывая соответствующие изменения пользовательского интерфейса каждый раз, как обычно.

Answer 2

Я недавно работал над похожей проблемой. Мой вариант использования состоял в том, чтобы отправить задание на создание отчета и предоставить результат пользователю. Создание отчета занимает пару минут, что делает его асинхронным. Я создал мутацию, которая отправила задание в бэкэнд-систему обработки и вернула идентификатор задания. Затем я периодически опрашиваю поле jobs, используя запрос, чтобы узнать о состоянии задания и в конечном итоге о результатах. В результате получается файл, я возвращаю ссылку на другую конечную точку, где его можно загрузить (аналогичный подход используется Github).

Опрос на фактические результаты работает, как и ожидалось, но я думаю, что это может быть лучше решено с помощью подписки.