I mean… the database does all the shit itself, just give it some SQL queries. It’s incredibly important to realize that nearly all this complexity is optional - it may make sense for Facebook to invest this much in their backend infrastructure but most companies could get away with plain ol’ script that on top of Postgres.
As a backend developer you should know when things like load balancing and and complex db schemas add little value, a single table is good enough. Maintaining complex systems costs money and developers should always advocate for the simplest most sustainable solution to a problem. I think we have a real issue with pursuing shiny new technologies.
Absolutely, it’s why at our company I laid the groundwork to eventually adopt a read replica based database approach but didn’t push to actually set up such an environment until about six years later when we had a compelling reason to switch. I work in PHP and the language itself is pretty irrelevant because most pages are just some validation and then shuffling the request off to the database - it doesn’t make sense to over engineer since you’ll end up paying to maintain things that don’t benefit you.
Using a single table is almost always a bad idea though - for prototyping it can make sense but strong typing ends off paying off quickly in not having to write defensive code.
People on all sides are guilty of over complicating things and it’s not helpful for building an agile product. I’d say that there’s a generally accepted assumption that “modern web” means react or some other flavor of SPA - these are amazing tools but aren’t always necessary. Tools are powerful, but you should understand what you’re using and have a justification as to why (or at least make it obvious that decisions were made arbitrarily since sometimes you’ve just got to choose one).
Nobody is arguing for overcomplicating things, and it’s true that a lot of projects out there are in fact overdesigned. However, there are also non-trivial applications out there, and front-end can in fact be complex in such apps. For example, I worked at a hospital at one point, and my team built an application that allowed multiple users to work collaboratively on shared documents seeing each other’s changes in real time. That’s a kind of app that is non-trivial, and where there’s plenty of legitimate complexity to be found both on the frontedn and the backend.
I mean… the database does all the shit itself, just give it some SQL queries. It’s incredibly important to realize that nearly all this complexity is optional - it may make sense for Facebook to invest this much in their backend infrastructure but most companies could get away with plain ol’ script that on top of Postgres.
As a backend developer you should know when things like load balancing and and complex db schemas add little value, a single table is good enough. Maintaining complex systems costs money and developers should always advocate for the simplest most sustainable solution to a problem. I think we have a real issue with pursuing shiny new technologies.
Absolutely, it’s why at our company I laid the groundwork to eventually adopt a read replica based database approach but didn’t push to actually set up such an environment until about six years later when we had a compelling reason to switch. I work in PHP and the language itself is pretty irrelevant because most pages are just some validation and then shuffling the request off to the database - it doesn’t make sense to over engineer since you’ll end up paying to maintain things that don’t benefit you.
Using a single table is almost always a bad idea though - for prototyping it can make sense but strong typing ends off paying off quickly in not having to write defensive code.
People on all sides are guilty of over complicating things and it’s not helpful for building an agile product. I’d say that there’s a generally accepted assumption that “modern web” means react or some other flavor of SPA - these are amazing tools but aren’t always necessary. Tools are powerful, but you should understand what you’re using and have a justification as to why (or at least make it obvious that decisions were made arbitrarily since sometimes you’ve just got to choose one).
Nobody is arguing for overcomplicating things, and it’s true that a lot of projects out there are in fact overdesigned. However, there are also non-trivial applications out there, and front-end can in fact be complex in such apps. For example, I worked at a hospital at one point, and my team built an application that allowed multiple users to work collaboratively on shared documents seeing each other’s changes in real time. That’s a kind of app that is non-trivial, and where there’s plenty of legitimate complexity to be found both on the frontedn and the backend.