Don’t we all just want to use SQL on the front end?

But, yeah, this happens with REST APIs too.

I'll scream from the rooftops: Yes. Meteor has its shortcomings, MongoDB being a big one, but this pattern of unification is so fantastic for every party involved that even reading about the "new-fangled acronym for building apps" disappoints me.

Now, we've got the JAM Stack (that's the new one, right?): you got your separate web frontend and service-oriented backend, probably communicating over GraphQL, then you've got your database language, probably SQL, but wait, lets put Prisma in front of that so that speaks GraphQL, but it'll be a different GraphQL schema than your frontend because you don't want to expose data, and jeeze maybe serverless functions as well, that sounds good, and i'll just stop typing here because the level of complexity and intricacy we've reached just to build a fully-featured web application is far beyond useful.

The new-generation tools we've built to make development easy for teams of 200 engineers now demand that every team have 200 engineers. Its a self-fulfilling prophecy; congratulations, you just universally raised the cost of software for every human on the planet.

A few days ago, I installed Nextcloud on a little $10/month Digital Ocean instance. I'm blown away by the performance this PHP app puts down. Blown. Away. Using Google Drive, a pretty damn "snappy" app relatively speaking, feels like walking through mud in comparison, and lets not even go down the rabbit hole of the billion dollar data centers and 56 core Xeon Platinum processors behind Google Drive.

Modern web stacks fail along every metric, except "how easy is this for our massive team of developers to maintain." (Of course, they don't actually "fail"; we developers just move the goalposts so 'master' passes, future changes might fail it but we can fix that). They're insane to get started on, hard to maintain, hard to monitor, and at the end of the day have far worse performance for end-users. We started with the monolithic systems which share a ton between server and client, decided those were a mistake, then overindexed in the entire opposite direction instead of iteratively addressing what was wrong with them.

I predict a move back in the opposite direction. The situation has become insane, and I want PHP, Meteor, and Rails. Fortunately, they're all still there, but Meteor has mostly fallen into maintenance mode (not to mention, MongoDB), and JavaScript really doesn't have another solution like this.

10 years later, there are special cases on top of the special cases. The reality of compromising over and over when adding new features has added up and it's hard to remember the right way to get the correct currency converted total for an invoice (so you need to get the total in each currency, but not add the line items that are marked as 'deleted', then apply discounts, then convert currencies to USD, then add tax, then add shipping, then convert to the local currency, except when the delivery address is in Russia where legally you have to ...). Lots and lots of things are like this, and with no abstraction to ensure that these computations are isolated in a single component in the system you are going to get nowhere.

It's something you should never do. Off the top of my head:

1) Security (as has been beaten to death here)

2) Interface versioning. If you expose a generalized SQL interface to your consumers directly, good luck ever making a change to your database schema. You'll have no idea whose workflows you break. This high coupling becomes very painful very fast.

3) Abstraction. The way data is stored is often not the way data should be surfaced. What about application layer data integrity, things like that? This would require the frontend client to have far too specialized of knowledge as to how the backend works.

4) Optimization. How do you optimize for queries you don't control? Someone will craft something that can bring your database to its knees under load without even trying to.