you have to do the same on the server side and your database, if you have one. the API is just data too. you don't keep all your application state in you database, do you?
i don't know what kind of application you have in mind, but in mine the frontend state and the backend state are entirely different things. the only thing that needs to be kept in sync is the data itself. and that's easier than the whole frontend state which is a lot more complex. in most cases you treat the backend like a database itself. there is n additional state to be kept in the backend, than what goes into the database. at least with all the applications i ever built. i am sure there are other applications that are more complex, and i may change my mind when i get to work on one, but i believe most applications are CRUD, and complex UI state is only in the fronted, data state in the backend/database,
I keep as much state as I can in the database, yes. For example - foreign keys. I use constraints in the database to enforce application logic.
I could do this in the backend, yes. But that's needless complexity and it will blow up. Eventually, I'll write something to the database that's inconsistent and then I have to fix it. Because bugs happen.
hmm, i don't want to come across as argumentative, it is more curiosity, because i simply never wrote apps that way. i just don't see how application logic could affect the data itself. the data is independent, and of course there are constraints for data consistency, but it is completely separated from the application logic. application logic doesn't make it into the database at all, or if it does then at best i might store some application specific states in a separate area in the database. effectively a different database than the one that has actual data. i can't think of an example where that separation would not be possible.
i don't know what kind of application you have in mind, but in mine the frontend state and the backend state are entirely different things. the only thing that needs to be kept in sync is the data itself. and that's easier than the whole frontend state which is a lot more complex. in most cases you treat the backend like a database itself. there is n additional state to be kept in the backend, than what goes into the database. at least with all the applications i ever built. i am sure there are other applications that are more complex, and i may change my mind when i get to work on one, but i believe most applications are CRUD, and complex UI state is only in the fronted, data state in the backend/database,