CoCube: Local First Tools

CoCube is built with local first prinicples in mind. This page documents how CoCube treats local and non-local data, and how it handles sync and collaboration features.

Why Local First

Most web software functions in the same way: store the users data on some private servers, and allow the user to request it each time they want to view it. Local first software instead gives users complete control of their data. What this means is that by default, every document you create is stored on your computer. CoCube only uses its own servers when you opt-in on a per-component basis to enable sync and/or collaboration. This allows you to create useful tools and systems in private, without worrying about your data.

How Components Are Stored

Components are hardly more complex than simple key-value pairs.

Component Document Updates

Updating a component updates that cell in the runtime, then modifies the associated docuemnt. Then, the document changes are synced back to the central server.

Ephemeral vs Persistent Cells

When components are included using references, the rutime represents their cells as Ephemeral cells. Modifying these cells does NOT update the associated document.

Local vs Non-Local Changes

When exactly do your changes update a document, and when do your changes sync?

How Collaboration and Sync Works

Your documents are not persisted until you enable collaborative or sync features.

Special Case: Text Cells and Cursors

When a component contains a cell that contains nothing more than some Text, CoCube can track cursor positions on the cell. This allows seamless collaborative real-time text editing.

Local Storage with Sqlite

Other reading.

Make sure to check out Local First Software to see other applications using these principles.See how Riffle approaches the problem: Riffle: Building data-centric apps with a reactive relational database.