3 ms·

A lot of the times the part of the backend that renders pages and handles user input can be assumed to be part of the frontend, I'm not talking about those. I m

by mojuba 5y ago

A lot of the times the part of the backend that renders pages and handles user input can be assumed to be part of the frontend, I'm not talking about those. I meant backend as an API. I honestly think you've never built a decent sized, non-trivial mobile app for example, and you probably have no idea how tedious and difficult it is to produce something that will be pleasant for the users to deal with.

majormajor 5y ago
I mean, if you say "parts of the backend are actually the frontend"[0] and "parts of the backend area actually the infra" and say "backend" is just a CRUD api that talks to a database: sure, that can be easy. But I've rarely seen backend jobs that don't require touching the 90% of the iceberg that's underwater... So it's a stupid definition. I haven't built a large mobile app, but I'm not claiming frontend dev is easy. You're claiming backend dev is easy but your argument so far reduces to "it's easy because the hard parts actually aren't part of it" which is tautological and pointless. You're not even just claiming it's easy, you're claiming it can be built 100% correct and bug free. What's the most complicated backend system you've built? What database, what user scale, what traffic scale, what technologies, what servers, etc? [0] the part of the backend that renders pages, if one exists, and the part that validates user input should be VERY VERY different components, anyway...
- mojuba 5y ago
  Hundreds of thousands of daily active users, I built both the backend and the mobile app. I think I'm familiar with common problems on both sides. Trust me, dealing with UI platforms is orders of magnitude more pain in the arse if you set the quality standards to the highest. Even the codebases were approx. 1 to 20-25.
  - valenterry 5y ago
    A big difference still stays: a frontend (and that includes SPAs, mobile apps and desktop applications) is essentially restarted all the time. If I screw something up in the frontend, then in most cases, I can fix it and people use the new version / reload the page and that's it. In backend, if I screw up, in most cases I now have a data problem and an ongoing problem that might only be fixable through an operational update. I might even have lost/overwritten data that is not recoverable or only through backups. Sure, this can happen on the frontend too (e.g. sending a wrong update command to the backend API or when storing some data/configuration directly in the browser) but from my experience it is much much more likely to happened in the backend and if it does, it is more severe. This doesn't make things more difficult on the technical side per se, but it slows things down a lot. I can't count how often I wished to be able to just truncate all user data and start with a fresh plate, instead of with a long, messed up user data history that contains quirks, fixes/workarounds in the data and that I have to stay compatible with and not forget.

by mojuba 5y ago

majormajor 5y ago

I mean, if you say "parts of the backend are actually the frontend"[0] and "parts of the backend area actually the infra" and say "backend" is just a CRUD api that talks to a database: sure, that can be easy. But I've rarely seen backend jobs that don't require touching the 90% of the iceberg that's underwater... So it's a stupid definition. I haven't built a large mobile app, but I'm not claiming frontend dev is easy. You're claiming backend dev is easy but your argument so far reduces to "it's easy because the hard parts actually aren't part of it" which is tautological and pointless. You're not even just claiming it's easy, you're claiming it can be built 100% correct and bug free. What's the most complicated backend system you've built? What database, what user scale, what traffic scale, what technologies, what servers, etc? [0] the part of the backend that renders pages, if one exists, and the part that validates user input should be VERY VERY different components, anyway...

mojuba 5y ago
Hundreds of thousands of daily active users, I built both the backend and the mobile app. I think I'm familiar with common problems on both sides. Trust me, dealing with UI platforms is orders of magnitude more pain in the arse if you set the quality standards to the highest. Even the codebases were approx. 1 to 20-25.
- valenterry 5y ago
  A big difference still stays: a frontend (and that includes SPAs, mobile apps and desktop applications) is essentially restarted all the time. If I screw something up in the frontend, then in most cases, I can fix it and people use the new version / reload the page and that's it. In backend, if I screw up, in most cases I now have a data problem and an ongoing problem that might only be fixable through an operational update. I might even have lost/overwritten data that is not recoverable or only through backups. Sure, this can happen on the frontend too (e.g. sending a wrong update command to the backend API or when storing some data/configuration directly in the browser) but from my experience it is much much more likely to happened in the backend and if it does, it is more severe. This doesn't make things more difficult on the technical side per se, but it slows things down a lot. I can't count how often I wished to be able to just truncate all user data and start with a fresh plate, instead of with a long, messed up user data history that contains quirks, fixes/workarounds in the data and that I have to stay compatible with and not forget.