Hacker News new | ask | show | jobs
by bsaul 2346 days ago
i was stunned the first time i saw web frameworks like django and symfony automatically build a full featured admin panel based on model's definition.

I wonder if there aren't projects aimed a building just an administration GUI based on SQL introspection mixed with simple configuration files. Just point at a db, and there you go.

Side note : what is the current state of codegen based on api and model specifications ? I feel like 90% of most projects could be automatically generated just based on that.

7 comments

> building just an administration GUI based on SQL introspection

I built exactly this. The idea was to make databases look and feel like a file manager where databases are shown as folder, tables as subfolders and rows are shown as files that once open shows a fully editable form that look like this: https://archive.kerjean.me/public/2020/screenshot_20200117_2... It understands foreign keys and create relevant links to easily navigate through. The entire code is there: https://github.com/mickael-kerjean/filestash

very nice !

As an advice from a marketing POV : i wouldn't start by explaining that it lets you navigate ftp servers using file abstraction. This is very confusing, because most people already access ftp servers using tools like filezilla clients that do exactly that.

The db -> file browser is a very interesting idea that i think should stand on its own (even if the underlying tech is similar).

> I built exactly this. The idea was to make databases look and feel like a file manager where databases are shown as folder, tables as subfolders and rows are shown as files that once open shows a fully editable form ... It understands foreign keys and create relevant links to easily navigate through.

I thought that was the whole point of e.g. LibreOffice Base and the like? (including Paradox, Access, etc.) So you built a web-based clone?

> So you built a web-based clone?

It's more of an elaborate answer to the infamous ftp comment from when Dropbox did launch in 2007 here on HN (https://news.ycombinator.com/item?id=8863). At its root, the project tries to solve the Dropbox problem by abstracting the storage aspect so that you can bring your own backend by implementing a simple interface.

The mysql plugin is just an implementation of that model to enable non nerds to crud a database without braking anything. I did a few one of those implementations: FTP, SFTP, S3, ... Mysql is just one of those "for the sake of science" one to be put in the same bag as the LDAP one: https://www.filestash.app/ldap-browser.html

There's plenty of database administration tools that do just that. I guess they could use work in the UX department to make it more user friendly though.

But beyond pure data access you'll want features like access rights (SQL servers will offer that to a point), validations, and data/context specific visualizations.

For my current project, we're auto-generating a relatively full-featured CRUD interface with granular access controls and the works. [one detail to add there is that while it's primarily used as an admin interface now, it's not meant to be restricted to that - it has access control and workflow support built in that we're building product flows on, where the UI is still generated the same way]

It's not just from the SQL, but we use Sequel (Ruby ORM) to introspect the DB as a starting point, coupled with a plugin to Sequel that lets us annotate the models to provide more precise information that our Sinatra based API introspects to return JSON data to our React frontend that drives how the UI is presented. This extends to e.g. declaring which fields are most useful for users to search for relations that should be linked via foreign keys, for example (e.g. users are linked to by id, but when linking a user from another record, they are searchable by name and e-mail). As much as practical we auto-generation validations etc. from the database schema as well.

I think doing this by SQL alone would be quite painful unless you sacrifice usability, because a typical database schema has too little information on how users think about the data.

E.g. we dialled back on using Postgres enum types because they're annoying to update and deal with if you frequently update the allowed values - but you need relatively little extra config to be able to generate very full-featured interfaces, and you can make most of that extra information entirely declarative. Foreign keys is another issue, as described above - a normal database schema just tells you how things are linked together, not how users would like to see it. E.g. knowing a comment was written by user 42 is much less useful than knowing it was written by bob@example.com; to allow user-friendly linking etc. you'll want more information. We refer to our additional layer of information about the structure of our data as our meta schema.

You certainly could put the parts that don't fit perfectly in your database schema in your database anyway as regular data, and to some extent we do - e.g. the meta information that we augment our Sequel model classes with can be overridden by rows in a table.

But the main reason we've not fully embraced that vs. annotating the model classes in code is that it makes version control painful, and if you update it with migrations it's really not saving that much vs. just putting it in the model classes (this might be different if you have other applications accessing the database and the database in effect needs to be a versioned API in itself accessible by multiple consumers, but in this case all the database access happens via the API exported from the model classes).

There are a lot of headless CMS which assists with the creation.
I think forestadmin.com / jetadmin.io are the SQL introspection equivalent of the Django Admin. Both are commercial products though.
Yes yazz Pilot lets you build an admin panel by pointing at a dB and then it queries the database tables which you select visually
Metabase?