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 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