Esto es útil cuando:¿Cómo pueden funcionar las aplicaciones Meteor sin conexión?
Sí! Esto ya está implementado en Meteor, en su mayor parte.
Si se pierde la conexión al servidor, el cliente aún puede funcionar localmente. Las escrituras de la base de datos aparecerán para tener éxito en el cliente y reflejarán instantáneamente en la pantalla. Una vez que se restablezca la conexión, Meteor volverá a enviar todas las solicitudes de métodos pendientes al servidor y actualizará la pantalla del cliente con los resultados del servidor. Esto es todo el resultado de la compensación de latencia, estar fuera de línea se trata como si el servidor fuera muy lento.
Los clientes pueden controlar la salida reactiva 'Meteor.status()' para ver el estado de la conexión actual. Por ejemplo, podría usar Meteor.status para activar una ventana emergente con un temporizador de reconexión y un botón "conectar ahora", como gmail.
EDITAR: por supuesto, Meteor no es mágico. Si presiona "recargar", o navega fuera de la página, etc., mientras está fuera de línea, perderá su sesión Meteor y no podrá volver a comenzar hasta que recupere la red. Sin embargo, esto es cierto para todas las aplicaciones web con modo fuera de línea, por lo que no debería ser una sorpresa para los usuarios de su aplicación.
Esta es la respuesta gracias n1mmy – dennis
Sería interesante almacenar registros sucios en el cliente en LocalStorage cuando la conexión no está disponible, de modo que en caso de que se pierda el estado de la página local, se pueden recuperar. Me gustaría ver esta funcionalidad en meteorito. También estoy realmente interesado en explorar maneras de almacenar todo el conjunto de datos localmente (posiblemente como un archivo en el manifiesto de caché de la aplicación) para que la aplicación se pueda volver a abrir y usar sin conexión, pero este es un requisito difícil. –
Desarrollé una biblioteca que permite que su aplicación Backbone.js trabaje fuera de línea con el mismo algoritmo. https://github.com/Ask11/backbone.offline –
Existen otras dos opciones que pueden resolver el problema 'si la pestaña se cierra o vuelve a cargar'. No los he probado todavía pero me veo interesante.
https://github.com/awwx/meteor-offline-data:
Meteor datos fuera de línea
Inicio del proyecto de datos en línea Meteor, la implementación de un "Desconectado Collection", que envuelve un Meteor.Collection:
de datos desde el servidor es almacenado persistentemente en la base de datos del navegador, poniéndolo a disposición de la aplicación incluso si la aplicación inicia sin conexión.
Los cambios realizados por el usuario también se guardan en la base de datos del navegador, y se conservan si el navegador se cierra y se vuelve a abrir. La próxima vez que la aplicación se conecte, los cambios se enviarán al servidor.
Las actualizaciones se comparten de forma reactiva en todas las ventanas del navegador abiertas en la misma aplicación , incluso sin conexión.
y https://github.com/GroundMeteor/Meteor-GroundDB:
Características:
huella de luz
soporte de los navegadores Amplio Chrome, Safari, Firefox e Internet Explorer 9 retorno a la normalidad de meteoritos.Colección si no localStorage Currículum de cambios en las colecciones Currículum de métodos Trabajos fuera de línea actualización cruzada ventanas pestañas Soporte para SmartCollection Soporte para fuera de línea bases de datos del lado del cliente Usa EJSON.minify y EJSON.maxify para comprime datos en localstorage En el futuro hay será un controlador de conflicto personalizable en el lado del servidor
no soy un experto, pero imaginemos una solución:
noen una tableta/célula (no estoy seguro que podemos instalar una pila de meteoritos en dicho dispositivo), pero en el escritorio, el usuario necesita una disponibilidad fuera de línea, como punto de venta, registro de transacciones, lista de productos, precios e inventario limitados o no actualizados, etc. (Las transacciones que usan acciones que no son físicamente locales, deben ser «pendientes de confirmación (pedido fuera de línea)» (Las ubicaciones que tengan ese stock podrían venderse incluso si ya reservados por un pedido fuera de línea, que no conocen, porque ellos o el otro usuario están desconectados, especialmente si el usuario que tiene el stock es el que está fuera de línea)
Además de eso, algunas funciones solo se pueden usar en línea (usando otra aplicación web Meteor)
Por supuesto, no todas las partes de la aplicación se pueden usar fuera de línea: creaciones de registros delicados, algunas transacciones, búsquedas que necesitan la colección completa, etc. Las características fuera de línea funcionarían a través del mac local hine webserver con un Meteorito local totalmente instalado que ya está instalado.
Oplog sincronizaría estos DB sin conexión a una colección reflejada en el servidor centralizado, una base de datos específica por usuario, de modo que no todos los big data disponibles fuera de línea en la máquina del usuario. La idea es mantener la disponibilidad de algunas funciones. De lo contrario, podríamos tener solo una base de datos para las transacciones fuera de línea de todos los usuarios, pero oplog sincronizaría todas estas transacciones en todos los DB sin conexión del usuario. Podríamos PUBLICAR y borrar estos registros lo antes posible, pero no es bueno para la privacidad. Lo mejor es que la base de datos fuera de línea del cliente, y reflejada en el servidor centralizado, incluya solo registros creados por ese usuario o información que el usuario podría necesitar, por lo tanto, una base de datos específica por usuario.
Una función central del lado del servidor validaría regularmente y PUBLICARía estos registros a la base de datos centralizada más grande de todos los usuarios.
Una manera simple: todas las transacciones se realizan con la aplicación de meteorito local sin conexión que publicará las transacciones en un servicio web cuando esté disponible. (De esta manera, los usuarios no tienen que gestionar el uso de 2 aplicaciones, que van y vienen.)
podríamos utilizar un concepto de 2 números de factura: número de factura venta: (? El ID de documento) generado en el tiempo de transacción
Número de factura secuencial: para fines de contabilidad, se genera más adelante (cuando está en línea y para el documento de 15 a 20 segundos.Sabemos con certeza todas las facturas nuevas que se crearon en ese período)
La idea aquí es tener una pila de meteoritos locales teniendo auto de persistencia local, Oplog sincronizando con persistencia centralizada (a menos que enviemos llamadas de servicio web asynchrone para las transacciones contabilizadas cuando en línea, pero perdemos automáticamente sinc con la base de datos más grande)
(Después de todo, tal vez sea mejor tener 2 aplicaciones ejecutándose: en local, una central servida y una manera de permitir que estas 2 hablen juntas, o una aplicación en línea y fuera de línea con una manera cómoda de dirigir al usuario a usar el en línea con prioridad y el fuera de línea si está fuera de línea)
Sería bueno si la comunidad de personas más conocedoras evalúa y documenta una forma de trabajo. Todavía no utilicé Meteor, todavía en el proceso básico de aprendizaje.
Gracias,
Marc
Si bien tu respuesta es bastante completa, creo que te estás perdiendo un poco el tema. – Dave
Claro, estoy evaluando las posibilidades, pero no estoy seguro de cuál es la mejor solución. (Por cierto, tal vez haya actualizado mi publicación desde que la leíste) Estaría encantado de obtener precisiones sobre el punto que me falta. Gracias de cualquier manera. – EMHmark7
inferior de la línea:
1) o bien el navegador puede salvar por completo la sesión real (cada cuánto tiempo cada vez que la aplicación lo solicite porque tiene cambios para?. tal aplicación, cada 10 segundos no es suficiente, necesitamos todos los eventos). ¿Podemos programarlo en, digamos, Firefox? (Pero necesitaría guardar todo (HTML, JS, MinoMongoDB, etc. ¡solo por un cambio!)
2) O tenemos un montón de meteoritos completo del lado del cliente que se ocupa de las cosas locales (una aplicación local propia) pero de alguna manera comunica sus operaciones CRUD a otra aplicación en línea en otra pestaña o instancia del navegador. (Esa segunda aplicación sería atendida por el servidor remoto real) El problema es si esas 2 aplicaciones se pueden comunicar. Supongo que los navegadores lo prohibirían por razones de seguridad)
Otra idea más creativa podría ser: activar oplog en la pila del cliente. Luego, cada back-online y constantemente en línea, el oplog del cliente real podría exportarse/importarse en la aplicación principal (que es otro registro oplog)
3) A menos que podamos enviar una solicitud call() del meteorito del cliente pila completa a otra pila de meteoritos en el servidor. (¿Es posible? ¿Hay algunas reglas acerca de las limitaciones de dominio URL en meteoritos)
Pero no fija la posibilidad de tener una pila de meteoritos completa en una tableta (no soy consciente de lo shuch es posible)
No
de fábrica, por supuesto, es posible implementar una solución completa fuera de línea, pero eso son miles de líneas de código – Raynos
. Esto se está abordando en parte por la aplicación próximamente: http://devel-docs.meteor.com/#appcache (al menos el manifiesto de caché HTML5). ¡Luciendo bien! – Vindberg
¿Qué sucede si uno necesita desarrollar una aplicación móvil completa sin conexión? [Mi pregunta] (http://stackoverflow.com/questions/27893600/meteor-for-non-internet-mobile-app) no tiene respuesta. Cualquiera con ideas –