I've got a similar project that reads your db schema and generates a Go REST API and a TypeScript/React web interface. (The code-generation is language agnostic so at some point I'd like to add at least a Java REST API as well.) It supports PostgreSQL, MySQL, and SQLite.<p>Unlike PostgREST/Hasura and some other dynamic tools you can "eject" at this point if you'd like and continue on development without the generator in a language you already know. But I'm working on exposing Lua-based hooks you could carry across whatever backend language you choose to generate and avoid the need to eject.<p>It has builtin support for paginated bulk GET requests with filtering, sorting, limiting. Built-in support for bcrypt-password authentication and optional SQL filters specified in configuration for authorization of particular endpoints based on session and request metadata.<p>Still very much a work in progress but the goal is to push the envelope on application boilerplate.<p>Screenshots are of the example/notes project in the repo.<p><a href="https://www.dbcore.org/" rel="nofollow">https://www.dbcore.org/</a><p><a href="https://github.com/eatonphil/dbcore" rel="nofollow">https://github.com/eatonphil/dbcore</a>
The idea is interesting. But it looks like you end up with a yaml file that enumerates each of your tables/endpoints and the queries that back them. So are we exchanging the “complexities” of code, where we have control and testing, for the “lack of complexity” of yaml that becomes unwieldy and untestable in the name of “simplicity?”
One of the things that's not obvious to me about things like this (and other similar tools) is where/how scopes/limitations/permissions are handled. I assume they either are or can be, I just never see it spelled out clearly. What am I missing?
Perhaps I'm old, but who needs an API for an SQL query? I'm not sure I understand the use case, or the advantage of something like this over a regular API call to a backend which would also allow you to do e.g. authentication. Enlighten me?
Looks great!<p>If you like this, check out OctoSQL[0]... Also in Go... Though OctoSQL lets you query multiple databases / files / event streams like kafka using SQL from your command line, not as a server, so a fairly different use case, but you should check it out nevertheless!<p>The naming clash is funny.<p>[0]: <a href="https://github.com/cube2222/octosql" rel="nofollow">https://github.com/cube2222/octosql</a>
Nice to see openfaas featured here and thanks for your PRs to Arkade. I do wonder what your strategy is on connection pooling and authentication?<p>Also not keen on the passwords being kept in a plaintext file - someone will check that into git. OpenFaaS has secret support which you can use Amal. So does Knative.
Reminds me of the venerable Datasette by Simon Willison: <a href="https://github.com/simonw/datasette" rel="nofollow">https://github.com/simonw/datasette</a>
Interesting concept and quite liked the playful logo. Can we pass in env variables to db connection ?<p>We are in similar space, we take input params of db and generate CRUD apis with Auth+ACL and then APIs are packed into a single lambda function. There is support for serverless framework as well.<p>[1]: <a href="https://github.com/xgenecloud/xgenecloud" rel="nofollow">https://github.com/xgenecloud/xgenecloud</a>
Interesting, I've built a similar project that generates GraphQL API based on your database schema - <a href="https://okdb.io" rel="nofollow">https://okdb.io</a>
My main purpose of tools like these has always been prototypes, or hobby one-off type stuff. For SPAs, or a sketch with a Jupyter notebook. They're great for this sort of thing because in my experience, this used to require building some sort of API just to get a simple json interface to the database. It was my understand that the purpose of these types of tools was mostly that.<p>Are folks using these kind of things for non-trivial production applications?
I fear that all of these "expose your DB as an API" tools like this, Postgraphile, Hasura, etc. are going to set up folks for a world of hurt down the road. Tightly coupling your end clients to your database schema can make it extremely difficult, if not impossible, to refactor your DB in you need to (which is highly likely).
Looks like someone took this tweet literally <a href="https://twitter.com/davecheney/status/1296033304756404225" rel="nofollow">https://twitter.com/davecheney/status/1296033304756404225</a>