Design question: single or multiple Replicache instances?

[tslocke]

In a collaborative drawing app like Replidraw, suppose I want to also keep in sync with other users creating/deleting boards.

I could have a single Replicache instance for each board (like the Reflect example) and another Replicache representing the "world", with mutations like 'createBoard', 'deleteBoard'.

If I'm not using Reflect and I have a fully transactional database, there's no particular reason these need to be separate Replicaches. It could all be one, with the various drawing mutations, plus createBoard, deleteBoard etc. all in there. The cookie could have a worldVersion and (assuming I only need to keep one board in sync at a time) a boardVersion.

My hunch is the separate Replicache style is more modular and so might be a bit simpler, but I can't think of any strongly persuasive pros and cons for either. Any advice on which way to go?

Thanks.

[aboodman]

Good questions. The tradeoffs as I see them:

• There is no consistency guarantees across Replicache caches (I'm going to use the word "cache" as opposed to "instance" to distinguish from a running instance of the Replicache class). So it's possible your "world" cache sees that a world is present, but that world is not present on device. Or if there is any metadadta like the name of a board in the world cache, it can be inconsistent with data in the board cache.
• It is easier to incrementally expand the sync window when Replicache caches are partitioned because you can just do it per-board. You don't need to do any complex cookie logic.

Generally I think it's better to partition on boundaries that your data model naturally fits. Like for an issue tracker I'd partition by repo.