ðĪŠ The Reset Strategy
The Reset Strategy is the easiest possible strategy: it sends the entire client view on every pull response, so no patch calculation is necessary at all.
Sending the entire client view on each pull this way is very inefficient, so this approach is not usually recommended. That said, we do have customers that use this strategy in production, and it works if your data changes infrequently or is very small.
Schemaâ
In addition to your own normal domain data, your backend database will need to store two additional entities to support Replicache:
// A group of related ReplicacheClients. Typically there is one per browser
// profile.
type ReplicacheClientGroup = {
// Globally unique ID, generated by Replicache.
id: string;
// Optional, but required if the application is authenticated. The userID
// that created this ReplicacheClientGroup.
userID: any;
};
// An instance of the Replicache JS class that has ever synced with the server.
type ReplicacheClient = {
// Globally unique ID, generated by Replicache.
id: string;
// The ClientGroup this client is part of.
clientGroupID: string;
// Last mutation the server has processed from this client.
lastMutationID: number;
};
Pushâ
Replicache sends a PushRequest
to the push endpoint. The endpoint should:
- Create a new
ReplicacheClientGroup
if necessary. - Verify the requesting user owns the specified
ReplicacheClientGroup
.
Then, for each mutation described in the PushRequest
:
- Create a new
ReplicacheClient
if necessary. - Validate the
ReplicacheClient
is part of the requestedReplicacheClientGroup
. - Validate the received mutation ID is the next expected mutation ID from this client.
- Run the applicable business logic to apply the mutation.
- Update the
lastMutationID
of the client to store that the mutation was processed.
It is important that each mutation is processed within a serializable transaction, so that the lastMutationID
is updated atomically with the changes made by the mutation.
Pullâ
Replicache sends a PullRequest
to the pull endpoint. The endpoint should:
- Verify that requesting user owns the requested
ReplicacheClientGroup
. - Return a
PullResponse
with:- Some monotonically increasing
cookie
. - The
lastMutatationID
for every client in the client group. - A patch which clears the client view and replaces it with the entire current client view.
- Some monotonically increasing
Exampleâ
We do not currently have an example of this strategy.
Variationsâ
Read Authorizationâ
Because of the fact that this returns a reset patch, read authorizaton works naturally. Just update the query used to build the patch in the pull response to obey whatever auth rules you like.
Early Exitâ
There is no need to process every mutation submitted to the push endpoint. You can exit early as long as lastMutationID
is set to whatever the last processed mutation was. This can ocassionally be useful if clients can accumulate large amounts of mutations while offline and you want to keep the runtime of the push handler under some limit.
Batchingâ
You don't need to process each mutation in its own transaction. The entire push can be run inside one transaction, or you can do smaller batches.