I get the reasoning behind this, and I agree with some of that. But I don't agree with this. For reasons:
1. You can't trust the front end. Backends must be written assuming that every call from the front end is malicious. Validations must be duplicated in both the UI (to show people that they can't do the thing), and the back end (to stop them from the doing the thing).
2. There will be multiple front ends. If all your business logic is in the front end, you'll have to duplicate it into all of them. Where it will rapidly get out of synch and you'll have different behaviours on different clients.
3. The entities that make the most sense for storing your data into a database are not the same entities that make the most sense for using in a UI. Forcing your UI to use the same entities as your database will mean more work for both, and often ends up influencing the database design badly.
4. There are ways of writing APIs that allow for rapid change. Uncoupling the storage entities from the display entities is a key step, so you can change things in the database without affecting the front end (and vice versa).
5. There are ways of writing database schemas that allow for rapid change. My favourite is adding a hstore "metadata" field that I can use to create "temporary" fields in the table for experimental features.
I've written a few back ends, and the advice in the article strikes me as dangerously sensible-sounding while being mostly wrong. I can see a newbie product manager buying into this completely and making a huge mess.
> 1. You can't trust the front end. Backends must be written assuming that every call from the front end is malicious.
This is already taken care of in the proposal, by permitting clients to access only data they own.
> 2. There will be multiple front ends. If all your business logic is in the front end, you'll have to duplicate it into all of them. Where it will rapidly get out of synch and you'll have different behaviours on different clients.
No, because a) not every startup starts on multiple platforms b) you can always put common behavior into a piece that's reused. This can be a library linked in to multiple frontends, or a backend API. The post says your backend should be as thin AS POSSIBLE. It doesn't say you shouldn't have a backend at all costs, even if that means duplicating code.
> Forcing your UI to use the same entities as your database.
Nothing prevents you from mapping the entities to different ones for your frontend, in cases where you need that.
> The advice in the article strikes me as dangerously sensible-sounding while being mostly wrong.
I don't think you even understood the advice in the first place, as I can see from your misconceptions above.
> This is already taken care of in the proposal, by permitting clients to access only data they own.
But you don't propose any method for that apart from hand-waving about "database user accounts with read access", which is largely irrelevant unless you're proposing to give every one of your customers a database account and do row-level database security.
Let's talk about a concrete example: A call arrives at the back end to change the user's name to "dickwad".
In a conventional backend, you'd check the session, work out which user that session was logged in as, check that it's the same account as the name that's going to change, and maybe then run a profanity filter, or not.
How would you build your minimal backend to do that? Remember, you don't actually know that this call has come from the front end, it could be sent from curl.
> Nothing prevents you from mapping the entities to different ones for your frontend, in cases where you need that.
True, but that's not mentioned at all in your article, and defeats half the point of it - the front end engineer still has to worry about what the database needs and how to do that mapping when it changes.
> I don't think you even understood the advice in the first place, as I can see from your misconceptions above.
What misconceptions? I understood you (almost) perfectly. It's a well-written article. Still wrong, though.
> This is already taken care of in the proposal, by permitting clients to access only data they own.
I'm curious how this works. In a database that stores something like an address, how do you prevent someone from slightly changing the query to give them someone else's address stored in the same table. I've heard of giving per-table access, but never per-row.
1. You can't trust the front end. Backends must be written assuming that every call from the front end is malicious. Validations must be duplicated in both the UI (to show people that they can't do the thing), and the back end (to stop them from the doing the thing).
2. There will be multiple front ends. If all your business logic is in the front end, you'll have to duplicate it into all of them. Where it will rapidly get out of synch and you'll have different behaviours on different clients.
3. The entities that make the most sense for storing your data into a database are not the same entities that make the most sense for using in a UI. Forcing your UI to use the same entities as your database will mean more work for both, and often ends up influencing the database design badly.
4. There are ways of writing APIs that allow for rapid change. Uncoupling the storage entities from the display entities is a key step, so you can change things in the database without affecting the front end (and vice versa).
5. There are ways of writing database schemas that allow for rapid change. My favourite is adding a hstore "metadata" field that I can use to create "temporary" fields in the table for experimental features.
I've written a few back ends, and the advice in the article strikes me as dangerously sensible-sounding while being mostly wrong. I can see a newbie product manager buying into this completely and making a huge mess.