Как приложения Meteor могут работать в автономном режиме?
Это полезно, когда:
- сервер не работает, и клиент не может подключиться для синхронизации в реальном времени
- нет подключения к интернету
- пользователь не хочет выходить в интернет, но хочет работать с приложением;
4 ответов
да! Это уже реализовано в Meteor, по большей части.
Если соединение с сервером потеряно, клиент все еще может функционировать локально. Записи базы данных будут отображаться успешно на клиенте и мгновенно отражаться на экране. Как только соединение будет восстановлено, Meteor повторно отправит все ожидающие запросы метода на сервер и обновит клиентский дисплей с результатами с сервера. Это все результат компенсации задержки, находясь в автономном режиме рассматриваться как сервер, просто очень медленно.
клиенты могут контролировать реактивный Метеор.status () ' вывод для просмотра состояния текущего соединения. Например, вы можете использовать Meteor.статус диска всплывающее окно с переподключением таймер и подключить кнопку, как Gmail.
EDIT:конечно, Метеор не волшебный. Если вы нажмете "перезагрузить" или переместитесь со страницы и т. д., В автономном режиме вы потеряете сеанс Meteor и не сможете начать снова, пока не восстановите сеть. Это верно для всех веб-приложений с автономным режимом, поэтому это не должно удивлять пользователей вашего приложения.
есть еще несколько вариантов, которые могут решить проблему "если ваша вкладка закрывается или вы перезагружаете". Я еще не пробовал, но выглядит интересно.
https://github.com/awwx/meteor-offline-data:
Метеор Автономных Данных
Дома проекта Метеор данных в автономном режиме, осуществляя "в автономном режиме Коллекция" обертывает "Метеор".Коллекция:
данные с сервера постоянно хранятся в браузере база данных, делая его доступным для приложения, даже если приложение запускается в автономном режиме.
изменения, внесенные пользователем, сохраняются в базе данных браузера , сохранение их, если браузер закрыт и снова открыт. Следующий раз приложение выходит в интернет, изменения отправляются на сервер.
обновления реактивно разделяются через окна браузера, открытые на том же применение, даже пока не в сети.
и https://github.com/GroundMeteor/Meteor-GroundDB:
характеристики:
светлый след
широкая поддержка браузера Chrome, Safari, Firefox и Internet Explorer 9 Возврат к нормальному метеориту.Коллекция, если нет localStorage резюме изменения в коллекциях резюме методов работы offline обновление cross окно вкладки для поддержки SmartCollection для форума на стороне клиента базы данных использует EJSON.minify и EJSON.для MAXIFY для сжатие данных в localstorage в будущем появится настраиваемый обработчик конфликтов на стороне сервера
внизу строка:
1) либо браузер может полностью сохранить фактический сеанс (каждый сколько времени? каждый раз, когда приложение запрашивает его, потому что есть изменения. Для такого приложения каждые 10 секунд недостаточно, нам нужны все события). Можем ли мы запрограммировать его, скажем, в Firefox? (Но ему нужно будет сохранить все (HTML, JS, MinoMongoDB и т. д. хотя бы для разнообразия!)
2) или у нас есть клиентский полный стек meteor, заботящийся о локальном материале (локальное приложение), но как-то передача своих операций CRUD другому онлайн-приложению на другой вкладке или экземпляре браузера. (Это 2-е приложение будет обслуживаться реальным удаленным сервером) проблема в том, что такие 2 приложения могут общаться. Я полагаю, браузеры запретили бы это по соображениям безопасности)
еще одна более творческая идея может быть: активировать oplog в стеке клиента. Затем, каждый back-online и постоянно в интернете, фактический клиентский oplog может быть экспортирован/импортирован в основное приложение (которое является другим oplog log),
3) Если мы не можем отправить запрос call () из полного стека meteor клиента в другой стек meteor на сервере. (Возможно ли это? Есть ли некоторые правила об ограничениях домена URL в meteor)
но это не фиксирует возможность иметь полный метеоритный стек на планшете (я не знаю, что это возможно)
Я не эксперт, но давайте представим себе решение:
не на планшете / ячейке (не уверен, что мы можем установить стек meteor на таком устройстве), но на рабочем столе пользователю нужна автономная доступность, такая как точка продажи, некоторое ведение журнала транзакций, ограниченный или не обновленный список продуктов, цены и инвентарь и т. д. (Транзакции с использованием акций, которые физически не являются локальными, должны быть " подтверждены (офлайн-заказ) " (Места, имеющие этот запас, могут продаваться, даже если они уже зарезервированы по оффлайн-заказу, о котором они не знают, потому что они или другой пользователь находятся в автономном режиме, особенно если пользователь, имеющий запас, находится в автономном режиме)
кроме того, некоторые функции могут использоваться только в интернете (с помощью другого веб-приложения Meteor)
конечно, не все части приложения можно использовать в автономном режиме: чувствительный запись творения, некоторые операции, поисков, которые нуждаются в полном сборе, и т. д. Автономные функции будут работать через веб-сервер локального компьютера с работающим местным полным штабелем Meteor уже установлен.
Oplog синхронизирует эти автономные БД с зеркальной коллекцией на централизованном сервере, одна конкретная БД на пользователя, поэтому не все большие данные доступны в автономном режиме на компьютере пользователя. Идея в том, чтобы поддерживать доступность некоторых функций. В противном случае мы могли бы иметь только одну БД для автономных транзакций всех пользователей, но oplog будет синхронизировать все эти транзакции на автономной БД всех пользователей. Мы могли бы опубликовать и очистить эти записи как можно скорее, но не годится для уединения. Лучше всего, что автономная БД клиента – и зеркально отраженная на централизованном сервере-будет включать только записи, созданные этим пользователем, или информацию, которая может понадобиться пользователю, таким образом, одна конкретная БД на пользователя.
функция центрального сервера будет регулярно проверять и публиковать эти записи в более крупную централизованную БД всех пользователей включительно.
простой способ : всех сделок совершается с местными оффлайн приложение Метеор, что бы разнести проводки по WebService при доступный. (таким образом, пользователям не нужно управлять с помощью 2-х приложений, идя туда и обратно.)
мы могли бы использовать концепцию 2 номеров счетов-фактур : Номер счета продажи: генерируется во время транзакции (идентификатор документа?)
последовательный номер счета-фактуры : для целей бухгалтерского учета, сгенерированный позже (в режиме онлайн и для документа от 15 до 20 сек. Старый. Мы точно знаем все новые счета, созданные за этот период)
идея здесь состоит в том, чтобы иметь локальный стек метеоров принимая автомобиль местного упорства, Синхронизация Oplog с централизованным сохранением (если мы не отправляем asynchrone WebService вызовы для проводки транзакций в интернете, но мы теряем auto sinc с большей БД)
(В конце концов, может быть, лучше иметь 2 приложения работает: на локальном, один центральный служил и способ, чтобы эти 2 говорить вместе, или онлайн и оффлайн приложение с удобным способом направить пользователя, чтобы использовать онлайн в приоритете и в автономном режиме, если в автономном режиме)
было бы хорошо, если сообщество более знающих людей оценивает и документирует рабочий способ. Я еще не использовал Meteor, все еще в основном процессе обучения.
спасибо,
Марк