SveltyCMS utilizes Yjs CRDTs and a lightweight WebSocket sync server (ws + y-protocols) to provide a seamless, conflict-free collaborative editing experience — no Hocuspocus dependency needed.

🚀 The Single Source of Truth (SSoT) Model

Unlike traditional CMS editors that rely on periodic auto-saves, SveltyCMS treats the Y.Doc as the active source of truth during an editing session.

📈 Implementation Details

Phase 2: Full CRDT Concurrent Editing (Active)

1. Yjs Integration: Leveraging yjs for the core CRDT logic and y-svelte for native Rune bindings.
2. Synchronization:
   • Primary: WebSocket via lightweight ws + y-protocols server at /ws running natively on Node’s HTTP port.
   • Fallback: REST HTTP endpoint at POST /api/collaboration/yjs for environments with restrictive proxies. Clients POST base64-encoded Yjs updates; the server publishes them via pubSub to the yjsService for server-side doc application.
   • Deployment: Highly stable production setup running on the standard @sveltejs/adapter-node which automatically upgrades /ws connections for Yjs collaboration.
3. Presence & Cursors:
   • Real-time remote cursor tracking with user-specific colors.
   • “Active Editors” avatar stack in the header.
   • Field-level focus highlights to prevent overlapping edits.
4. RichText: Native Yjs integration for the TipTap/ProseMirror based RichText widget.

🔬 What Makes SveltyCMS’s Implementation So Special?

The key is its architectural choice. Instead of building real-time features on top of a traditional database, SveltyCMS has integrated a CRDT engine directly into its core editing experience. This enables granular, conflict-free synchronization typically found only in high-end tools like Google Docs or Figma.

1. CRDT Engine: The Gold Standard for Real-Time Sync

Traditional CMSs prevent “lost updates” by locking fields (e.g., Directus) or relying on a central server to resolve conflicts. This can feel clunky and interrupt the creative flow.

SveltyCMS uses Yjs, a high-performance Conflict-free Replicated Data Type (CRDT) implementation. CRDTs allow multiple users to edit the same document simultaneously without a central server. Each user’s changes are merged mathematically, ensuring consistency without locking or data loss.

The Yjs framework treats the shared document as the Single Source of Truth (SSoT) during an editing session, enabling true real-time collaboration.

2. Lightweight Yjs Sync Server: Zero External Dependencies

SveltyCMS ships with a built-in Yjs WebSocket sync server (src/services/collaboration/yjs-sync-server.ts) that uses only ws + y-protocols — no Hocuspocus or external sync engine required. The server handles:

• Document synchronization: Full Yjs sync protocol (SyncStep1/SyncStep2/Update)
• Awareness: Real-time cursor presence and user state
• Multi-document: Documents keyed by tenantId:docId for tenant isolation
• Graceful shutdown: Cleans up all Y.Doc instances on server stop

3. Character-Level Sync & Remote Cursors

Because of the CRDT foundation, SveltyCMS provides a seamless, collaborative editing experience within its RichText widget. Editors see changes character-by-character as they are typed and can view other users’ cursors in real-time. This level of fidelity is a hallmark of the SveltyCMS experience, setting it apart from standard CMS implementations.

🛠️ Technical Components

⚙️ Configuration

Collaborative editing is built-in but can be toggled per collection:

• Enable Collaborative: Full CRDT-based multi-user editing.
• Strict Locking: Classic field-level locking (one editor at a time).
• Disabled: Standard save/overwrite behavior.

🚀 Performance & Scalability

SveltyCMS real-time collaboration is built on standard Node.js WebSockets (ws) running natively on SvelteKit’s HTTP port. Benchmarked under production load, the engine yields sub-millisecond propagation latency and high update velocity:

Benchmark Metrics (Single CPU Thread)

Scalability & Capacity Planning

Because standard WebSockets in Node.js bypass native compiler requirements, they offer extremely predictable resource profiles:

• Idle Connections (Memory-Bound): Standard socket allocation uses ~15KB to 30KB of RAM per connection.
  • 512MB RAM Container/VPS: Supports ~15,000 parallel idle clients.
  • 2GB RAM Container/VPS: Supports ~60,000+ parallel idle clients.
• Active Editors (CPU-Bound): An active user editing a document typically generates 1 to 2 sync updates per second. At 3,000 updates/sec throughput capacity, SveltyCMS supports ~1,500 to 2,000 concurrent active editors typing simultaneously per CPU core.
• Active Chat Users: In chat or low-frequency setups (where users send a message every 10 seconds), the engine handles 30,000+ active concurrent users without delay.

Related

• Architecture Overview
• Security Overview
• State Management