Как приложения Meteor могут работать в автономном режиме?

Это полезно, когда:

  • сервер не работает, и клиент не может подключиться к синхронизации в реальном времени
  • нет подключения к Интернету
  • пользователь не хочет входить в сеть, но хочет работать с приложением;

Да! Это уже реализовано в Метеор, по большей части.

Если соединение с сервером потеряно, клиент все еще может работать локально. Запись базы данных окажется успешной на клиенте и мгновенно отобразится на экране. Как только соединение будет восстановлено, Meteor повторно отправит все ожидающие запросы метода на сервер и обновит отображение клиента с результатами от сервера. Это результат компенсации латентности, поскольку в автономном режиме рассматривается как очень медленный сервер.

Клиенты могут отслеживать реактивный выход «Meteor.status ()», чтобы увидеть статус текущего соединения. Например, вы можете использовать Meteor.status для запуска всплывающего windows с таймером повторного подключения и кнопкой «connect now», например gmail.

EDIT: конечно, Метеор не волшебство. Если вы нажмете «перезагрузить» или перейдете от страницы и т. Д., В то время как в автономном режиме вы потеряете сессию Метеор и не сможете начать снова, пока не восстановите сеть. Это справедливо для всех веб-приложений с автономным режимом, поэтому это не должно стать сюрпризом для пользователей вашего приложения.

Есть еще пара вариантов, которые могут решить проблему «если ваша вкладка закрывается или вы перезагружаетесь». Я еще не пробовал их, но выгляжу интересно.

https://github.com/awwx/meteor-offline-data :

Метеоритные автономные данные

Главная проекта офлайновых данных Meteor, реализующая «Offline Collection», которая обертывает Meteor.Collection:

Данные с сервера постоянно хранятся в базе данных браузера, что делает его доступным для приложения, даже если приложение запускается в автономном режиме.

Изменения, внесенные пользователем, также сохраняются в базе данных браузера, сохраняя их, если браузер закрыт и снова открыт. При следующем запуске приложения изменения отправляются на сервер.

Обновления активно взаимодействуют между браузерами, открытыми в одном приложении, даже в автономном режиме.

и https://github.com/GroundMeteor/Meteor-GroundDB :

Особенности:

Легкий след

Широкая поддержка браузера Chrome, Safari, Firefox и Internet Explorer 9 Возврат к нормальному Meteor.Collection, если нет localstorage. Возобновление изменений в коллекциях. Возобновление методов. Работа автономного обновления вкладок в кросс-windowsх. Поддержка SmartCollection. Поддержка автономных клиентских баз данных. Использует EJSON.minify. и EJSON.maxify для сжатия данных в localstorage. В будущем на стороне сервера будет настраиваемый обработчик конфликта

Нижняя часть линии:

1) Браузер может полностью сохранить фактический сеанс (каждый раз, когда он запрашивает приложение, потому что получил изменения. Для такого приложения каждые 10 секунд недостаточно, нам нужны все события). Можем ли мы запрограммировать его, скажем, на Firefox? (Но ему нужно было бы сэкономить все (HTML, JS, MinoMongoDB и т. Д. Только за одно изменение!)

2) Или у нас есть полный стек meteorита на стороне клиента, который заботится о местных вещах (собственное локальное приложение), но каким-то образом передает свои операции CRUD другому онлайн-приложению на другой вкладке или экземпляре браузера. (Это второе приложение будет обслуживаться реальным удаленным сервером). Проблема в том, могут ли такие 2 приложения общаться. Я предполагаю, что браузеры запретили бы его по соображениям безопасности)

Еще одна креативная идея может быть: Активировать oplog в стеке клиента. Затем каждый онлайн-доступ и постоянный доступ в Интернет, фактический клиент может быть экспортирован / импортирован в основное приложение (что является еще одним журналом oplog)

3) Если мы не можем отправить запрос call () из полного стека клиента в другой стек meteorита на сервере. (Возможно ли это? Существуют ли некоторые правила ограничения URL-адресов в meteorе)

Но он не фиксирует возможность наличия полного стека meteorов на планшете (я не знаю, что это возможно)

Я не эксперт, но давайте представим решение:

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

Кроме того, некоторые функции могут использоваться только в режиме онлайн (с использованием другого веб-приложения Meteor)

Разумеется, не все части приложения могут использоваться в автономном режиме: создание конфиденциальных записей, некоторые транзакции, поиск, требующий полной коллекции, и т. Д. Функции автономной работы будут работать через локальный веб-сервер машины с уже установленным локальным полным стеком Meteor.

Oplog будет синхронизировать эти автономные БД с зеркальной коллекцией на централизованном сервере, по одному конкретному БД на пользователя, поэтому не все большие данные доступны в автономном режиме на машине пользователя. Идея состоит в том, чтобы поддерживать доступность некоторых функций. В противном случае у нас может быть только одна БД для оффлайновых транзакций для всех пользователей, но oplog будет синхронизировать все эти транзакции во всех автономных БД пользователя. Мы могли бы POST и очистить эти записи как можно скорее, но не хорошо для конфиденциальности. Лучше всего то, что клиентский автономный БД и зеркально отражен на централизованном сервере – будет включать только записи, созданные этим пользователем, или информацию, которую пользователь может потребовать, таким образом, один конкретный БД для каждого пользователя.

Центральная функция на стороне сервера будет регулярно проверять и POST эти записи для большего числа всех пользователей, включая централизованную БД.

Простой способ: все транзакции, выполненные с помощью локального автономного meteorитного приложения, которые будут отправлять транзакции в веб-сервис, когда они будут доступны. (таким образом, пользователям не нужно управлять двумя приложениями, перемещаясь туда и обратно).

Мы могли бы использовать концепцию из двух номеров счетов: номер счета-фактуры продажи: сгенерирован во время транзакции (идентификатор документа?)

Последовательный номер счета-фактуры: для целей бухгалтерского учета, сгенерированный позже (когда онлайн и для документов от 15 до 20 секунд. Мы знаем наверняка все новые счета-фактуры, созданные в этот период)

Идея здесь состоит в том, чтобы локальный meteorитный стек с автомобилем местного сопротивления, синхронизация Oplog с централизованным сопротивлением (если мы не отправляем asynchrone webservice призывы к размещению транзакций в режиме онлайн, но мы теряем аут-син с большей БД)

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

Было бы хорошо, если сообщество более осведомленных людей оценивает и документирует рабочий процесс. Я еще не использовал Meteor, все еще в основном процессе обучения.

Благодаря,

Марк

Давайте будем гением компьютера.