At some point during the dot-com era, Microsoft toyed with adding an HTTP server to its SQL Server product to enable similar development paradigms. My recollection is that this was a disaster on several fronts, not the least of which was that successfully breaching the HTTP server gave an attacker direct access to the database. This (and other considerations) make a good case for the kind of separation-of-concerns which would avoid entwining API service with DB access.
I read the README, but it focuses on the practical aspects of getting the solution to work, not its philosophical justification.
edit: When I say "disaster" for the MS SQL Server attempt, I don't believe anyone ever experienced a breach, etc. But, as I recall, there were no large customers (MS caters to the larger corporate crowd) with IT deparments willing to risk exposing their DB servers to the "DMZ zone" of public Internet access (or only 1 layer past is, such as behind a proxy). So from that standpoint the disaster was providing a solution nobody (with money and corporate experience) wanted. I guess for hobbies or Silicon Valley MVPs, the concept might have some legitimate appeal.
I read the README, but it focuses on the practical aspects of getting the solution to work, not its philosophical justification.
edit: When I say "disaster" for the MS SQL Server attempt, I don't believe anyone ever experienced a breach, etc. But, as I recall, there were no large customers (MS caters to the larger corporate crowd) with IT deparments willing to risk exposing their DB servers to the "DMZ zone" of public Internet access (or only 1 layer past is, such as behind a proxy). So from that standpoint the disaster was providing a solution nobody (with money and corporate experience) wanted. I guess for hobbies or Silicon Valley MVPs, the concept might have some legitimate appeal.