Comment by kartickv | Hacker News Reader

Comment by kartickv | Hacker News Reader

Parent Full thread

Author here:

> 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.

alter table addresses enable row level security;

However this article is insane because of the security nightmare of trusting all incoming queries

Reply on news.ycombinator.com