Looks a lot like PostgREST, but with more backends (not just postgres), fewer fancy features (joins? not mentioned here), and with the client-side code generator built in (typescript).
If the author is reading, assuming I'm using Postgres and typescript, in what situations would I choose this over PostgREST + any openapi code generator?
The difference between this and openapi code generator (I think) is that I made a few specific decisions in the builtin templates that help get internal business apps off the ground faster. But since it's designed around a template system you could do whatever you want with it. And of course openapi is much more mature just generally speaking.
It's different from PostgREST in that it doesn't dynamically read schemas from the DB during the application server runtime. You generate an application from the DB up front and then you can do whatever you want with that generated application afterward.
Interesting how many languages are in here, HTML/CSS/TS on the front-end is no surprise, Go on the generated back-end is a little less expected than full-stack Typescript. The fact that the tool itself is in F# is really interesting. I kind of expected it to be some combinations of the others.
This is really cool. Poking around the source code, it's surprisingly simple. It's just a database -> template engine with a front-end/back-end template included.
I would love if something like this existed except it used a .proto as the source of truth and had a way to provide ways to rename/query certain fields.
Would make it easy to replace shared DBs with APIs over time.
Real world CRUD is a bit different though, you want to send the log to somewhere else, use Sentry to try catch error in your CRUD endpoint. Or publishing a message to Kafka after u created an object. How to integrate "real world components" into this ?
The primary use case I had in mind for this was internal business apps.
But a few ways you could hook without any code changes in dbcore: use LISTEN/NOTIFY or equivalent to hook on changes, poll for changes in the DB, "eject" the generated code and edit API handlers directly to call where you want, or just edit the default templates directly with whatever API handlers you want to call.
It's true there's not a great way to add hooks at a configuration level at the moment. But there are still many ways you could work around that.
Not really in line with this particular CRUD subject, but combine-able esp. if things grow in size and scale: https://temporal.io provides a really nice way to code your workflows in Golang, applicable for small-scale, while hiding most complexity that come with scaling.
care to tell us what specific similarities you see between MS Access and this? I worked with Access and it had a few issues, it could be buggy and it did not support multiple users nor logins or sso.
I didn't meant to disparage the project. The comparison is because it does in the web basically the same thing that access provided: the ability for power users to build applications with minimal or absolutely no code given a physical data model.