The id can be used to look up a particular message in the replica which supports various business logic
When Alice adds a message optimistically to her replica, she can simulate almost everything in the final result except the id .
The id is an important part of the message identity as it assigns uniqueness to each message in the replica collection. The id is also an important part of the view creation logic as it is used as the key in the React render function that maps an array of messages to JSX.
Resolving conflict in the two different id versions should be avoided. We are venturing into dangerous territories when the clients are in the business of reasoning about the provenance of data in its local copy. This could introduce a leaky abstraction problem wherein the client needs to know the implementation details of the server (e.g., how an id is picked), which can cause the system to be fragile and error-prone.
There are two ways to avoid performing conflict resolution on the id . Choosing which approach to pursue depends on the constraints and non-functional requirements imposed on the project. In particular, this is a tradeoff between technical complexity on the back-end vs front-end.
Conflict Avoidance (server-side)
A server-generated id for message was a constraint for the offline-first chat app project. The chat app was originally built to not be usable while offline.