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.
> 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.
Clients 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.
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.