Skip to main content

ðŸĪŠ 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:

  1. Create a new ReplicacheClientGroup if necessary.
  2. Verify the requesting user owns the specified ReplicacheClientGroup.

Then, for each mutation described in the PushRequest:

  1. Create a new ReplicacheClient if necessary.
  2. Validate the ReplicacheClient is part of the requested ReplicacheClientGroup.
  3. Validate the received mutation ID is the next expected mutation ID from this client.
  4. Run the applicable business logic to apply the mutation.
  5. 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:

  1. Verify that requesting user owns the requested ReplicacheClientGroup.
  2. 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.

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.