Background
Full Stackabril de 2025

Coordly

Un espacio de trabajo unificado que consolida documentos colaborativos en tiempo real, tareas Kanban, chat de equipo y videoconferencia WebRTC en una sola arquitectura cohesiva.

Coordly — screenshot 1
01 — Why I Built It

Por Qué Construí Coordly

"La motivación para este proyecto surgió de la fricción constante de usar múltiples herramientas dispares para la colaboración en equipo. Un flujo de trabajo típico involucra Jira o Trello para tareas, Google Docs para escribir, Zoom o Google Meet para llamadas y Slack para chatear."

"Gestionar un proyecto en varias aplicaciones se sentía innecesariamente fragmentado. El objetivo principal de Coordly era explorar cómo construir un espacio de trabajo unificado donde un equipo pudiera manejar estas actividades de colaboración de forma nativa bajo un mismo techo."

De CollabHub a Coordly

El proyecto originalmente se llamaba CollabHub. Sin embargo, el nombre se cambió más tarde a Coordly porque CollabHub parecía demasiado genérico y ya estaba asociado con otros productos.

Se eligió Coordly porque es más corto, más moderno, fácil de comercializar y se alinea estrechamente con el objetivo central de la aplicación de la coordinación en equipo.

02 — The Workspace

El Espacio de Trabajo Unificado

Coordly está construido en torno al concepto de 'Collabs' — espacios de nombres de contenedores de espacio de trabajo.

Cuando los usuarios se unen a un Collab, obtienen acceso inmediato y sincronizado a un documento de texto enriquecido impulsado por Tiptap, un tablero de tareas Kanban de arrastrar y soltar, un canal de mensajería en tiempo real y una interfaz de videollamada persistente.

Esta arquitectura elimina el cambio de contexto, permitiendo a los equipos referenciar un documento, charlar sobre una tarea y hablar por video simultáneamente dentro de la misma pestaña del navegador.

03 — Architecture

System Architecture

Coordly Workspace (Client)
DocsYjs / Tiptap
ChatSocket.IO
VideoWebRTC / PeerJS
y-websocket
socket.io signaling
Peer signaling
documentServer.js (Node) Multiplexed Realtime Server
peerServer.js Peer Broker
MongoDBApp Data & Yjs Buffers

Because Yjs operates natively over raw WebSockets and the chat/signaling system operates over Socket.IO (which also uses WebSocket/HTTP upgrades), the backend node server needed to securely route traffic to the correct protocol handler over a single HTTP port.

To solve this, the server intercepts the HTTP `upgrade` event. It analyzes the incoming request path—routing requests prefixed with `/socket.io/` to the Socket.IO engine, while passing all other relevant upgrade requests to the raw `wss.handleUpgrade` handler for Yjs document synchronization.

04 — Real-Time Systems

Tres Sistemas en Tiempo Real, Un Espacio de Trabajo

Collaborative Documents (Yjs)

Uses Yjs CRDTs over raw WebSockets (`y-websocket`) to coordinate document state across concurrent editors.

Chat & Signaling (Socket.IO)

Employs Socket.IO for ephemeral, room-based message broadcasting, including typing indicators and emoji reactions.

Video Calling (WebRTC & PeerJS)

Uses PeerJS and WebRTC for peer-to-peer media streaming, keeping the media path outside the application's main realtime server.

05 — WebRTC Media

Intercambio en Caliente de Medios WebRTC

A significant UX challenge in building the video component was allowing users to toggle their camera or microphone without dropping and rebuilding the entire peer-to-peer call.

Rather than tearing down the WebRTC connection, Coordly uses `RTCPeerConnection.getSenders().find(s => ...)` combined with `sender.replaceTrack()`. `replaceTrack()` swaps the active media track without tearing down the existing peer connection. This keeps the network connection alive while instantly reflecting the new hardware state.

06 — Persistence

Estrategia de Persistencia

The application splits persistence based on data characteristics. Application metadata, user profiles, tasks, and chat history are structured via Mongoose and stored in standard MongoDB collections.

Conversely, the real-time document state is decoupled from the REST API. It is captured by `y-mongodb-provider`, which stores the binary Yjs update buffers into a specialized MongoDB collection directly from the Node WebSocket server.

07 — Security

Autenticación y Autorización

Coordly uses NextAuth for identity management, supporting OAuth flows (GitHub, Google) with a JWT session strategy.

Security is enforced server-side via `getServerSession` checks. API routes explicitly validate a user's `CollabParticipant` role before authorizing database operations, preventing unauthorized access to private workspaces.

08 — Engineering Challenges

Desafíos de Ingeniería

1. Multiplexación de Protocolos en Tiempo Real

Problem: Running Yjs (raw WebSockets) and Socket.IO concurrently on the same backend port.

Approach: Intercepting the Node HTTP `upgrade` event and dynamically routing the socket based on the request URL path.

Result: A single Node.js server can route the two realtime protocols to their appropriate handlers.

2. Coordinación de Sistemas

Problem: Ensuring video, chat, and document states remained consistent without overwhelming the client.

Approach: Isolating component lifecycles and utilizing React Context to prevent unnecessary top-level re-renders.

Result: An interface where users can keep the video call in a floating PiP window while working in Docs or Tasks.

3. Consistencia de REST y CRDT

Problem: Maintaining consistency between standard REST data (document titles/permissions) and CRDT document content.

Approach: Decoupling the storage mechanisms—using Mongoose for metadata and `y-mongodb-provider` for binary state.

Result: Keeps CRDT document state separate from conventional REST-managed metadata and permissions.

09 — Trade-offs

Compromisos y Limitaciones

  • El `documentServer.js` mantiene el estado de conexión en la memoria. El escalado horizontal requeriría un adaptador de infraestructura compartida (como Redis) para unir las instancias de Socket.IO y Yjs.
  • PeerJS depende de las configuraciones STUN/TURN predeterminadas, lo que puede dificultar la negociación de conexiones WebRTC a través de cortafuegos corporativos estrictos.
  • Actualmente no se ha implementado ninguna limitación de tasa API explícita en el backend de Node.
10 — What I Learned

Lo Que Aprendí

Este fue mi primer gran proyecto backend con gran carga en tiempo real. Me enseñó los fundamentos de la arquitectura backend, especialmente cómo y cuándo usar diferentes tecnologías de comunicación como WebSockets, WebRTC y API HTTP.

También aprendí las grandes diferencias entre el desarrollo local y las implementaciones de producción, el manejo de esquemas de bases de datos y la gestión segura de la autenticación de sesiones.

A mitad del desarrollo, mi computadora portátil se averió y perdí todo el código fuente no confirmado. Reconstruirlo desde cero hizo que el valor de Git, el control de versiones y los repositorios remotos fueran muy reales para mí.

Qué Construiría Diferente Hoy

"Si comenzara este proyecto hoy, priorizaría un plan de arquitectura mucho más estricto desde el primer día, estableciendo límites de sistema más claros entre los servidores en tiempo real."

"También diseñaría la plataforma con la integración de IA como un pilar fundamental, en lugar de una ocurrencia tardía, permitiendo funciones como la generación automatizada de tareas o resúmenes de reuniones."

11 — Tech Stack

Pila de Tecnología

TechnologyRole
Next.js 15Marco de trabajo frontend y rutas API
Yjs & TiptapCRDT para edición de texto colaborativa en tiempo real
Socket.IOChat, señalización y presencia
WebRTC & PeerJSTransmisión de medios de igual a igual
Node.jsServidores multiplexados de WebSocket y señalización
MongoDBBase de datos para metadatos de la aplicación y almacenamiento CRDT
NextAuthAutenticación y gestión de sesiones JWT
Framer MotionAnimaciones UI fluidas y PiP arrastrable