My experience is that giving front-end developers who does not understand databases the ability to do this is a great way of killing performance across the board.
I don't particularly want that to be easy, because I've too many times had to clean up the consequences.
If you have a team where everyone understands the database implications, then awesome. In that case this consideration may not apply.
And this is why in general I don’t like ORMs, even my favorite ORM, Django’s. They hide from you the query complexity — and perhaps also the number of queries — that your ORM query produces. There are situations where a different ORM approach would yield similarly shaped data yet consumes orders of magnitude more or fewer resources. And this is without adding any new indices.
In general I don’t like giving anyone the ability to write queries unless I trust they understand the performance ramifications. This can be difficult to enforce because someone “on the outside” can always abuse your thoughtfully constructed set of access points you’ve provided by sticking them in nested loops.
Perhaps an answer is strict allocation of quotas outside the realm of assumed competence and good will.
That's why I only use orm with the simplest query. It helps so much if the queries are just select where, create update delete rather than composing the queries myself.
I totally agree. I much prefer tools like the now-deprecated Yesql for Clojure that provide for easy mapping of actual SQL queries to function wrappers for those queries. Also, given that the database is where your data model’s consistency should be enforced, stored procedures and views are your friends. The last fifteen years of web app frameworks and developer practices have abused/neglected RDBMS systems by regarding them as simple table stores. ORMS are a classic “now you have two problems” non-solution.
It can be a very bad thing or an acceptable payment for developer velocity, based on what's your business priorities with the project.
I have a couple of issues that I worked on that started exactly like this: front-end developer implemented a feature based on GraphQL, but when we deployed this feature, we quickly disabled it after receiving alerts from production database, and re-enabled it back only after backend developer (me) went and worked on database indexing.
But for my team, at the current point of the project's development, this scenario is a net positive overall, because we're exactly in "move fast and break things" mentality, which suits our product and our place in the market. If our project would require a lot of 9s, or worked with very confidential data, or had 10s of millions of daily users, we would have completely different internal procedures and development practices: much safer and much slower.
I agree with this - my current main focus is effectively a CRM where I've exposed abilities for front-end devs to outright write SQL directly - as a shortcut when you need to get things done fast it can be fine.
But I've also never seen this done without getting horribly abused, and so I tend to lock things down gradually as a service matures or the team grows.
Then again, developers will try to work around it - I had one project many years ago where I on purpose introduced a very restrictive template language to ensure proper separation of content and logic, in large party because the templates were translated to 17 languages, and avoiding breakage was a lot easier the less logic there were in them...
Cue two of the developers trying to sneak in a tag to allow embedded Perl...
I don't particularly want that to be easy, because I've too many times had to clean up the consequences.
If you have a team where everyone understands the database implications, then awesome. In that case this consideration may not apply.