[singingboyo]

You're technically correct (the best kind!) but in practice one can largely ignore server state in some applications.

I've got a side project where the data is stored server side. In practice, that server side data might as well be a saved file on the clients hard drive.

Is it "all in" on client state? Not really. Do I ever need to worry much about synchronization? Also no. The synchronization is just "send it to the server when it changes, put an error bar up if that fails". Pretty simple.

It's a bit network heavy, but in this case there are other, heavier parts of the app. There are options if data size ever does become an issue - for now it's not.

Incidentally, I feel like this is where something like MongoDB really is a decent choice. The client would probably just preload the data anyway if it were normalized and in Postgres somewhere. API serves out JSON. Why not just... load the JSON out of the DB?

[em-bee]

that's pretty much how i build all my websites. not with mongodb but another reusable generic CRUD backend. it's not much more network heavy than a static or serverside rendered site and the server doesn't need to keep any state other than the data itself. any custom state that the client wants to store on the server is just saved as additional server data.