Comment by SideburnsOfDoom | Hacker News Reader

Comment by SideburnsOfDoom | Hacker News Reader

Parent Full thread

SideburnsOfDoom

> In the 90's we had message queues. In the 00's we had service busses. Today we have API gateways. All they do is route requests - they're all the same thing.

On AWS, you have options a message queues (SQS), busses (SNS), API gateways, and load balancers (ELB). i.e. many of the existing proven patterns are still around, and you can choose which one is best for the particular circumstance. And that indicates that while they have similarities, they're not exactly the same thing.

I can see cases where a design of "API gateway -> lambda fn -> database" is performant, simple and very cost effective. particularly where the function is very simple and load is low or varies a lot. That won't be everything though.

I don't understand why you think that "Direct access to the database" is always bad. Someone has to access that database directly, on behalf of everyone else who is insulated from it. A lambda fn may not be worse than a web app for that role. But if it is inadvisable, then it can use the same indirect requests that a web app would.

If you give client code access to your database you have to trust that client to respect data types, sizes and, depending on how your database is designed, referential integrity. There's risk of data loss because again, you have to trust the client. There's risk of denial of service in scenarios where the client fills up your database with junk. It's risk all the way down and using it or not is down to probability x impact.

> If you give client code access to your database you have to trust that client to respect ...

I get all that but I still am unsure of what you mean. A database is useless if no-one can ever access it. So some code somewhere accesses that database, not so? And other code makes request to this code?

What do you consider "client code" and what are you comparing this to? Why do you think that lambda functions cannot be in the second category, and if they cannot be, why can't they use the same gated mechanisms as other "client code", and I would assume that they use restful http to read, and http or message queues to write?

> There's risk of denial of service

in the AWS lambda case, the rate limiting is specifically the role of the api gateway. There's always the risk, and I don't think that lambda increases it.

First, "client". A client is anything that calls a server but is outside the trust boundary of that server.

And yes, of course there's code that accesses the database. The problem is that if it's client code, that code must be trusted by the database.

A better approach is where there's code between the client and the database, also on the server (server estate, at least), that verifies data going into and out of the database.

That isolates client-side changes - malicious, unintentional or otherwise, that might impact the data, because there's a server-side gatekeeper.

So all of a sudden FAAS is more appealing than BAAS, and the FAAS API gateway doesn't just do routing, it does validation too. Guess what, you just created an application/business logic layer on a middle tier, and it's no longer serverless.

"...Why do you think that lambda functions cannot be in the second category..."

They can indeed be in the second category. The author, however, specifically calls out direct database access from the client without lambda functions.

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?

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.

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.

> The author, however, specifically calls out direct database access from the client without lambda functions.

Ah sorry, I missed this part:

> 2 Using another example of BaaS, we’ve allowed the client direct access to a subset of our database (for product listings)

"The client" in this sense is a web browser and is thus completely untrustworthy. He seems to be talking about read access, hopefully with an api gateway for auth and rate limiting in front of it. But yes, it is wise to be much more wary of this case.

> I get all that but I still am unsure of what you mean.

Direct database access would be like exposing ODBC from the DB directly to a web application. You either have to trust that the application doesn't do a "drop table ..." or hope that the DB has fine-grained enough access controls to prevent that.

Whereas in a SOA design, the API endpoint runs your code that gates access to the DB.

"web application" could mean a number of things. To me "web app" in the comments above meant the code on a server that handles http requests, not the browser client of it. You are talking about Javascript running in the browser of a random internet user, right? It could be catastrophic to allow that level of access to a database from the public web, obviously.

As is pointed out in (1) that can happen already through carelessness. And it does (2)

But it probably isn't what was intended in a newly designed general system. That would assume great stupidity.

I suspect that even the "no code, just access the database" actually has some kind of code and config in front of the db, like odata (3). I'm not saying that odata is great, but it is an example of trivial access to a database. it's gated, mostly read-only and configurable, but it probably doesn't count as "writing a custom server app to gate to a database"

1) https://news.ycombinator.com/item?id=11925043

2) https://www.owasp.org/index.php/Top_10_2013-A1-Injection

3) http://www.odata.org/

Reply on news.ycombinator.com