javascript angularjs symfony data-synchronization offlineapps

javascript - Práctica recomendada para la sincronización de datos on/off line con AngularJS y Symfony 2



data-synchronization offlineapps (5)

Parece que quieres muchas cosas, la sincronización es difícil ... Tengo una solución para algunas de estas cosas en una biblioteca de OSS que estoy desarrollando. La idea es que haga versiones de datos locales, para que pueda descubrir qué ha cambiado y, por lo tanto, realizar una sincronización significativa, que también incluye resolución de conflictos, etc. Esta es una especie de meteoro fuera de línea ya que está realmente sintonizado para uso fuera de línea (para el metro de Londres donde no tenemos señales de datos móviles).

También he desarrollado un sistema ecológico que incluye un administrador de conexión y servidor. El proyecto principal está en https://github.com/forbesmyester/SyncIt y está muy bien documentado y probado. La aplicación de prueba para el ecosistema estará en https://github.com/forbesmyester/SyncItTodoMvc, pero todavía no he escrito prácticamente ningún documento.

Actualmente está utilizando LocalStorage, pero será fácil moverlo a localForage, ya que en realidad está usando un contenedor alrededor de localStorage para convertirlo en una API asíncrona ... ¿Otra más para la lista?

Estoy construyendo una aplicación web relativamente compleja y de datos pesados ​​en AngularJS. Estoy planeando usar php como backend RESTful (con symfony2 y FOSRESTbundle). Pasé semanas buscando soluciones diferentes para las soluciones de sincronización en línea y fuera de línea, y parece haber muchas medias soluciones (consulte la lista a continuación para ver algunos ejemplos). Pero ninguno de ellos parece encajar perfectamente en mi situación. ¿Cómo puedo decidir qué estrategia me servirá?

Los problemas que podrían determinar las "mejores prácticas" para construir un sistema de sincronización on / off en AngularJS y Symfony 2 necesitan algunas investigaciones, pero en la parte superior de mi cabeza quiero considerar cosas como la velocidad, la facilidad de implementación, la prueba de futuro (duradera solución), extensibilidad, uso / requisitos de recursos en el lado del cliente, tener múltiples usuarios fuera de línea que editan los mismos datos, cuánto y qué tipo de datos almacenar.

Algunos de mis requisitos que conozco actualmente son:

  • Los usuarios estarán fuera de línea a menudo y luego necesitan sincronizar datos (creados localmente) con la base de datos.
  • Múltiples usuarios comparten algunos de los datos editables (se deben considerar posibles problemas de fusión).
  • El usuario puede haber iniciado sesión desde múltiples dispositivos al mismo tiempo.
  • Permitir que gran cantidad de datos se almacenen fuera de línea (hasta un gigabyte)
  • Probablemente quiera que el usuario pueda decidir qué quiere almacenar localmente.
  • Incluso si el usuario está en línea, probablemente quiera que el usuario pueda elegir si usa todos los datos (back-end) o solo los que están disponibles localmente.

Algunas posibles soluciones de ejemplo

  • PouchDB: estrategias interesantes para sincronizar los cambios de múltiples fuentes
  • Racer - Node lib para la sincronización en tiempo real, construir en ShareJS
  • Meteor - DDP y estrategias para la sincronización
  • ShareJS: transformación operativa de Node.js, inspirada en Google Wave
  • Restangular - Alternativa a $ recurso
  • EmberData - biblioteca de persistencia de datos ORM-like de EmberJS
  • Trabajador del servicio
  • IndexedDB Polyfill - Polyfill IndexedDB con navegadores compatibles con WebSQL (Safari)
  • BreezeJS
  • JayData
  • ORM de Loopback
  • ActiveRecord
  • Modelos BackBone
  • lawnchair - Ligero cliente DB DB de Brian Leroux
  • TogetherJS - Libración de colaboración / sincronización multi-cliente de Mozilla Labs.
  • localForage - La biblioteca de mejora DOMStorage de Mozilla.
  • Orbit.js - Biblioteca de sincronización de contenido

( https://docs.google.com/document/d/1DMacL7iwjSMPP0ytZfugpU4v0PWUK0BT6lhyaVEmlBQ/edit#heading=h.864mpiz510wz )

Cualquier ayuda sería muy apreciada :)

https://www.firebase.com/ es confiable y probado, y se puede utilizar como biblioteca de back-end y sincronización para lo que está buscando. pero, cuesta, y requiere alguna codificación de integración.
https://goinstant.com/ también es una buena opción alojada.

En algunas de mis aplicaciones, prefiero tener ambas: la sincronización de la fuente de db Y de otra base de datos principal. ( mogno / express, php / mysql, etc. ). luego, cada db maneja lo que es mejor con sus funciones (en tiempo real frente a seguridad, etc.). Esto es cierto independientemente del proveedor sync-db ( ya sea Racer o Firebase o GoInstant ... )

La aplicación que estoy desarrollando tiene muchos de los mismos requisitos y se está construyendo en AngularJS. En términos de pruebas futuras, hay dos preocupaciones principales que he encontrado, una son los intentos de piratería que requieren cifrado y posible uso de claves de un solo uso y un administrador de claves de back-end y la otra es soporte para WebSQL que el consorcio de estándares indesedDB. Por lo tanto, encontrar una capa de abstracción que pueda admitir ambos es importante. El conjunto de soluciones que he propuesto es bastante directo. Donde los datos fuera de línea se cargan primero en la interfaz de usuario y se envía una solicitud al servidor REST si se encuentra en un estado en línea. En cuanto a la resolución de conflictos de datos en un entorno multiusuario, se convierte en una decisión de regla empresarial. Mi decisión fue simplificar el asunto y no profundizar en las fusiones de datos, sino utilizar una comparación de estampillas de microtime para determinar qué versión debería conservarse y enviarse a los clientes. Cuando está en modo fuera de línea, almacene datos como una escritura sucia y la inserción en el servidor al volver a un estado en línea.

O use ydn-db, que estoy evaluando ahora ya que tiene compatibilidad incorporada para AWS y el almacenamiento en la nube de Google.

Para trabajar fuera de línea con sus requisitos, sugiero dividir el problema en dos escenarios: contenido (html, js, css) y datos (RESTO API).

El contenido

Se almacenará fuera de línea mediante la aplicación para aplicaciones pequeñas o para casos avanzados con los asombrosos trabajadores del servicio . Chrome 40+.

Los datos

Requiere resolver el almacenamiento y la sincronización y se convierte en un problema más difícil. Sugiero una lectura profunda del algoritmo de Sincronización Diferencial, y tenga en cuenta los siguientes consejos:

Interfaz

Almacene el recurso y la sombra (utilizando, por ejemplo, url como clave) en el almacenamiento local para aplicaciones pequeñas o en alternativas más avanzadas (pouchdb, indexdb, ...). Con el recurso puede trabajar sin conexión y cuando se necesita sincronizar con el servidor use jsonpath para obtener diffs entre el recurso-shadow y para enviarlo al servidor la solicitud PATCH.

Backend

En back-end, tenga en cuenta el almacenamiento de las copias sombra en redis.

Los dos lados (Frontend / Backend) necesitan identificar el nodo cliente, para ello se puede usar x- syn-token en el encabezado HTTP (enviarlo en todas las solicitudes del cliente con interceptores angulares).

Otra sugerencia: Yjs aprovecha un algoritmo tipo OT para compartir una amplia gama de tipos de datos admitidos, y usted tiene la opción de almacenar los datos compartidos en IndexedDB (para que esté disponible para la edición sin conexión).