The company I work for did this, basically because the people working there had to crank out features as quickly as possible and had no idea what a "back end" even is.
Fast forward almost a decade, and this approach has generated a huge headache. The database is an incomprehensible mess, there's a whole class of features we cannot implement because of this (lack of) architecture, business logic is all over the place (with a million ways to do the exact same thing), mostly in the clients, performance is bad because every client is doing all sorts of queries all the time, and training a new developer either takes months or doesn't really work out at all - because who wants to read a decade's worth of spaghetti code. I've been working on a way to fix this, but it takes a lot of time and effort. Also management still doesn't understand the concept of "overwhelming technical debt".
The only reason this has even been hanging by a thread for so long is that we only make software where the back-end and the clients are run on-premise in a separate network. Otherwise it would be a security nightmare as well.
This article is basically a set of instructions to get to where we are. It's like saying that traffic lights are unnecessary because if you just floor it through an intersection, you'll get to your destination much faster. And you know what, it might just work the first few times. Until you find out why these things exist in the first place.
I'm not saying they weren't successful. As someone who tends to over-engineer things, I do admire their ability to get a product out quickly - I think for a startup that was probably the right decision!
But that's what I've been missing from your article - more on the distinction between the approaches, and the drawbacks of having a thin back-end layer as the product / company is growing. In the beginning I thought you were talking about how to make your startup more efficient and flexible - basically consciously building some technical debt, having weighed your options.
But if that's not the idea - personally I don't know how to scale with this approach, neither technologically nor in terms of team structure. The thin back end layer could work though if you have a lot of small products that are independent of each other - developed by small teams that can afford to act like early startups. Maybe that's what you meant, but I didn't really get that from the article.
I get that you've disagreed with almost every point telling you this is a bad idea, but I think the point is particularly pertinent.
They tried this system, and then realised they painted themselves into a corner. Businesses wants features they can sell to customers, and sometimes fixing technical debt is a luxury. Especially when technical debt hidden to customers.
Adding layers of abstraction when needed might sound like great advice to a startup that needs money ASAP. But down the line when requirements change, maybe those layers of abstraction cost too much time to implement, especially if you're firefighting a dozen other poor choices.
Clients, services... the original developer didn't see anything wrong with it, since transactions exist and foreign key relationships make sure the data model stays consistent, right? And you can combine some frequently used methods accessing the database in some helper classes, and if some of the clients use those, that's basically your business logic!
It's a pretty impressive house of cards.
Refactoring (or rather re-designing) this sort of thing while still churning out new features is tricky to say the least.
Fast forward almost a decade, and this approach has generated a huge headache. The database is an incomprehensible mess, there's a whole class of features we cannot implement because of this (lack of) architecture, business logic is all over the place (with a million ways to do the exact same thing), mostly in the clients, performance is bad because every client is doing all sorts of queries all the time, and training a new developer either takes months or doesn't really work out at all - because who wants to read a decade's worth of spaghetti code. I've been working on a way to fix this, but it takes a lot of time and effort. Also management still doesn't understand the concept of "overwhelming technical debt".
The only reason this has even been hanging by a thread for so long is that we only make software where the back-end and the clients are run on-premise in a separate network. Otherwise it would be a security nightmare as well.
This article is basically a set of instructions to get to where we are. It's like saying that traffic lights are unnecessary because if you just floor it through an intersection, you'll get to your destination much faster. And you know what, it might just work the first few times. Until you find out why these things exist in the first place.