How to handle states sync in an «offline first» approach?

Questions / Help
, ,
1

Hello all,

The context is simple: When a user joins the main lobby channel of my app, it receives its state. Then, the user interacts over the front-end UI, where its state is mutated.

So I see two paths here:

Path #1: When a mutation occurs, send a request thru the socket (or over API), then wait for the server to process the mutation.

This is the old request-response mechanism and it may suit a lot of needs. But it has caveats: the front-end must be constantly connected over an internet connection. Plus, there might be a delay between the mutation occurs and its acknowledgment from the server.

Path #2: When a mutation occurs, simply mutate local state. Syncing is made in background with a presence mechanism. If a client goes offline for any reason, then its state gets synced next time it reconnects.

My question is: what is the best way to implement path 2?

I’ve looked at Phoenix.Tracker, which «use a heartbeat protocol and CRDT to replicate presence information across a cluster in an eventually consistent, conflict-free manner» and it looked promising. Trackers work with presence metadata. But I read in the Phoenix.Presence doc: « Presence metadata should be minimized and used to store small, ephemeral state, such as a user’s “online” or “away” status.».

So I am confused. Is Phoenix.Tracker the best way to implement this or there is a better way of doing it?

Thanks in advances!

JP

1 Like
2

Offline first is just a more fancy way to say distributed state. So all the solutions / tradeoffs and issues of the latter apply here. Phoenix Tracker for example uses CRDTs to distribute the presence of something/someone in a channel. The metadata is just a bag of data assigned to that presence, which is not merged in any way as far as I know. It’s simply replaced.

So you’d need to check if you problem can be solved using the particular solution, but there are many other ways for merging potentially conflicting state all with their own set of tradeoffs.

1 Like