7 ms·

Offline first isnt more prevalent because: 1. its hard 2. its a significant dev cost 3. there aren't a lot of resources to help you out if you aren't already

Offline first isnt more prevalent because: 1. its hard 2. its a significant dev cost 3. there aren't a lot of resources to help you out if you aren't already familiar with CRDTs and the like (and that assumes your backend also already supports them) I can't help with #1 and #2, but for #3 I found Jake Archibald to be the best source of information online. Here is a great high level presentation (he really is a gem of a presenter. I always drop what I'm doing to watch anything he puts out, offline-first or otherwise): https://www.youtube.com/watch?v=cmGr0RszHc8 https://www.youtube.com/watch?v=cmGr0RszHc8 Also, Trello put out a multipart blog series which gets into some nuts and bolts which are really valuable when designing your own app: https://tech.trello.com/sync-architecture/ https://tech.trello.com/sync-architecture/ EDIT: I just noticed Jake has a full course available. I'm not sure how good it is, or how indepth, but I'm sure its decent based on the author: https://jakearchibald.com/2014/offline-cookbook/ https://jakearchibald.com/2014/offline-cookbook/

lytefm 4y ago
> 1. its hard From my experience, building an offline-first app is much easier than a traditional client-server app. I maintain an authentication backend for PouchDB/CouchDB-based apps and have received this feedback multiple times: It only requires a little bit of frontend web dev knowledge to store and retrieve JSONs locally + sync them up, without having to worry about authentication, API design, network connection or caching. > 2. its a significant dev cost It allows to move much faster than a traditional setup where frontend devs might need to sit in meetings with backend devs in order to argue about some API design. But early mistakes in the data model are much harder to fix because with CouchDB, your data model is your API. Having built apps with Pouch/Couch for > 4 years now, I think the perfect middle ground is to only accept changes made by a user through an API (proper data validation, no conflicts,...) and to use Pouch/Couch in a read-only manner, replicating all necessary user data to the client.

lytefm 4y ago

> 1. its hard From my experience, building an offline-first app is much easier than a traditional client-server app. I maintain an authentication backend for PouchDB/CouchDB-based apps and have received this feedback multiple times: It only requires a little bit of frontend web dev knowledge to store and retrieve JSONs locally + sync them up, without having to worry about authentication, API design, network connection or caching. > 2. its a significant dev cost It allows to move much faster than a traditional setup where frontend devs might need to sit in meetings with backend devs in order to argue about some API design. But early mistakes in the data model are much harder to fix because with CouchDB, your data model is your API. Having built apps with Pouch/Couch for > 4 years now, I think the perfect middle ground is to only accept changes made by a user through an API (proper data validation, no conflicts,...) and to use Pouch/Couch in a read-only manner, replicating all necessary user data to the client.