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.
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.