Как использовать Kuzzle & GraphQL, Apollo и Realtime

Question

Я разрабатываю набор сервисов / приложений, позволяющих управлять турнирами по стрельбе из лука. Он состоит из веб-приложения, которое будет управлять созданием различных турниров и будет обрабатывать подписку лучников в качестве претендентов, рассылку по почте и классификации. И мобильное приложение, которое будет установлено на несколько планшетов, которые будут использоваться для аннотирования каждой точки стрелки лучника в реальном времени во время турнира.

Эта последняя часть будет развернута и использована в локальной сети, которая выиграла. t иметь внешний доступ inte rnet (хотя он сможет подключиться для получения данных турнира). Поэтому я решил использовать kuzzle (https://kuzzle.io/) в качестве бэкэнда, поскольку я мог бы развернуть его на сайте, разрабатывая веб-приложение в angular и возможности реального времени.

Единственное, что думают, что не распространяется, значит иметь автономные возможности, поэтому, если аннотационные планшеты потеряли связь с сервером kuzzle, лучники все равно должны иметь возможность записывать точки. Таким образом, одним из решений является определение конечной точки GraphQl в kuzzle (https://github.com/kuzzleio/kuzzle-plugin-graphql) и использование клиента Graphql, который позволяет использовать какой-то автономный кеш, например https://www.apollographql.com/, но я буду по-прежнему не хватает синхронизации в реальном времени, которую обеспечивает Kuzzle.

Есть ли способ / идея о том, как сопоставить запросы apollo graphql со средой выполнения kuzzle, чтобы последняя могла обновить кеш apollo? А какая другая конфигурация лучше?

Answer 1

Здесь член основной команды Kuzzle.

TL; DR - Подписки GQL Live пока не поддерживаются Kuzzle. Вы можете использовать механизм Kuzzle Realtime для подписки на данные и повторного запуска запросов GQL.

Текущие офлайн-возможности, которые предлагает Kuzzle SDK, позволяют восстанавливать действующую подписку при повторном подключении и воспроизводить действия из очереди, которые не могли t может быть отправлен на сервер в автономном режиме, но на самом деле не имеет мнения (или инструмента) о том, как следует обрабатывать несинхронизированные данные.

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

Существует множество решений для внешних баз данных, но они подразумевают, что вы должны удваивать запросы при каждой выборке данных (с разными DSL), затем согласовывать результаты, так как они могут отличаться. Это не невозможно, но это усилие.

Это хорошая мотивация для использования GraphQL вместе с Kuzzle, что неплохо, но живые запросы GraphQL пока не поддерживаются, так что вы не будете иметь возможность использовать запросы GQL для express фильтров подписки в реальном времени. Основная команда активно рассматривает возможность поддержки их в течение этого года.

Временное решение - отказаться на данный момент от GQL Live-Queries и оформить подписку с помощью Kuzzle (посредством звонка realtime.subscribe). Каждый раз, когда подписка получает уведомление, она повторно запускает запрос GQL для получения набора данных fre sh. Единственные накладные расходы будут заключаться в том, что ваш фильтр подписки должен быть выражен в Koncorde DSL, что может раздражать в масштабе, но ИМХО, все еще жизнеспособно.