4 ms·

My main issue with putting state in the frontend is that you introduced sync points, which is where, like, 90% of the bugs happen. Take form input and validati

My main issue with putting state in the frontend is that you introduced sync points, which is where, like, 90% of the bugs happen. Take form input and validation. Great, let's write out the validation on the frontend. But that doesn't mean much. We need to sync it. Okay... So let's just write the validation, again, on the backend. Hope it's the same validation. It never is, so we just introduced a whole class of bugs around that. Or just take a look at routing. Okay, let's route on the frontend. But what about access control? Okay, let's do a little routing logic on the backend too. Oh and now we've run into the same problem. When you do rich frontend and backend, you always have a minimum of two application states. You have two apps. You cannot get rid of the backend state, it's non-negotiable. So you have to keep them in sync, or more accurately, try to keep them in sync.

em-bee 1y ago
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,
- em-bee 1y ago
  my keyboard swallows keys, to remove ambiguity, i meant to say "there is no additional state to be kept in the backend"
- array_key_first 1y ago
  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.
  - em-bee 1y ago
    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.

em-bee 1y ago

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,

em-bee 1y ago
my keyboard swallows keys, to remove ambiguity, i meant to say "there is no additional state to be kept in the backend"
array_key_first 1y ago
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.
- em-bee 1y ago
  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.