GraphQL is a consequence of the SPA design, a bad design leads to a worse fix.

The drawback is that the frontend now has its own schema, often it starts as a naive direct mapping of the real schema.

Thus any changes in the real schema also need to change the frontend schema and every use of it, or the mapping to the frontend schema needs to change.

Eventually these two schemas will diverge because it is not feasible that every schema change results in frontend change. Especially if the idea is to have two different teams working from either side, then the backend team can’t wait for the frontend team therefore the schema mapping will change.

And the thing is that the frontend shouldn’t be aware of how the backend schema is constructed, if the User model is separated into three different tables, because of some technical reason, that should not change how the frontend operates. The frontend understanding of what a User is shouldn’t be the same as the backends.

Therefore ideally frontend schema and the backend schema will always differ. They don’t view the world the same way.

However what you now have is a slow mapper between the frontend schema and backend schema.

The point of relationship databases is that you can view your data from different perspective by doing different SQL queries. That is already built in. But now we have invented yet another layer on top of SQL, usually in combination with the already monstrosity called ORM.

What a tortured usage of GraphQL. Schema files are automatically generated by the backend, and components pull data that they need, and know more. If you find yourself changing schemas constantly, then you’re not defining them in a scalable manner. You’ve basically misused the tech, and blamed it on the tech instead of your misuse.

That is even more horrible what I thought. Automatically generate schemas 1:1 and then expose it. Let me guess tons of information leakage, ddos attacks and queries not hitting indexes. This is absolutely the worst idea I come across in web development. Horror.

GraphQL is just another artificial solution to a problem created by SPAs themselves. Same as SSR, hydration, server components, client side routers, dynamic bundles loading, dynamic translations loading, etc, etc, etc. A whole industry of workarounds for a broken idea. Now 10 years after SPAs became popular we starting to approach a point were we almost have what we already had.

What I really don't get is why we don't just expose SQL directly at this point. Is it just security? Database servers have fairly extensive authentication and authorization models.

Authorization & access restrictions. Yes, you can go quite far with table/row/column permissions, but a lot of business logic cannot be modeled using just those (i.e. "user cannot place orders if total outstanding invoice payments surpass value $X").

The combination of DB permissions, DB constraints, and simple (SQL, not procedural language) triggers gets you a lot, including the ability to enforce rules like the one you mention.

Yes, you can enforce a lot through SQL triggers/stored procedures etc. But you often end up abusing your DB/SQL as a business logic layer, where your business logic is encoded in a huge set of row/column permission and custom SQL triggers . This tightly couples your database into your whole business application stack.

Especially in Oracle PL/SQL, I've seen this often abused to an extend where no one ever understood the whole business logic anymore (as logic was spread out in frontend, middle-layer services, and DB mumbojumo), and the database became a fragile core-piece (with a significant vendor login) and hindered all sort of future development.

Seriously, your business logic should be modelled in code, ideally in some sort of service layer (which does not necessarily mean microservices!).

> But you often end up abusing your DB/SQL as a business logic layer, where your business logic is encoded in a huge set of row/column permission and custom SQL triggers.

That's not “abuse”. Admittedly, it's no longer an essential best practice for most systems, the way it used to be viewed, because it's more common to have a single application which fully owns the database and not to (at least in idealized theory, though very some ops staff still end up with direct access to the prod DB) allow access by other means, so in theory it doesn't tend to be necessary to avoid either circumvention of rules or (inevitably inconsistent, as well as expensive to maintain) duplication of logic.

Then why aren't we working on improving the databases to allow for such complex rules, and instead wrap it in another layer (often multiple) to do all this stuff there?

because a database should not hold your business logic. It should hold your data, and that it can do well. See also my other post on parent for more reasoning.

I beg to differ in many interesting cases, we put at least some parts of the business logic into the database. The table design is a direct consequence of the business logic, the same is true for constraints and triggers.

Why shouldn't it? As noted above, database servers already have most of this (security) logic in them - likely tested much better than whatever you can write on top of the database yourself. And given how many apps are basically just CRUD, why reinvent the wheel every time?

Mostly because the tooling is so bad. Or do you have unit tests, lint, and easy version control for your stored procedures? Are they written in a way that matches at all what rest of your programming is? Can you import a randomly picked utility library?

The next obvious question is, why is tooling so bad then? And would it have been so bad if we invested as much into RDBMS as we did into Node.js web-frameworks-of-the-day.

Writing the next modern elegant artisanal javascript webshit is a lot easier than making a sandboxed programming environment that integrates tightly with a production quality database engine and has a good story for testing, deployment, debugging, etc.

Even if you solve the security issue, a query can easily bring down the server if it has a complex join query.

This could be solved by only exposing stored procedures, but that just moves the code to the database server instead of the REST service with the same problems as before.

You can also use a VIEW.

How does GraphQL make sure to respect table indexes? If not you get a super slow query.

You can still get performance issues with a view if you "select *" on a large amount of data, or join with other views. By exposing the SQL to a web page, you also open up for DDoS attacks more easily, as you can write complex SQL queries

You can get the same problems with GraphQL or stored procedures too of course, if the queries are not optimized correctly

So what's the solution to this?

Performance quotas.

Because a human is writing the resolvers pulling the data from the database. Set whatever index you want to use.

Just give the end user an account to phpMyAdmin. Done. No complex frontend framework required.

You wouldn't belive how often companies use excel with external datasources like this. Excel basically is the common-ui for a lot of people.

And most of the projects I worked on in my professional career as a webdev, were replacing such workflow with a proper web application, because excel does not scale and eventually people fuckup their data.