3 ms·

I had no idea Legend Keeper used CRDTs. That's awesome! What were some of the challenges?

braden-lk 4y ago
To start with the good, building features in your app becomes super easy because your network layer is completely agnostic. Rather than making API endpoints for every new feature, you're implementing everything in the language of shared types like arrays and maps. The changes to those structures are simply merged with the server/peers and you don't worry about manually syncing stuff anymore. Everything you build now works offline by default, and collaboratively if you so choose. Collaboration is where things get a little spicy. You're now dealing with multi-master replication. These challenges are exacerbated with multi-user use cases (though even a single-user experience is still multiplayer: one person using multiple tabs or devices is essentially multiple users in the eyes of most CRDT-based app architectures. You could also consider the server another peer.) IMO, biggest challenge areas are data migrations, version management, data validation, and authorization. Sure you can migrate things on the server (if you're not building a P2P app), but you have to remember the server is now just a more authoritative peer; you can't guarantee your user will ever even talk to the server again. If you don't have defensive data validation and stellar error handling, one peer can poison the others with bad data. It doesn't need to be a bad actor: you could simply add a bug to your code without realizing it, push it to prod, and now you've got viral data corruption. On the bright side, because your business logic is all in the client, unit and integration tests become super powerful. There's no need to mock a server and risk deviation from reality: the client is authoritative, therefore its tests are authoritative. In my eyes, most of the challenges come from multiplayer. If you scope down your local-first app to a single-user experience + a server for backup purposes, I think things are pretty straightfoward. You'll still have to deal with version management and data migrations, but traditional desktop and mobile apps already have a rich history of best practices for this which can be emulated.
- infogulch 4y ago
  For data migrations / model versioning, have you seen Project Cambria [0], posted in 2020 [1]? (Also an inkandswitch.com project.) [0]: https://www.inkandswitch.com/cambria.html https://www.inkandswitch.com/cambria.html [1]: https://news.ycombinator.com/item?id=24699615 https://news.ycombinator.com/item?id=24699615

To start with the good, building features in your app becomes super easy because your network layer is completely agnostic. Rather than making API endpoints for every new feature, you're implementing everything in the language of shared types like arrays and maps. The changes to those structures are simply merged with the server/peers and you don't worry about manually syncing stuff anymore. Everything you build now works offline by default, and collaboratively if you so choose. Collaboration is where things get a little spicy. You're now dealing with multi-master replication. These challenges are exacerbated with multi-user use cases (though even a single-user experience is still multiplayer: one person using multiple tabs or devices is essentially multiple users in the eyes of most CRDT-based app architectures. You could also consider the server another peer.) IMO, biggest challenge areas are data migrations, version management, data validation, and authorization. Sure you can migrate things on the server (if you're not building a P2P app), but you have to remember the server is now just a more authoritative peer; you can't guarantee your user will ever even talk to the server again. If you don't have defensive data validation and stellar error handling, one peer can poison the others with bad data. It doesn't need to be a bad actor: you could simply add a bug to your code without realizing it, push it to prod, and now you've got viral data corruption. On the bright side, because your business logic is all in the client, unit and integration tests become super powerful. There's no need to mock a server and risk deviation from reality: the client is authoritative, therefore its tests are authoritative. In my eyes, most of the challenges come from multiplayer. If you scope down your local-first app to a single-user experience + a server for backup purposes, I think things are pretty straightfoward. You'll still have to deal with version management and data migrations, but traditional desktop and mobile apps already have a rich history of best practices for this which can be emulated.

infogulch 4y ago
For data migrations / model versioning, have you seen Project Cambria [0], posted in 2020 [1]? (Also an inkandswitch.com project.) [0]: https://www.inkandswitch.com/cambria.html https://www.inkandswitch.com/cambria.html [1]: https://news.ycombinator.com/item?id=24699615 https://news.ycombinator.com/item?id=24699615