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

Ответ 1

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

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

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

РЕДАКТИРОВАТЬ: Конечно, Метеор не волшебный. Если вы нажмете "перезагрузить" или перейдете от страницы и т.д., В то время как в автономном режиме вы потеряете сессию Метеор и не сможете начать снова, пока не восстановите сеть. Это справедливо для всех веб-приложений с автономным режимом, поэтому это не должно стать неожиданностью для пользователей вашего приложения.

Ответ 2

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

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

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

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

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

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

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

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

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

Легкий след

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

Ответ 3

Нижняя часть строки:

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

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

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

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

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

Ответ 4

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо,

Марк