4 ms·
Because if you are writing a fairly standard web app, you don't need this. There isn't the scale to make it important. Software is a very large field, with a wi
by momokoko 7y ago
Because if you are writing a fairly standard web app, you don't need this. There isn't the scale to make it important. Software is a very large field, with a wide variety of use cases. Obviously an exchange trading platform is going to have much more focus on these DB issues than a SaaS web app for business that expects at most 5,000-10,000 users at a time. With very few of those user modifying the same records.
- coldtea 7y ago>Because if you are writing a fairly standard web app, you don't need this. Does the app handle user accounts? Payments? Data editing? Multiple logins into the same account? Then it should handle races and transaction properly... That said, it's true that they can be rare, and might be less worth it (engineering or time wise) than just letting it go. For an app with like a few thousands users or internal use, the odds might be small. But a fairly standard web app might serve 1M, or 10M or 100s of millions of people, and they deserve better.
- momokoko 7y ago> deserve better So less features and slower performance to account for the hypothetical case where someone tries to edit their user account from 50 devices at once over and over again? > But a fairly standard web app might serve 1M, or 10M or 100s of millions of people You are talking about less than 0.5% of revenue generating SaaS apps.