¿Cuáles son los buenos marcos para la colaboración en tiempo real en una aplicación web?

Probablemente voy a entrar en más detalles sobre esto más adelante, pero en caso de que la gente sienta curiosidad, esto es lo que encontré. Agregué enlaces a artículos que no requieren una suscripción de ACM donde pude. Primero, aquí están los posibles algoritmos que puede usar:

1. Transformaciones operacionales. Este es un término para un conjunto de algoritmos diferentes que le permiten colaborar en tiempo real de manera genérica. Es lo que usan Google Wave, Etherpad y Subethaedit. Hay algunas formas de implementar este algoritmo:

a) Un enfoque totalmente descentralizado. Este algoritmo se describe en el primer documento real sobre colaboración en tiempo real aquí: http://www.itu.dk/stud/speciale/…. El algoritmo es una forma de hacer las cosas de igual a igual. El documento es en realidad muy legible (proviene de alguien que se deja intimidar fácilmente por la academia), pero que yo sepa, ningún sistema de colaboración en tiempo real implementa este algoritmo que no sea GROVE (aunque es demostrablemente correcto).

b) Modelo cliente-servidor. El algoritmo utilizado aquí es mucho más simple que el utilizado para la colaboración entre pares, pero requiere que tenga un servidor central con el que todos los clientes puedan hablar. Este algoritmo se describe aquí: ftp://ftp.lambda.moo.mud.org/pub…. Este documento también es muy legible, aunque se pasa por alto al explicar cómo se aplica realmente su modelo cuando tiene varios clientes. Explico un poco más sobre cómo funciona realmente en mi respuesta de desbordamiento de pila aquí: http://stackoverflow.com/questio…. Hasta donde yo sé, Etherpad usa este algoritmo (o algo similar) y es de código abierto: http://code.google.com/p/etherpad/.

c) enfoque de Google Wave. Wave en realidad usa el algoritmo de b), con un ligero cambio que les permite reducir la cantidad de estado que el servidor necesita mantener. El algoritmo Wave se describe aquí: http://www.waveprotocol.org/whit…. También tiene la ventaja de ser de código abierto. Si la gente no está segura de por qué sus cambios realmente les permiten reducir el uso de memoria en un servidor, esto es algo que podría ampliar más adelante, ya que no es lo más obvio.

d) Modificación del enfoque de Google Wave que no introduce ninguna latencia en la red. La idea es tratar cada par cliente-servidor en un modelo cliente-servidor como una red p2p, y aplicar el algoritmo de a). Hice una publicación al respecto aquí: http://groups.google.com/group/w…. Este es mi propio algoritmo, y no lo he probado, pero parece que debería funcionar. Sin embargo, es más complicado que el enfoque Wave y probablemente no recomendaría usarlo.

2. Sincronización diferencial. Este es el algoritmo utilizado por Google Mobwrite y se describe con más detalle aquí: http://neil.fraser.name/writing/…. La idea detrás de esto es básicamente tener “ciclos de sincronización” donde las diferencias se envían a un servidor, se fusionan allí, y luego los cambios en el servidor se envían de vuelta al cliente para fusionarse en la base del cliente. Es bastante simple de implementar para texto plano, aunque pensar en cómo hacerlo para datos estructurados, parecía menos fácil.

3. WOOT. Significa “sin transformaciones operativas” y puede leer más sobre esto aquí: http://www.inria.fr/rrrt/rr-5580…. En lugar de usar diffs, WOOT envía un contexto para cada acción y cada acción se aplica en función de este contexto. Nunca elimina el contexto, solo marca las cosas como ocultas, por lo que puede estar seguro de que existirá el contexto que utiliza al enviar una edición.

4. Ordenación total de los comandos. Este es el enfoque utilizado por la biblioteca Synchro que se basa en Google Wave: http://www.processwave.org/2010/…. Con este enfoque, cada cliente mantiene una serie de acciones que ha realizado y que el servidor aún no ha reconocido. Cuando el cliente obtiene una nueva acción, revierte todas sus acciones no reconocidas, aplica la nueva acción y luego vuelve a aplicar sus acciones no reconocidas. Para algunas subclases de aplicaciones, esto puede resultar más simple que un enfoque de transformación operativa completa.

Por cierto, si se encuentra con este documento mientras intenta encontrar transformaciones operativas (titulado “Un editor colaborativo en tiempo real actualizado de cliente-servidor”), no lo siga: http://jcit.org/files/csc562- Pro… . Ese algoritmo NO funciona en todos los casos. Puedo proporcionar detalles si hay personas interesadas.

Si no desea implementar estos algoritmos usted mismo, también hay una serie de plataformas que le permiten crear aplicaciones colaborativas en tiempo real sobre ellas (hasta donde yo sé, todas usan transformaciones operativas para manejar las cosas genéricamente). Éstas incluyen:

1) Google Wave
2) http://www.beweevee.com/
3) http://www.xtwip.com/
4) Probablemente otros, pero parecía que en su mayoría eran servicios flash / silverlight / .NET / pagos, por lo que no lo examiné demasiado.

¡Espero que ayude!

Las otras respuestas aquí son buenas descripciones de las tecnologías que permiten la colaboración en tiempo real, pero es probable que realmente no te importe la tecnología subyacente . Solo desea este tipo de funcionalidad en su aplicación, sin necesidad de un doctorado en algoritmos de control de divisas.

Se necesita mucho para construir este tipo de aplicaciones. La mayor parte de la conversación en este espacio gira en torno al estado mutable compartido, que sin duda es el aspecto más desafiante. Todas las otras respuestas a esta pregunta discuten esto y solo esto . Es cierto: es un problema DURO y necesitará usar una biblioteca existente para construir cualquier cosa en un plazo razonable.

Sin embargo, la mayoría de las soluciones se centran solo en este problema de sincronización de datos. Una experiencia de usuario colaborativa convincente requiere conciencia de lo que otras personas en el documento (o diagrama, proyecto, etc.) están haciendo. Muchos de los problemas con este tipo de aplicaciones se deben a que las personas cambian simultáneamente los mismos datos porque ni siquiera saben que alguien más está haciendo lo mismo. La mejor manera de manejar conflictos es evitarlos en primer lugar, por lo que casi todas las aplicaciones necesitarán alguna forma de rastrear el estado transitorio, como los punteros, cursores y selecciones de los usuarios. Por lo tanto, una solución robusta proporcionará funcionalidad de datos en tiempo real, así como características que faciliten a los usuarios colaborar eficazmente en estos datos.

Con eso fuera del camino, déjame responder tu pregunta. Estas son las bibliotecas actuales que proporcionan la funcionalidad de colaboración RT:

  1. sharedb es probablemente la biblioteca más utilizada en este espacio. Es de código abierto, tiene buenas integraciones con DerbyJS y Meteor, y es bastante rápido de configurar. Como la mayoría de las otras soluciones, solo maneja la pieza de sincronización de datos. No proporciona mucho por la forma de manejar el estado transitorio, como punteros del mouse, cursores y presencia del usuario.
  2. TogetherJS proporciona sincronización de la capa de vista en todos los navegadores. Comenzar es extremadamente rápido y no le importa cómo y cuándo se conservan sus datos. El chat está integrado. Puede ser una buena opción para muchas aplicaciones pequeñas, pero el soporte para algo tan básico como deshacer será imposible ya que no hay seguimiento de los cambios.
  3. La API de Google Realtime proporciona un buen conjunto de herramientas para permitir la colaboración en tiempo real con los archivos de Google Drive. Esto, por supuesto, requiere que su aplicación use Drive para persistencia. Soporta deshacer / rehacer local. Nuevamente, deberá traer su propio chat, presencia de usuario y cualquier seguimiento de estado transitorio.
  4. SwellRT es una plataforma de almacenamiento en tiempo real centrada en datos textuales. Es bastante nuevo y de código abierto.
  5. Flip es una biblioteca de modelo de datos extraída de Ohm Studio. Deshacer / rehacer admitido de fábrica, patentado.
  6. Firebase, RethinkDB, etc. son bases de datos esencialmente distribuidas con funcionalidad integrada para transmitir los cambios de datos en tiempo real. Sin embargo, un requisito crítico para las aplicaciones de RT es la capacidad de resolver actualizaciones de datos simultáneas, para lo cual estas soluciones no están diseñadas. Puede obtener una buena cantidad de comportamiento de la aplicación en tiempo real con estas herramientas, pero la edición colaborativa no es su fuerte.
  7. PubNub, Pusher y muchos otros proporcionan mensajes robustos en tiempo real, enfocados principalmente en la distribución de mensajes y actualizaciones a una gran cantidad de clientes. Si bien es útil para muchos casos de uso, estos realmente no ayudan con la edición en tiempo real. Dado que no proporcionan la pieza de resolución de conflictos fuera de la caja, generalmente no se ajustan a las aplicaciones de colaboración en tiempo real.
  8. Convergence es una plataforma alojada para el desarrollo de aplicaciones de colaboración en tiempo real. Piense en ello como Firebase creado desde cero para aplicaciones colaborativas. Existen API de alto nivel para admitir la mutación de datos y escuchar los cambios en cualquier nivel de granularidad, seguimiento de la actividad del usuario, chat y presencia, todo con una consistencia eventual garantizada para todos los usuarios asociados. Sin duda, esta es la forma más rápida de mojarse los pies creando una aplicación colaborativa en tiempo real, PERO puede no ser una buena opción para aquellos que necesitan un control total sobre sus datos. Propiedad.

En total divulgación, soy cofundador de Convergence Labs, y estamos creando Convergence para resolver el problema exacto que usted describe. Nosotros (el equipo fundador) tenemos más de una década de experiencia combinada en la construcción de este tipo de aplicaciones, y hemos aprendido que manejar el estado mutable compartido es solo el comienzo. Así que creamos Convergence, que es la única solución integral que maneja todos los diferentes aspectos de la construcción de aplicaciones de edición colaborativa.