It's a good thing to include and we will with time but currently the thorough validations in the Service Worker is decent enough for our smaller mvp target. We the devs will just stay away from using such tools for now (at least on Production). On the server we currently do conflict detection & merging which includes some level of validation. From my notes (example using a dummy domain):
--Conflict Detection & Merging:--
Having the client-server communication be event-based it will simplify the conflict detection performed by the server as the data & context is more specific. Example:
Client A has received stream of five events (0 to 4) from server for a particular aggregate. The client-side Read Data generated from this event data gets marked with _version: 4 indicating the last event applied to it.
Client A loses Internet Connection.
Client B on a different machine creates a new event which will receive event number 5. He syncs this with server. Server event store now has six events for this particular stream/aggregate.
Client A creates a new event while offline and it receives event number 5 (because system sees that Read Data has _version: 4 meaning next should be 5).
Client A regains Internet Connection and uploads the new event to server.
Server sees that this new event is marked as number 5. It checks with the event-store for the particular stream/aggregate and it sees that it already contains six events (and an event with number 5). This means we have a potential conflict and that we need to dig deeper.
--When is there an actual conflict and when is it a false alarm:--
If event received is of ‘created’ type (always for event with number 0, i.e. ‘createdProject’) then there’s zero chance of conflict and we can just let it through without checking. Also if we receive event with number 2 and there only exists events from 0 to 1 on server then we might also consider not checking deeper for conflict and just let it pass through.
If we receive events with lower or equal number to what’s already in the event store however then we might have a conflict on our hands and need to check deeper. Let’s say server event #5 is of type ‘addedAttachmentToProject’ and event #5 received from client is ‘addedContactPersonsToProject’ then we can see from the domain logic that there would be no actual conflict and we just update event number for the received event to #6 and add it to the event store.
However if existing server event #5 is of type ‘editedScopeOfProject’ and newly received event #5 from (recently offline) client is also ‘editedScopeOfProject’ then we would have an actual conflict and we reject it.