It's more effort to have to maintain some extra SQL code for those views, but with all the labour-saving PostgREST delivers in the first place, you still come out ahead.
From the sqler readme I couldn't tell if either of those were available but I have used columns aliases when I have used other SQL to API gateways (like http://restsql.org ).
Such db level features definitely don't give you as much power to abstract as a full middle tier, but at least it is something. The trade may be worthwhile for the speed of API building. (I have worked with Google sheets as an API provider and that was far less flexible than sqler appears.)
It is always possible (though perhaps not pleasant) to swap out an API built on this type of direct SQL access technology with one built on a traditional middle tier.
It is really amazing what modern databases are capable of and at the same time also surprising that most applications in the wild don't use them to the fullest of their capabilities.
I have been personally exploring on ability to efficiently map GraphQL queries to database operations while retaining the ability to write business logic in typescript (which I currently believe offers the best compromise wrt type safety and flexibility among popular mainstream languages). My preliminary work is available on github  and I welcome any feedback and contributions.
As mentioned in another reply, there seems to be quite a reluctance to use/accept plain SQL, and SQL injections are usually treated as vulnerabilities, though I doubt that it's necessarily worse (that is, more of a potential vulnerability) than an average web back end.
Users (not as in "API users", but as in "service users") usually aren't familiar with SQL, and it's not great to write queries manually each time (even if there are views and stored procedures with predefined ones), but SQL being exposed to clients ("API users") is reality, even if uncommon. Coincidentally, I worked on a project like that just this week, and on others taking such an approach in the past.
- For permissions: the db is readonly.
- For performance: there is an execution time limit for each query.
It also pairs beautifully with the read model in CQRS inspired designs.
Another problem is the SQL flavor implemented by RDBMs. Every major RBDMs has their own distinct flavor of SQL. So forcing everyone else to learn a specific flavor of SQL is going to be a hassle. Especially if the RDBMs was changed.
But the biggest issue is security and performance ( especially true for sensitive data ).
APIs are there to make things secure, user friendly, consistent and of course robust in the face of back-end changes. I doubt most companies or people would allow direct access to their DBs. If people wanted to run queries on their dataset, they might let you download the dataset and run the queries locally.
Your application layer "security system" is just row level security done outside the db.
Yes, that Infocom, if Zork fame.
After doing interactive fiction, it tried to use its parser to drive a database. Instead of “SELECT * FROM...” a user could write, “Show me all the people in London who own cats.”
Here's an excerpt from wikipedia:
"One development decision that proved fateful for the product—and the company as a whole—was the decision to make Cornerstone run via a virtual machine (VM). The use of Infocom's "Z-machine" for its interactive titles had been a huge boon: since all the games were written in an intermediate language (called ZIL), the company could release one title for every major platform simultaneously. The developers hoped to do the same for Cornerstone and its subsequent products. The existing VM proved unsuitable for the database application, so a new one was written for the product. The developers produced the VM for the IBM PC first, planning to write VMs for other platforms after the initial PC release."
Plus having the database exposed means its easier to attack from outside and that's where all the important stuff is.
Zero configuration to generate REST APIs for any MySQL databases
I sorely miss a comment about security authentication, however. How are sessions done? Cookies? Etc?
More fundamentally, I find myself really liking many things that are inspired by CGI. I think that when we moved from CGI to monolithic application servers two decades ago, despite all the good reasons to do so, we threw a lot of babies out with the bathwater. There's an elegance to the "http request? just run some code" model that only very recently got popular again with AWS Lambda and the likes.
I think the biggest problem with Rails is Arel and by making it easier to write raw queries that serve json straight from the database you get great performance, composability and its still all really simple.
I don't need GraphQL because its so easy to write in one one endpoint everything I need to get back from my database and then write endpoints for all the smaller endpoints.
But yeah my project is basically handlebars meets SQL. I'm currently working on writing my own template language and hope to port it to other common languages.
I get really depressed working on projects with a million small endpoints or they take the other extreme of using GraphQL.
I'm quite tired of Full-stack development since things are taking 100x more effort and not because things are getting more complicated because they can't see the simpler solution.
Migrations are, of course, a possible solutions, but I'm yet to see a decent toolset for managing schema changes.
Now, this definitely looks like a programming language construct. How long before this project gets loops and conditionals? See for example ansible.
I arrived at something similar recently in Rust, using actix-web. However, as an open source author of prior work (Yosai, in python), I realize that releasing this work is only the beginning. There's a lot more effort required to make an open source project viable. I'd gladly talk with folks about how one might do it, though.
It would be helpful to understand the demand for a project like this (and postgrest et al). What are the use cases where people finding value in creating enterprise-quality auto-generated endpoints?
Did it take off? Of course not.
nginx configuration looks nothing like HCL (which is json compatible)