4 ms·
Backend is riskier. If you mess up the frontend, revert and redeploy. Easy. If you mess up the backend (data corruption, data removal, data leaking, etc.) you a
by tkiolp4 3y ago
Backend is riskier. If you mess up the frontend, revert and redeploy. Easy. If you mess up the backend (data corruption, data removal, data leaking, etc.) you are in hell.
- runarberg 3y agoClients also have datastores, localstorage, sessions, cookies, indexdb, service workers, etc. Messing up a service worker is particularly annoying, but messing up storing an authtoken can also leave your users in a broken state. On the backend you can (hopefully) revert from a backup, or conjure up a clever SQL query to patch things up. On the frontend however, well, you just have to wait for the user to call you to tell you it is broken, and then tell them—somehow—that they must delete the service worker. Oh yeah, and you also have to deal with shipping a feature which brakes everything for users on 5 year old versions of Safari.
- fiedzia 3y ago> If you mess up the backend (data corruption, data removal, data leaking, etc.) you are in hell. True, but also tooling is better. I have seen a data corruption in a database only once in my life (at least in production). Finding some issue with ui is closer to norm then exception.