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