3 ms·

Cache stays simple even for large applications. It never gets "sufficiently complex".

• xeromal 4y ago
  Theoretically, but not practically.
• ekidd 4y ago
  As the joke goes, there are two hard problems in software: 1. Naming things. 2. Cache invalidation. 3. Off-by-one errors. Caches are tricky beasts. First, you need to update them when the server-side state changes (for example, two people editing a single Google doc). Second, writing state changes to the server and waiting for confirmation is too slow for many kinds of interactions. In these cases, it's typical to optimistically write local changes to a local store, and then try to sync those changes with server asynchronously. But if synchronization fails, then the client needs to report that. And finally, there's the problem of partially loaded state, where the rest is loaded asynchronously on demand. That should be simple, but without some kind of framework, it also tends to have lots of subtle state-machine and null-reference bugs. So, no, cache does not always stay simple in large applications. (Unless the app is read only, and you're OK showing stale data.)
  • petilon 4y ago
    If you are building Google doc editor by all means, design a complex state management system, it is worth it. But then don't bring that complexity into typical business applications.
  • wruza 4y ago
    It’s all true, but you missed the part where react and/or redux are talking to the server to manage the cache. Because if they aren’t, it’s unclear why tf they are holding the mic.