docs/adr/ADR-0001-20250106-use-yjs-for-docs-editing.md
We will use Yjs a CRDT-based library for the collaborative editing of the documents.
Accepted
We need to implement a collaborative editing feature for the documents that supports real-time collaboration, offline capabilities, and seamless integration with our Django backend.
A robust toolkit for building rich-text editors with collaboration capabilities.
| Pros | Cons |
|---|---|
| Mature ecosystem | Complex integration with Django |
| Rich text editing features | Steeper learning curve |
| Used by major companies | More complex to implement offline support |
| Large community |
Real-time database backend based on Operational Transformation.
| Pros | Cons |
|---|---|
| Battle-tested in production | Complex setup required |
| Strong consistency model | Requires specific backend architecture |
| Good documentation | Less flexible with different backends |
| Higher latency compared to CRDTs |
Complete enterprise solution for real-time collaboration.
| Pros | Cons |
|---|---|
| Full-featured solution | Commercial licensing |
| Built-in presence features | Less community support |
| Enterprise support | More expensive |
| Good offline support | Overkill for basic needs |
A CRDT-based library specifically designed for real-time collaboration.
| Category | Pros | Cons |
|---|---|---|
| Technical Implementation | • Native real-time collaboration | |
| • No central conflict resolution needed | ||
| • Works well with Django backend | ||
| • Automatic state synchronization | • Learning curve for CRDT concepts | |
| • More complex initial setup | ||
| • Additional metadata overhead | ||
| User Experience | • Instant local updates | |
| • Works offline by default | ||
| • Low latency | ||
| • Smooth concurrent editing | • Eventual consistency might cause brief inconsistencies | |
| • UI must handle temporary conflicts | ||
| Performance | • Excellent scaling with multiple users | |
| • Reduced server load | ||
| • Efficient network usage | ||
| • Good memory optimization (especially Yjs) | • Slightly higher memory usage | |
| • Initial state sync can be larger | ||
| Development | • No need to build conflict resolution | |
| • Simple integration with text editors | ||
| • Future-proof architecture | • Team needs to learn new concepts | |
| • Fewer ready-made solutions | ||
| • May need to build some features from scratch | ||
| Maintenance | • Less server infrastructure | |
| • Simpler deployment | ||
| • Fewer points of failure | • Debugging can be more complex | |
| • State management requires careful handling | ||
| Business Impact | • Better offline support for users | |
| • Scales well as user base grows | ||
| • No licensing costs (with Yjs) | • Initial development time might be longer | |
| • Team training required |
Comparison Table:
| Feature | Yjs | Automerge | Legion | Diamond Types |
|---|---|---|---|---|
| Text Editing | ✅ Excellent | ✅ Good | ⚠️ Basic | ✅ Excellent |
| Structured Data | ✅ | ✅ | ✅ | ⚠️ |
| Memory Efficiency | ✅ High | ⚠️ Medium | ✅ Very High | ✅ High |
| Network Efficiency | ✅ | ⚠️ | ✅ | ✅ |
| Maturity | ✅ | ✅ | ⚠️ | ⚠️ |
| Community Size | ✅ Large | ✅ Large | ⚠️ Small | ⚠️ Small |
| Documentation | ✅ | ✅ | ⚠️ | ⚠️ |
| Backend Options | ✅ Many | ✅ Many | ⚠️ Limited | ⚠️ Limited |
Key Differences:
Implementation Approach:
Performance Characteristics:
Ecosystem Integration:
This analysis reinforces our choice of Yjs for the CRDT-based option as it provides:
After evaluating the alternatives, we choose Yjs for the following reasons:
| Feature | Yjs (CRDT) | ProseMirror | ShareDB | Convergence |
|---|---|---|---|---|
| Real-time Collaboration | ✅ | ✅ | ✅ | ✅ |
| Offline Support | ✅ | ⚠️ | ⚠️ | ✅ |
| Django Integration | Easy | Complex | Complex | Moderate |
| Learning Curve | Medium | High | High | Medium |
| Cost | Free | Free | Free | Paid |
| Community Size | Growing | Large | Medium | Small |