Construir una pizarra colaborativa en tiempo real con Svelte y WebSockets
Cuando se piensa en herramientas colaborativas modernas, nombres como Miro o FigJam vienen inmediatamente a la mente. Detrás de su aparente fluidez se esconden desafíos técnicos formidables: sincronización de estados, gestión de conflictos y latencia casi nula. Pero, ¿debemos reinventar la rueda con protocolos exóticos o bases de datos en tiempo real? No necesariamente. Con Svelte y WebSockets bien dominados, es posible construir una pizarra colaborativa eficiente sin sacrificar la simplicidad.
Este artículo te guía paso a paso en la realización de una aplicación de este tipo, basándome en la experiencia de proyectos similares y en los comentarios de la comunidad. Abordaremos la arquitectura, la sincronización, la gestión de usuarios y las optimizaciones que marcan la diferencia.
La base: Svelte y WebSockets, un dúo ganador
Svelte se distingue por su reactividad nativa: las variables reactivas actualizan el DOM sin sobrecarga. Combinado con WebSockets, que permite una comunicación bidireccional persistente, obtenemos una base ideal para el tiempo real.
En nuestro caso, cada acción de dibujo (trazado, borrado, movimiento de elemento) se envía a través de WebSocket a un servidor Node.js, que la difunde a los demás clientes. El estado global se mantiene en el servidor, pero cada cliente posee una copia local para garantizar una respuesta instantánea.
Arquitectura: el servidor como director de orquesta
El servidor juega un papel central: recibe los eventos, los valida y los redistribuye. Para evitar conflictos, cada evento se marca con una marca de tiempo y se identifica con un ID único. En caso de concurrencia sobre una misma forma, prevalece el último evento recibido: un enfoque "last-write-wins" simple pero eficaz para una pizarra.
La gestión de sesiones es esencial: cada pizarra tiene un identificador único. Los clientes se conectan a una sala específica, y el servidor solo transmite los eventos a los miembros de esa sala. Esto limita la carga y garantiza la confidencialidad.
Gestión de estados: el equilibrio justo entre local y remoto
Un error clásico es sincronizar todo en tiempo real, incluidos los estados transitorios como el paso del cursor sobre una forma. Es mejor distinguir:
- Eventos permanentes: trazos, movimientos, modificaciones de propiedades – enviados al servidor y persistidos.
- Eventos fugaces: cursores de otros usuarios, selecciones temporales – difundidos localmente a través de WebSocket pero no persistidos.
Esta distinción reduce la carga del servidor y evita una base de datos llena de información innecesaria.
Experiencia de usuario: el cursor de los demás, ventana a lo colaborativo
Ver el cursor de un colaborador en tiempo real crea una sensación de presencia. Los datos de posición se envían a alta frecuencia (cada 50 ms) pero sin garantía de entrega. Para evitar la saturación, se utiliza un throttling del lado del cliente.
Atención: el desplazamiento o zoom de la pizarra debe tenerse en cuenta. Cada evento de ratón se convierte en coordenadas lógicas (relativas al canvas), no en píxeles de pantalla, para que todos los usuarios vean el cursor en el lugar correcto.
Gestión de conflictos: deshacer/rehacer en modo multijugador
Deshacer/rehacer es un dolor de cabeza en un entorno colaborativo. La solución adoptada: cada usuario tiene su propia pila de deshacer local, pero las acciones de deshacer se convierten en eventos "inversos" que se envían al servidor. Así, deshacer un trazo equivale a enviar un evento "eliminar este trazo" a todos. Este enfoque, aunque más complejo, evita incoherencias.
Para profundizar, Liveblocks ofrece un excelente análisis de las estrategias de deshacer/rehacer en multijugador, que inspiró nuestra implementación.
Rendimiento y escalabilidad
Para un uso moderado (menos de 100 usuarios simultáneos en una misma pizarra), un único servidor Node.js es suficiente. Más allá, hay que considerar una arquitectura distribuida con Redis para compartir el estado entre instancias. NATS, mencionado en proyectos similares, también puede servir como backbone de mensajería.
Del lado del cliente, se prefiere el canvas HTML5 al SVG por el rendimiento de renderizado. Las formas se redibujan en cada fotograma, pero solo las zonas modificadas se actualizan gracias a rectángulos sucios.
Despliegue y consideraciones prácticas
El servidor WebSocket puede desplegarse en una plataforma como Heroku o Fly.io. Atención a las conexiones largas: los timeouts de los balanceadores de carga deben configurarse para no cortar los WebSockets. El uso de SSL es indispensable para entornos de producción.
En cuanto al almacenamiento, una base de datos simple como SQLite o PostgreSQL puede guardar el estado final de la pizarra (lista de formas con sus propiedades). Para necesidades de tiempo real más avanzadas, Supabase Realtime ofrece una solución llave en mano.
Experiencia: lecciones aprendidas
Durante la construcción de un prototipo, se identificaron varios errores:
- No descuidar la compresión: los mensajes WebSocket pueden comprimirse con permessage-deflate para reducir el ancho de banda.
- Gestionar la reconexión: tras una pérdida de conexión, el cliente debe solicitar el estado completo de la pizarra para resincronizarse.
- Probar con usuarios reales: las pruebas unitarias no reemplazan sesiones reales con decenas de personas dibujando al mismo tiempo.
Conclusión
Construir una pizarra colaborativa con Svelte y WebSockets es un proyecto accesible y formativo. Respetando una arquitectura simple pero robusta, gestionando correctamente los estados y conflictos, se obtiene una aplicación fluida y agradable. Las herramientas modernas como Svelte simplifican la reactividad, mientras que WebSockets aseguran la comunicación en tiempo real.
¿Listo para lanzarte? Abre tu editor, instala algunas dependencias y comienza con un simple intercambio de coordenadas de ratón. El resto vendrá por iteración.
Para profundizar
- Medium - Building a Real-Time Collaborative Whiteboard Backend with NestJS and Socket.IO - Un artículo que detalla un enfoque similar con NestJS.
- Supabase Realtime Docs - Documentación sobre las capacidades en tiempo real de Supabase, útiles para almacenamiento y sincronización.
- Reddit - How to start learning WebSockets - Discusión con consejos prácticos para empezar.
- Reddit - Reactive, optimistic-by-default WebSocket library - Presentación de una biblioteca WebSocket reactiva para apps colaborativas.
- Hacker News - Matrix-CRDT: real-time collaborative apps using Matrix - Un enfoque alternativo basado en Matrix y CRDT.
- Hacker News - How to build undo/redo in a multiplayer environment by Liveblocks - Análisis de estrategias de deshacer/rehacer en entorno multijugador.
- Reddit - itty-sockets: dead-simple realtime messaging in Svelte - Una biblioteca ligera para tiempo real con Svelte.