<story><title>Downsides of Offline First</title><url>https://rxdb.info/downsides-of-offline-first.html</url></story><parent_chain><item><author>the_duke</author><text>I might be missing something, but I have trouble seeing how CRDTs can work for regular CRUD style applications.&lt;p&gt;Just the first example that pops into my head: edit A sets an invoice status to paid, edit b changes the invoice amount from 100 to 120. The merge is a paid invoice with an incorrect amount.&lt;p&gt;A workaround would be to record a separate PaidInvoice that wont be changed by the application logic.&lt;p&gt;But that&amp;#x27;s just a really trivial example that only involves scalar fields inside a single object,  and also relies on the application logic considering all ways that the CRDT might behave.&lt;p&gt;There are countless ways to end up with data that violates the constraints of the domain.&lt;p&gt;Is there any theoretical groundwork happening on how CRDTs can preserve domain semantics?</text></item><item><author>josephg</author><text>I’m a “true believer” in CRDTs, which I have some experience in. You can implement a useful CRDT for simple applications in under 100 lines if all you care about are standard database objects - like maps, sets and values. List CRDTs are where they get complicated, but most applications aren’t collaborative text editors.&lt;p&gt;The promise of CRDTs is that unlike most conflict resolution systems, you can layer over a crdt library and basically ignore all the implantation details. Applications should (can) mostly ignore how a CRDT works when building up the stack.&lt;p&gt;The biggest roadblock to their use is that they’re poorly understood. Well, that and implementation maturity. Automerge-rs merged a PR the other day which brought a 5 minute benchmark run down to 2 seconds. But by bit we’re getting there.</text></item></parent_chain><comment><author>TeMPOraL</author><text>I know nothing about CRDTs, but I feel the ultimate problem with your invoice example might be a representation issue.&lt;p&gt;&amp;gt; &lt;i&gt;edit A sets an invoice status to paid, edit b changes the invoice amount from 100 to 120. The merge is a paid invoice with an incorrect amount.&lt;/i&gt;&lt;p&gt;There is no such thing as &amp;quot;paid status&amp;quot; of an invoice. That&amp;#x27;s a simplification. If you unroll it, what you get is accounts that must balance. The invoice starts with &amp;quot;accounts payable&amp;quot;[0] set to 100$, and no payment covering it. Edit A adds a transaction from company account to AP to the value of $100. Edit B changes the liability in AP to $120. The result of a merge should be a transaction record for $100 and liability of $120, meaning a partially-paid invoice.&lt;p&gt;--&lt;p&gt;[0] - Or whatever it is called, I keep getting confused by this terminology, as it&amp;#x27;s not something regular people use in my part of the world.</text></comment>
<story><title>Downsides of Offline First</title><url>https://rxdb.info/downsides-of-offline-first.html</url></story><parent_chain><item><author>the_duke</author><text>I might be missing something, but I have trouble seeing how CRDTs can work for regular CRUD style applications.&lt;p&gt;Just the first example that pops into my head: edit A sets an invoice status to paid, edit b changes the invoice amount from 100 to 120. The merge is a paid invoice with an incorrect amount.&lt;p&gt;A workaround would be to record a separate PaidInvoice that wont be changed by the application logic.&lt;p&gt;But that&amp;#x27;s just a really trivial example that only involves scalar fields inside a single object,  and also relies on the application logic considering all ways that the CRDT might behave.&lt;p&gt;There are countless ways to end up with data that violates the constraints of the domain.&lt;p&gt;Is there any theoretical groundwork happening on how CRDTs can preserve domain semantics?</text></item><item><author>josephg</author><text>I’m a “true believer” in CRDTs, which I have some experience in. You can implement a useful CRDT for simple applications in under 100 lines if all you care about are standard database objects - like maps, sets and values. List CRDTs are where they get complicated, but most applications aren’t collaborative text editors.&lt;p&gt;The promise of CRDTs is that unlike most conflict resolution systems, you can layer over a crdt library and basically ignore all the implantation details. Applications should (can) mostly ignore how a CRDT works when building up the stack.&lt;p&gt;The biggest roadblock to their use is that they’re poorly understood. Well, that and implementation maturity. Automerge-rs merged a PR the other day which brought a 5 minute benchmark run down to 2 seconds. But by bit we’re getting there.</text></item></parent_chain><comment><author>ollysb</author><text>Your general point withstanding, in this case wouldn&amp;#x27;t the merge be a partially paid invoice?</text></comment>