¿Cómo pueden las aplicaciones de Meteor trabajar sin conexión?

Esto es útil cuando:

  • el servidor está caído y el cliente no puede conectarse para la sincronización en tiempo real
  • no hay conectividad a Internet
  • el usuario no quiere conectarse pero quiere trabajar con la aplicación;

¡Sí! Esto ya está implementado en Meteor, en su mayor parte.

Si se pierde la conexión con el 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 monitorear 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 magia. 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.

Hay otras dos opciones que pueden resolver el problema “si tu pestaña se cierra o vuelves 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 fuera de línea Meteor, implementando una “Colección sin conexión” que envuelve un Meteorito. Colección:

Los datos del servidor se almacenan de manera persistente en la base de datos del navegador, lo que lo pone a disposición de la aplicación incluso si la aplicación se inicia fuera de línea.

Los cambios realizados por el usuario también se guardan en la base de datos del navegador, conservándolos 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 reactivamente a través de las ventanas del navegador abiertas en la misma aplicación, incluso sin conexión.

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

caracteristicas:

Huella de luz

Amplia compatibilidad con el navegador Chrome, Safari, Firefox e Internet Explorer 9 Regreso a Meteor normal.Colección si no hay almacenamiento local Resumen de cambios en colecciones Currículum de métodos Funciona sin conexión actualización de tabs cruzadas Soporte para SmartCollection Soporte para bases de datos fuera del cliente solo en línea Utiliza EJSON.minify y EJSON.maxify para comprimir datos en el almacenamiento local. En el futuro, habrá un controlador de conflictos personalizable en el lado del servidor.

Parte inferior de la línea:

1) El navegador puede guardar completamente la sesión actual (cada cuánto tiempo, cada vez que la aplicación lo solicite porque tiene cambios. Para esa aplicación, cada 10 segundos no es suficiente, necesitamos todos los eventos). ¿Podemos progtwigrlo en, digamos, Firefox? (Pero necesitaría guardar todo (HTML, JS, MinoMongoDB, etc. ¡solo por un cambio!)

2) O tenemos un montón de meteors 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 stack del cliente. Luego, cada back-online y constantemente cuando está en línea, el oplog del cliente real podría exportarse / importarse en la aplicación principal (que es otro registro de oplog),

3) A menos que podamos enviar una solicitud de llamada (call) desde la stack completa de meteors del cliente a otra stack de meteors en el servidor. (¿Es posible? ¿Hay algunas reglas sobre las limitaciones del dominio de URL en el meteor)

Pero no soluciona la posibilidad de tener una stack de meteors llena en una tableta (no estoy al tanto de que sea posible)

No soy un experto, pero imaginemos una solución:

No en una tableta / celular (no estoy seguro si podemos instalar una stack de meteors en dicho dispositivo), pero en el escritorio, el usuario necesita una disponibilidad sin conexión, como punto de venta, algún registro de transacciones, un producto limitado o no actualizado lista, precios e inventario, etc. (Las transacciones que usan acciones que no son físicamente locales, deben «confirmarse (pedido fuera de línea)» (las ubicaciones que tienen ese stock podrían venderse aunque ya estén reservadas por un pedido fuera de línea, que no sean conscientes de, porque ellos o el otro usuario está fuera de línea, especialmente si el usuario que tiene el stock es el que está fuera de línea)

Además de eso, algunas características 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 servidor web de la máquina local con un Meteor instalado completamente local.

Oplog sincronizaría estos DB sin conexión a una colección espejo 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 para todos los usuarios.

Una forma sencilla: todas las transacciones realizadas con la aplicación de meteor local sin conexión que publicará las transacciones en un servicio web cuando esté disponible. (De esta forma, los usuarios no tienen que administrar usando 2 aplicaciones, yendo y viniendo).

Podríamos utilizar un concepto de 2 números de factura: Número de factura de venta: generado en el momento de la transacción (¿la identificación del documento?)

Número de factura secuencial: para fines contables, generado más tarde (cuando está en línea y para un documento de 15 a 20 segundos, viejo. Sabemos con certeza todas las facturas nuevas que se crearon en ese período)

La idea aquí es tener una stack de meteors local teniendo auto de persistencia local, sincronización de Oplog con persistencia centralizada (a menos que enviemos llamadas a un servicio web asincrónico para las transacciones que se publican en línea, pero perdemos automáticamente con la base de datos más grande)

(Después de todo, quizás sea mejor tener 2 aplicaciones en ejecución: 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 indicar al usuario que use la en línea con prioridad y el fuera de línea si 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,

Bagazo