Backend Strategies
Replicache defines abstract push and pull endpoints that servers must implement to sync. There are a number of possible strategies to implement these endpoints with different tradeoffs.
The main difference between the strategies is how they calcuate the patch
required by the pull endpoint. Different approaches to calculating this patch require different state to be stored in the backend database, affect the push and pull implementations, and also some features Replicache can support.
Strategy | When to Use | Push Performance | Pull Performance | Implementation | Partial Sync | Dynamic Auth |
---|---|---|---|---|---|---|
ðĪŠ Reset | For very tiny or slowly-updating applications. | ððž Little overhead compared to standard web app | ððž Read and transmit entire client view on each pull | ððž Trivial | ððž Automatic | ððž Automatic |
ð Global Version | Simple apps with low concurrency and no need for partial sync or dynamic auth | ððž Limited to about 50/second | ððž Efficient to compute patch | ððž Trivial | ððž Possible but inefficient. | ðĪ·ðŧ Extra effort. |
ðļ Per-Space Version | Simple apps that can be partitioned easily along some boundary like organization or account | ððž Limited to about 50/second/space | ððž Efficient to compute patch | ððž Trivial | ððž Possible but inefficient. | ðĪ·ðŧ Extra effort. |
ðĢ Row Versioning | Apps that need greater concurrency, partial sync, or dynamic auth | ððž Little overhead compared to standard web app | ððž More overhead than standard web app but scales well | ðĪ·ðŧ Moderately difficult | ððž Automatic | ððž Automatic |