[kartickv]

Author here.

> This article doesn't use the word "permission" or "validation"

The article talks about it multiple times: using a database user account with limited privledges, exposing some tables but not others, exposing read but not write access, giving users access only to data they own.

> it's nearly impossible to parse and check an arbitrary SQL query for malicious intent

Which is why the article doesn't propose trying to parse and check queries for malicious intent.

> it now passes the responsibility of query performance to the FE engineer. Are appropriate indexes in place? Does the query make inappropriate JOINs?

No, in the proposal, we have backend engineer(s) to advise and assist frontend engineers. Having appropriate indices and JOINs doesn't mean you have a layer that doesn't add business value. And when it does add value, write it!

> schema changes now mean that you need to update your front end code. This means guaranteed hard downtime, because you can't control what JS folks are running in the browser.

I don't know if I understood you, but you can just force a refresh in the browser.

> you also need to make sure that queries aren't designed to intentionally DoS your DB.

That's a valid point I didn't think of.

> There's a lot wrong with the ideas presented here.

It's hard to take your criticism seriously when many of your reactions are a result of your own misunderstanding of the proposal.