4 ms·
I'd really like to see more elaboration of different architectures used for offline. Having used Apollo's GraphQL recently, it definitely has a fairly robust t
by rektide 4y ago
I'd really like to see more elaboration of different architectures used for offline.
Having used Apollo's GraphQL recently, it definitely has a fairly robust toolkit for handling the cached data; it's a good mini-database-like thing. It feels more than a little like having a Spring repository[1], but in the front end.
My hope is, as much as address user needs, we also as a positive side-effect get a nice well defined front-end architecture. The question of how programmers represent & handle data is fascinating, and offline-first is a more general capability we should have some story for when architecting these client-server resourceful systems.
[1] https://www.digitalocean.com/community/tutorials/spring-repository-annotation https://www.digitalocean.com/community/tutorials/spring-repo...
- dragonshed 4y agoThe only framework alternatives I’m aware of are PouchDB and BreezeJS. Most everything else I’ve seen seems to tack on offline support.
- JamesSwift 4y agoThere is also Realm
- JamesSwift 4y agoWe need to differentiate between storage and sync is the problem. Sure, you might have something that supports the storage part, but sync is a domain/app specific problem. When you do offline first, you need to look at every endpoint and piece of data and make a decision about how it should be fetched/refreshed (and this is just considering the read-only usecase. read-write is a much harder problem). There are good resources online that outline the different fetch strategies (e.g. cache-first, cache-then-network, network-only) but it doesn't prevent the developer from needing to go through and make the decisions around each of those strategies and to implement them.