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.
We 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.
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-repo...