4 ms·

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, refe

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.

SideburnsOfDoom 10y ago
> 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.
- Spearchucker 10y ago
  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.
  - SideburnsOfDoom 10y ago
    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?
    - Spearchucker 10y ago
      Maybe I wasn't clear on that - a lambda function calling the database is indeed trusted.
      - lostcolony 10y ago
        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.
    - solipsism 10y ago
      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".
      - SideburnsOfDoom 10y ago
        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.
- lsllc 10y ago
  > 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.
  - SideburnsOfDoom 10y ago
    "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 https://news.ycombinator.com/item?id=11925043 2) https://www.owasp.org/index.php/Top_10_2013-A1-Injection https://www.owasp.org/index.php/Top_10_2013-A1-Injection 3) http://www.odata.org/ http://www.odata.org/

SideburnsOfDoom 10y ago

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

Spearchucker 10y ago
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.
- SideburnsOfDoom 10y ago
  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?
  - Spearchucker 10y ago
    Maybe I wasn't clear on that - a lambda function calling the database is indeed trusted.
    - lostcolony 10y ago
      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.
  - solipsism 10y ago
    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".
    - SideburnsOfDoom 10y ago
      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.
lsllc 10y ago
> 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.
- SideburnsOfDoom 10y ago
  "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 https://news.ycombinator.com/item?id=11925043 2) https://www.owasp.org/index.php/Top_10_2013-A1-Injection https://www.owasp.org/index.php/Top_10_2013-A1-Injection 3) http://www.odata.org/ http://www.odata.org/