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