DBFirstDataGrid
Database metadata turned into tables, forms, filters, and nested grids.
DBFirstDataGrid is a full-stack equipment management dashboard where the server inspects database schema and the frontend builds useful CRUD UI from the returned field descriptors.
What it solves
Admin dashboards often repeat the same table headers, form inputs, dropdowns, validators, and CRUD calls for every database table.
DBFirstDataGrid shifts that repetition into metadata. The backend describes tables and fields; the frontend renders the grid, edit forms, add modal, distinct-value dropdowns, and nested subgrids from that contract.
Orders grid with schema-driven columns
Who this is for
- Teams building internal equipment or operations dashboards
- Developers who want metadata-driven CRUD instead of repeated forms
- Projects where relational subgrids matter to the workflow
- People comparing SQLite local dev and MySQL production paths
What it does
The Express server inspects table columns at runtime and returns typed field descriptors. The React frontend uses those descriptors to build table headers, field labels, input types, dropdowns, paginated data views, and add/edit flows without hardcoded field knowledge.
The grid supports nested subgrids such as order items inside orders. It can switch between SQLite for local development and MySQL for production while keeping the UI contract consistent.
Workflow covered
- Read schema - validate table names, inspect columns, infer field behavior, and return metadata to the UI.
- Render operations UI - build grids, add/edit forms, dropdowns, and recursive subgrids from descriptors.
- Mutate safely - run create, update, and delete operations through allowlisted identifiers and parameterized values.
Technical highlights / stack
Why it matters
This project follows the same pattern as QMK Nexus: keep the underlying system honest, expose the right metadata, and let the interface guide users through a complex domain without hiding important constraints.
Technical notes
Hard parts
- Exposing arbitrary database columns without creating SQL injection paths.
- Rendering nested relational data without hardcoded table-specific components.
- Keeping SQLite and MySQL behavior compatible across development and production.
- Writing reliable tests against live database behavior without flaky shared state.
Engineering takeaways
- Schema-driven UI needs a precise server/client contract or the UI becomes ambiguous.
- Identifier allowlisting is required whenever SQL structure is dynamic.
- In-memory SQLite keeps tests fast, but schema parity must be protected.
- Containerizing both database paths early prevents environment-only surprises.
Current scope
Works now
- Paginated rows
- Add record modal
- Inline update/delete flow
- Recursive subgrids
API
GET /fetchGET /fetchFieldsGET /fetchDistinctPUT /addPATCH /updateDELETE /delete
Still improving
- Field naming conventions
- Migration coverage
- Relationship metadata depth
- Production polish
Related work
What to do next
Open the demo or source if you want to inspect the metadata contract, recursive grid behavior, CRUD API, and database safety boundaries.