Frontend is the worst place to hardcode the errors ⚡
Hardcoding of error messages on the front end, although common, is an anti-pattern. The idea flow for error handling is simple - when the backend gets an error, it should log it and then return a humanized version to the frontend, and the frontend can surface the same to the user.
A few reasons why this is a good idea
- the error messages can follow the same tonality and conventions
- any changes to conventions will happen in a single place
- the error messages will be consistent across the web, android, and ios
- the backend can choose to hide sensitive details
- the backend can add steps for resolution (like GCP error messages)
More importantly, any changes in the error messages or steps of resolution do not require an app rollout simplifying the entire process while keeping the frontend lightweight and error messages consistent.
By following this practice, the frontend is primarily concerned with presentation and is not burdened with the intricacies of error handling promoting loose coupling and cleaner separation of concerns.
But, some errors are best handled by the frontend, like the ones that involve network connectivity and browser compatibility issues. The frontend has the best chance to detect them and craft a great UX around them.
This is why we see “your internet is unstable” during a Zoom call, or “you are disconnected” on YouTube when the internet goes off, or adaptive bitrate kicking changing your resolution during flaky internet.
⚡ I keep writing and sharing my practical experience and learnings every day, so if you resonate then follow along. I keep it no fluff.
youtube.com/c/ArpitBhayani