This is old and out-dated. Please see https://doc.replicache.dev/strategies/overview instead.

🌁 Overview

This is an alternative strategy for computing differences for Replicache pulls.

It has a few big advantages over The Global Version Strategy (and related per-space version)

• The client view can be computed dynamically — it can be any arbitrary query over the database, including filters, joins, windows, auth, etc. For example the pull can return “all active threads”. This pull query can even change per-user. If the user checks something in the UI, it can change to “all active threads, or first 20 inactive threads ordered by modified-date”.
• It does not require a global lock or the concept of spaces.
• It does not require a soft deletes (the deleted column). Entities can be fully deleted.

The disadvantage is that it pays for this flexibility in read cost: pulls become more expensive because they require a few queries, they aren’t a simple index scan. However, database reads are often easier to scale than writes.

👩🏻‍🏫 How it Works

Client View Records

A Client View Record (CVR) is a map of ID/version pairs. It captures the minimum information required about what was sent to a client in a previous pull. Encoded as JSON, it might look like:

// key/version pairs
{
	"thread/3aasd39sa": 34,
	"comment/xskdjai": 18,
	"thread/33ska0a": 7,
	...
}

One CVR is generated for each pull response and stored in some ephemeral storage. The storage doesn’t need to be durable — if the CVR is lost, the server can just send a full sync. And the storage doesn’t need to be transactional with the database. Redis is perfect.

The CVRs are stored keyed under some unique ID. It can be a GUID, or a hash of the serialized CVR.

Database Schema

The minimum requirement is just that each entity has a version column.

There is no need for soft deletes (deleted column) or spaces. Though they don’t hurt anything either.

Push

• Process the push as normal
• Whenever any entity is updated, transactionally bump its version column. Note this is different than the way this column works in the Global Version strategy — each entity’s version is bumped independently on write, they aren’t all sharing one global or per-space version.