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.

DBFirstDataGrid orders screenshot 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

  1. Read schema - validate table names, inspect columns, infer field behavior, and return metadata to the UI.
  2. Render operations UI - build grids, add/edit forms, dropdowns, and recursive subgrids from descriptors.
  3. Mutate safely - run create, update, and delete operations through allowlisted identifiers and parameterized values.

Technical highlights / stack

Frontend
React 17 JavaScript Recursive components
Backend
Express 4 Node.js ES Modules
Storage
SQLite MySQL In-memory test DB
Environment
Podman Podman Compose Server tests

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

Schema contract Field descriptors carry labels, input types, dropdown behavior, and relationship hints to the frontend.
Identifier safety Dynamic table and column names require allowlists and regex validation; value parameters alone are not enough.
Recursive subgrids Orders and order items can nest without the grid knowing the relationship shape ahead of time.
Dialect boundary SQLite and MySQL differences stay behind a query layer so local development can match production behavior.

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 /fetch
  • GET /fetchFields
  • GET /fetchDistinct
  • PUT /add
  • PATCH /update
  • DELETE /delete

Still improving

  • Field naming conventions
  • Migration coverage
  • Relationship metadata depth
  • Production polish

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.