Первая автономная поддержка Apollo: Service Worker или Persisted Cache? - PullRequest
0 голосов
/ 25 июня 2018

У меня есть приложение реагирования, которое использует apollo в качестве клиента grapql.Приложение теперь нуждается в автономной поддержке подмножества / подпапки.Есть сервисный работник (благодаря workbox и webpack), который выполняет предварительное кэширование ресурсов приложения и работает хорошо.Теперь необходимо добавить поддержку данных.Приложение должно работать в автономном режиме, как в режиме онлайн.Это означает, что пользователь должен иметь возможность видеть все данные и выполнять несколько мутаций, которые необходимо будет синхронизировать при повторном подключении приложения.

У меня есть следующие подходы в качестве возможных решений: * Используйтеработник службы: добавьте кнопку, которая запускает набор запросов, чтобы получить все необходимые данные для автономной работы.Используйте работника службы (workbox runtimeCaching) для кэширования всех ответов на эти запросы.Когда приложение переходит в автономный режим, работник сервиса «обслуживает» ответ на запросы, поэтому приложение будет работать «как в режиме онлайн», выполняя запросы в обычном режиме, а работник сервиса выступает в качестве «прокси».Установите подход «оптимистический пользовательский интерфейс» для мутаций и используйте workbox backgroundSync для синхронизации изменений (в основном отправьте действие мутации обратно в конечную точку, когда браузер снова подключится).Используйте некоторый нативный подход apollo (например, apollo-cache-persist) для хранения кэша запросов в localStorage.Запустите все требуемые запросы для приложения, сохраните этот кэш, повторно загрузите приложение из кеша для дальнейшей загрузки, если приложение не подключено к сети.

Что было бы лучше и проще для автономного веб-приложения =

...