6 ms·

Someone else has already mentioned in this thread that backends only ever interact with other programs, not humans. This fact alone makes it easier to design, i

by mojuba 5y ago

Someone else has already mentioned in this thread that backends only ever interact with other programs, not humans. This fact alone makes it easier to design, implement and scale. And like I said elsewhere it is in fact so much easier that a backend can be built to be 100% correct and bug free, while for any more or less interesting and useful frontend it is practically impossible to achieve.

majormajor 5y ago
That's nonsensical. User input is passed to backends all the time, and results in just as many difficulties there. From SQL injection and other "untrusted input" problems, to dealing with migrating five years worth of user data to a new system because the old backend can't keep up, to trying to keep every piece of data in a consistent state. Look at CAP theorem: it literally says "you can't have a perfect system here, you have to choose." That's a backend problem with literally no "100% correct and bug free" answer! (With regard to the original article here, your error is that you're assuming modern backend software is closer to "low level" than "high level" compared to frontend code. It really isn't. And in terms of running your code, it's often at a HIGHER level than an app running directly on a user's device - you're in containers on VMs on someone else's hardware in a cloud environment, say.)
- 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.
- jensensbutton 5y ago
  Backends also need to design/build for their operators.
- klodolph 5y ago
  I think the CAP theorem is a bit overstated. It’s not, “You can’t have a perfect system,” but “You can’t have a system which is both available and consistent during a network partition.” True, and interesting, and useful to know, but if “100% available” is in your requirements to begin with, you are doomed to fail and the CAP theorem is just more nails in the coffin. To me, the “you can’t have a perfect system” is really just, “You can’t have 100% availability, and you can’t have 100% durability either.” The hard part is then convincing the users of your system that even though your system seems perfect, they should be prepared for it to fail. IMO the backend API solution is somewhat easy. 503 Service Unavailable. Then the front-end needs to somehow present a meaningful error message to the user, with a plan for how the user can accomplish their desired action or at least save their state and try continuing later… which can get insanely complicated…
  - majormajor 5y ago
    If your backend is frequently throwing 500 errors and "convince the users of your system that this is OK" flies with your management, sure, backend is easy! But that's often not the requirement... 100% available isn't the requirement per se either, but "as available as possible because outages cost us $XXXX/minute" is. And pushing that number up is HARD. And remember the context of this thread: we have a claim here that backend IS easy and that it CAN be "100% correct and bug free." Saying this allows for random-ass 500 errors whenever stuff is broken is such a huge copout as to make that original claim meaningless.
    - klodolph 5y ago
      > If your backend is frequently throwing 500 errors and "convince the users of your system that this is OK" flies with your management, sure, backend is easy! Strawman argument. I think you’re responding to something I didn’t write. The argument is kind of absurd. > …but "as available as possible because outages cost us $XXXX/minute" is. “As available as possible” is not a reasonable requirement. If this is your requirement, you’re in deep shit, but for different reasons. The problem is that you can generally spend more money to get more uptime. At some point, you have to say that the cost of more uptime is too dear. You can do experiments, testing, and simulation to get a more quantitative handle on the trade-off between uptime and resources spent. If you care that much, that is. But “as available as possible” is a bad requirement because there’s no way to tell if it’s satisfied. What ends up happening is that people unsatisfied with uptime can blame you for not having enough uptime, but they aren’t telling you how much is enough. The purpose of having a requirement is to record an agreement between different teams about “how much uptime is enough uptime”. It can be the wrong number, and it can be revisited, but if it’s not a number (with a way to measure it), you won’t be able to calculate other numbers like “how many database replicas do I need?” > And remember the context of this thread… I’m responding to the CAP theorem bit. You said that the CAP theorem means, “you can't have a perfect system here, you have to choose”, and I think that this is misstating the CAP theorem. > Saying this allows for random-ass 500 errors whenever stuff is broken is such a huge copout as to make that original claim meaningless. 503 errors aren’t random. They happen when the backend is unavailable. It’s not a random “stuff is broken” error—that’s 500. This is not a cop-out. Services will sometimes be unavailable. The 503 status is the correct way to signal this to the front-end. The fact that the back-end returns a 5xx series error code does not mean that there is a bug in the back-end. Likewise, if the service is important enough, your front-end should be able to respond to a 503 error with some kind of reasonable workflow for the user.

by mojuba 5y ago

majormajor 5y ago

That's nonsensical. User input is passed to backends all the time, and results in just as many difficulties there. From SQL injection and other "untrusted input" problems, to dealing with migrating five years worth of user data to a new system because the old backend can't keep up, to trying to keep every piece of data in a consistent state. Look at CAP theorem: it literally says "you can't have a perfect system here, you have to choose." That's a backend problem with literally no "100% correct and bug free" answer! (With regard to the original article here, your error is that you're assuming modern backend software is closer to "low level" than "high level" compared to frontend code. It really isn't. And in terms of running your code, it's often at a HIGHER level than an app running directly on a user's device - you're in containers on VMs on someone else's hardware in a cloud environment, say.)

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.
jensensbutton 5y ago
Backends also need to design/build for their operators.
klodolph 5y ago
I think the CAP theorem is a bit overstated. It’s not, “You can’t have a perfect system,” but “You can’t have a system which is both available and consistent during a network partition.” True, and interesting, and useful to know, but if “100% available” is in your requirements to begin with, you are doomed to fail and the CAP theorem is just more nails in the coffin. To me, the “you can’t have a perfect system” is really just, “You can’t have 100% availability, and you can’t have 100% durability either.” The hard part is then convincing the users of your system that even though your system seems perfect, they should be prepared for it to fail. IMO the backend API solution is somewhat easy. 503 Service Unavailable. Then the front-end needs to somehow present a meaningful error message to the user, with a plan for how the user can accomplish their desired action or at least save their state and try continuing later… which can get insanely complicated…
- majormajor 5y ago
  If your backend is frequently throwing 500 errors and "convince the users of your system that this is OK" flies with your management, sure, backend is easy! But that's often not the requirement... 100% available isn't the requirement per se either, but "as available as possible because outages cost us $XXXX/minute" is. And pushing that number up is HARD. And remember the context of this thread: we have a claim here that backend IS easy and that it CAN be "100% correct and bug free." Saying this allows for random-ass 500 errors whenever stuff is broken is such a huge copout as to make that original claim meaningless.
  - klodolph 5y ago
    > If your backend is frequently throwing 500 errors and "convince the users of your system that this is OK" flies with your management, sure, backend is easy! Strawman argument. I think you’re responding to something I didn’t write. The argument is kind of absurd. > …but "as available as possible because outages cost us $XXXX/minute" is. “As available as possible” is not a reasonable requirement. If this is your requirement, you’re in deep shit, but for different reasons. The problem is that you can generally spend more money to get more uptime. At some point, you have to say that the cost of more uptime is too dear. You can do experiments, testing, and simulation to get a more quantitative handle on the trade-off between uptime and resources spent. If you care that much, that is. But “as available as possible” is a bad requirement because there’s no way to tell if it’s satisfied. What ends up happening is that people unsatisfied with uptime can blame you for not having enough uptime, but they aren’t telling you how much is enough. The purpose of having a requirement is to record an agreement between different teams about “how much uptime is enough uptime”. It can be the wrong number, and it can be revisited, but if it’s not a number (with a way to measure it), you won’t be able to calculate other numbers like “how many database replicas do I need?” > And remember the context of this thread… I’m responding to the CAP theorem bit. You said that the CAP theorem means, “you can't have a perfect system here, you have to choose”, and I think that this is misstating the CAP theorem. > Saying this allows for random-ass 500 errors whenever stuff is broken is such a huge copout as to make that original claim meaningless. 503 errors aren’t random. They happen when the backend is unavailable. It’s not a random “stuff is broken” error—that’s 500. This is not a cop-out. Services will sometimes be unavailable. The 503 status is the correct way to signal this to the front-end. The fact that the back-end returns a 5xx series error code does not mean that there is a bug in the back-end. Likewise, if the service is important enough, your front-end should be able to respond to a 503 error with some kind of reasonable workflow for the user.