Storage Approaches
How and when a document is stored often depends on the level of document collaboration needed.High Collaboration
For real-time, multi-user collaboration (similar to Google Docs) using Yjs/CRDT, each client connects to a realtime collaboration service that merges all user updates.Complexity: Medium — Requires a server-side Yjs/CRDT service
- Every document edit (as a Yjs byte array) is automatically sent via WebSocket to the Yjs/CRDT service
- When all changes are merged, the service stores the new document
- Storage happens continuously on the backend
Low Collaboration
For scenarios where only one user edits at a time (like SharePoint), implement a locking mechanism where users check out documents before editing.Complexity: Low — Requires storing and querying document lock/unlock state
- When the active user makes an edit, debounced changes are sent to your server which stores the document
- Alternatively, when a user saves/checks in the document, it is sent to your server for storage
- Storage is triggered by user actions on the frontend
What to Store
In both low collaboration and high collaboration approaches, when the document arrives at your backend, we recommend:1
Create a unique version ID
Generate a unique identifier for the document version:
2
Store the document version
Save the full DOCX binary to your cloud storage:
3
Save version metadata
Store the document version ID and its storage path in your database for later retrieval.
Export Methods
The ways to export a document are covered in Import/Export.We recommend storing the full DOCX binary because it provides the highest fidelity version of the document. Other export options (such as JSON) are also available.
Best Practices
Unique Version IDs
Include timestamps or UUIDs to ensure uniqueness
Store Full DOCX
Preserves all formatting, comments, and tracked changes
Keep Version History
Store multiple versions for audit trails and recovery
Use Cloud Storage
S3, Google Cloud Storage, or Azure Blob Storage

