A lot of cloud-based, client-server applications really should be client applications with some kind of sync solution.
I don’t need my shopping list to be reachable at any time from anywhere in the world. I need it to be on a handful of phones and maybe a laptop/desktop, and for changes on one device to show up on the others. That can be done with a web-based application, or a mobile app with its own backend. It can send updates halfway across the country to a dedicated central server so they can come back and reach the family member who’s at the store right now…
…but it can also be done by syncing changes peer-to-peer, or via a cloud-based relay, or building on a more general sync service like Dropbox or Nextcloud.
The web and cloud services have made the client-server model really easy to build for. As long as you know the client is always going to have a good network connection.
(Flashback to grocery shopping before they installed a new cell tower near the supermarket and we couldn’t even text each other “hey, I just remembered we need ___!” unless the one shopping was at the front of the store where the signal was just strong enough that an SMS message might show up. Obviously this would delay syncing too, but it’s another reason to keep a copy of the current data locally on the device.)
A related example where client-server makes more sense: actual shopping (whether arranging store pickup or buying something to be shipped). You need to know what’s available, what’s in stock, what the prices are…and so do all the store’s other customers.
The model for how people use it is a star: one central point (the store) and a bunch of rays connecting to it (the customers) and not to each other – so it matches a client-server structure.
Compared to the shopping list, where it might be built as a star, with the central server running it and lots of people connecting to it, but the actual use model is a small mesh: A handful of people and their devices sharing something among themselves.
