Hacker News Reader

Comment by SideburnsOfDoom | Hacker News Reader

Why would a lambda fn be considered untrusted client code?

If the database and the lamdba fn are both in AWS, then they're on the same "server estate". How is this any different from the server portion a web app?

View on HN

This is something that annoys me about relative terms like "client" and "backend". An entity can simultaneously be the client of one pair and the server of another.

No good solution comes to mind, aside from being very explicit. "database client" vs "user client".

Indeed, this was a very confusing conversation because of it.

If by client you mean "a web browser" then "a better approach is where there's code between the client and the database" makes perfect sense; but in the meaning of "client" where any code that calls the database is a client of the database, it's balderdash.

I honestly don't think that a "trust boundary" has anything to do with it, generally.

Maybe I wasn't clear on that - a lambda function calling the database is indeed trusted.

API Gateway in AWS can't directly talk to the DB. It has to either hit a mock (where a canned response is sent back), a lambda function, or serve as an HTTP proxy. You may of course be referring to the more abstract concept of an API Gateway that then talks to a backend DB directly without passing through intervening code, and yes, that would be stupid. But you hardly need serverless infrastructure to achieve that level of wrongness; even with a server in between, you can easily achieve the equivalent of that by taking a SQL string from the client verbatim and executing it against your DB.

Reply on news.ycombinator.com