This is really interesting. Do you have any intention (or are you open) to add SQLite as a supported DB?
Yeah, working on that next for simple automated tests in particular. It’s got a bunch of odd quirks so it’s taking a bit longer to support than MySQL or Postgres.
It’s in now!
Awesome! Cheers for letting me know!
This looks great. I see (and understand) there’s very limited authorization - is there a plan for how to handle that (ie user1 and user2 have access to the To-do app - but should not be able to see/edit each other’s todo’s). That the generated gui is a bit of an “admin party” is probably ok - but for using the Api there probably needs to be a sane path for doing some authz?
I suppose for postgres one could go for different schemas and roles, possibly with a shared read schema for some common stuff - or go with row level security (probably better).
The template for the UI right now is more of an admin template, for sure. I’m thinking of another user-oriented template where the UI only generates pages that have a foreign key in the users table, and would filter implicitly on the current user within all these tables.
Regarding authorization, I’m still sketching it out but I’m thinking of optional per-endpoint/method filters specified in configuration that you can write to include the current session info and the current table being queried. Here is the sketch.
I wish you could squeeze metadata into the db but the COMMENT field doesn’t seem like the right way to go.
I would personally prefer something built-in with an eye towards authorization (ie roles/schemas or row level security).
Sadly it seems the only other free/open db with support is hsql:
And as far as I can figure out there’s not quite any one true way, although the approches aren’t that different for eg pg and ms sql:
Hsql looks a bit different :
Anyway, not suggesting you abandon mysql and sqlite for this.
It’s more that I’d just love rad framework that allowed a sane path from prototyping to deployment. I’m not entierly convinced an ad-hoc solution would be the best idea - it’s far too easy to end up choosing between reasonable performance and reasonable security (no access except for explicit grants).
Maybe adding a nullable role_id to all tables, and use a stored procedure for filtering access - along with a user/role table… But this quickly sounds like it’d get complicated (say, separate roles or columns for select/update/insert/delete?)…
Maybe it would be feasible exposing via views only. Eg:
Select from table1 where can_select(uid, table1.role_id) = true;
And can_select looks up user role membership along with rôle rights on table1…
But sounds like that would be very tricky to use more generally (when you need to aggregate and/or join…).