Преодолейте ограничения PWA и обеспечьте беспроблемный пользовательский интерфейс

Если вы читаете первый пост этой серии, у вас должна быть прочная база по этому поводу.
Такие термины, как service workers, web app manifest, cache API, должны быть вам знакомы и, вероятно, вы уже начали обновление своего проекта с помощью изученных прогрессивных функций.

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

Так что берите кофе, устраивайтесь поудобнее и приступим!

Ограничения Cache API

Ранее мы узнали, что Cache API позволяет кэшировать только GET Requests, но в настоящее время POST nor PUT это невозможно.
Если вы попытаетесь кэшировать запрос, отличный от GET, вы получите следующую ошибку: TypeError: Invalid request method POST. (здесь в случае, если мы отправили POST ).

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

Для этого необходимо разработать индивидуальные решения, позволяющие преодолеть это ограничение. Например, мы можем определить, когда клиент находится в автономном режиме, и в этом случае сохранить в индексированной БД значения, которые пользователь ввел в формы и попытался отправить на сервер.
Затем, когда подключение пользователя к сети восстановлено, наше приложение должно отправить все ожидающие изменения. Мы также должны спланировать, как обрабатывать исключения в случае сбоя POST и как это должно повлиять на другие кэшированные запросы.

Другая возможность предоставляется Cloud Firestore.

Cloud Firestore

Cloud Firestore - это гибкая, масштабируемая база данных NoSQL для разработки мобильных приложений, Интернета и серверов с помощью Firebase и Google Cloud Platform. Он обеспечивает синхронизацию данных между клиентскими приложениями с помощью слушателей в реальном времени и предлагает автономную поддержку для мобильных устройств и Интернета, чтобы вы могли создавать адаптивные приложения, которые работают независимо от задержки в сети или подключения к Интернету.

Данные в базе данных Firestore сохраняются как объекты json (структура ключ: значение) с именем Documents и содержатся в Collections. Эта организация упрощает проектирование объектов домена (сохраняемых в базе данных) аналогично тому, как это делают наши DTO веб-приложений.

Платформа Firebase также предлагает щедрый уровень бесплатного пользования:

Таким образом, мы можем использовать его для наших личных проектов или демонстраций, не беспокоясь о начальных затратах.

Я оставлю отдельную статью, чтобы более подробно описать платформу Firebase и другие функции Cloud Firestore. Здесь мы сосредоточимся на его offline persistence функциональности.

Автономное постоянство

Автономное хранилище включено по умолчанию для мобильной разработки, но не для Интернета. Мы должны активировать его явно, вызвав метод enablePersistence:

// Register Firebase Keys
firebase.initializeApp({
  apiKey: '### FIREBASE API KEY ###',
  authDomain: '### FIREBASE AUTH DOMAIN ###',
  projectId: '### CLOUD FIRESTORE PROJECT ID ###',
} ,"myDemoApp");


// Enable offline support
firebase.firestore().enablePersistence()
  .catch(function(err) {
      if (err.code == 'unimplemented') {
          // The current browser does not support all of the
          // features required to enable persistence
      }
  });
});

С этого момента любой документ, полученный с сервера, сохраняется локально в индексированной БД. Теперь мы можем читать, редактировать или удалять любой кэшированный документ даже без подключения к сети. Если в кеше нет запрошенного документа, возвращается ошибка.
Все ожидающие локальные изменения автоматически синхронизируются с БД на сервере, как только пользователь возвращается в онлайн.

Представим себе, что мы путешествуем на поезде без подключения к сети, постоянно переходя в офлайн и онлайн.

Знакомо, не правда ли?

Тем не менее, наше приложение по-прежнему будет доступно и даже позволит изменять его содержимое (пока у нас есть запрошенные документы в кеше). Мы разработали PWA, работающий без проблем как в сети, так и в автономном режиме.

Мы можем анализировать кэшированные данные на вкладке «Приложение» в DevTools (при использовании Chrome):

По умолчанию лимит кеша составляет 40 МБ. После превышения этой квоты Firestore пытается очистить старые документы до тех пор, пока размер кеша не станет меньше установленного лимита. Можно указать другой порог (минимальное значение должно быть 1 МБ) или полностью отключить процесс выселения:

firebase.firestore().settings({
  cacheSizeBytes: firebase.firestore.CACHE_SIZE_UNLIMITED
});

Ограничения Firestore

Однако, прежде чем решить использовать Firestore в нашем приложении, мы должны знать о некоторых ограничениях:

  • Разрешено не более 500 офлайн-транзакций
    Инженеры Google явно установили такое ограничение, поскольку офлайн-постоянство предназначено для покрытия временного прерывания соединения и не должно использоваться в течение длительного времени.
  • Политика одновременных обновлений - «победа по последней записи»
    Если имеется несколько обновлений для одного и того же документа в базе данных, будет сохранена последняя запись, поступившая на сервер. Это может привести к потенциальному сохранению более старых данных, если они поступают от клиента, который был в автономном режиме и теперь синхронизирует свои ожидающие изменения.

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

Первоначально опубликовано на https://dev.to 15 июля 2019 г.