rezwanul-haque/bytetable

1. Overall shape

ByteTable is a desktop application built as a Tauri 2 shell with a Rust backend and a React + TypeScript frontend. The app runs locally only; all database access happens in the Rust side, while the webview is responsible for UI, state, and user interaction.

2. Primary process boundary

The most important architectural boundary is between renderer and core. In the renderer (src/), feature modules call typed API wrappers that invoke Rust commands. In the core (src-tauri/src/), Tauri command handlers perform the actual I/O, business rules, and engine-specific logic. This boundary is also security-sensitive: the renderer sees opaque connection ids, not raw secrets or driver credentials.

3. Renderer composition

The UI is organized by feature slices rather than by technical layer. src/features/* contains the app’s main screens: workspaces, SQL browsing, Redis browsing, DynamoDB browsing, MongoDB browsing, Cassandra browsing, settings/preferences, schema maps, import/export, generate-data, saved queries, console/terminal, updater, and connection management. src/shared/* holds cross-cutting UI primitives, themes, and shared API/types.

4. Workspace shell

The app’s main interaction model is multiple workspaces in one window. The workspace shell provides the left rail, sidebar, tab bar, status bar, command palette, and docked terminal panel. Each workspace maintains its own connection context and tab state, so the UI is not a single global browser; it is a multi-session desktop workspace.

5. SQL subsystem

The relational path covers SQLite, MySQL, and PostgreSQL. On the renderer side this includes the data grid, SQL editor, filters, structure view, inline cell editing, foreign-key peek, column insights, explain panel, export dialogs, schema map, and mutation flows. On the Rust side, engine adapters under src-tauri/src/engines/{sqlite,mysql,postgres} provide the actual database access and type mapping.

6. Non-relational engine subsystems

Each non-SQL engine has its own purpose-built surface rather than being forced into the SQL grid model:

- Redis: keyspace browser with db switching, SCAN-based listing, type-aware value editors, and dashboard.

- DynamoDB: table-centric document/single-table workflow with scan/query, PartiQL, item editing, import/export, and schema map.

- MongoDB: collection/document workflow with find, aggregation pipeline, JSON editor, explain, shell, structure, and schema map.

- Cassandra: query-first wide-column workflow with consistency settings, CQL builder, structure view, shell, and denormalized schema map.

These differences are reflected both in the renderer folder structure and in the Rust engine adapters/ports.

7. Rust core layering

The backend follows a vertical-slice + clean architecture style. Each feature under src-tauri/src/features/<slice> is split into domain/application/ports/infrastructure/commands where needed. The command layer is thin and acts as the Tauri boundary; application/domain code holds use-case logic; infrastructure contains adapters such as local storage, keychain access, and DB integrations.

8. Engine ports and adapters

The core uses shared port traits in src-tauri/src/shared to keep engine-specific implementations isolated. There are separate port families for SQL, key-value, document/Mongo, DynamoDB document, and wide-column/Cassandra models. Concrete driver integrations live in src-tauri/src/engines, including rusqlite, sqlx, redis, aws-sdk-dynamodb, mongodb, scylla, plus SSH tunneling support in ssh.rs.

9. Connection and secret management

Connection setup is its own subsystem with a clear privacy boundary. The renderer has a connection modal and connection state, but secrets are handled by the Rust side and stored in the OS keychain. The app also supports SSH tunneling, TLS, and engine-specific connection options; this is why the connection feature is separated from browsing/query features.

10. Cross-cutting utility features

Several features are shared across engines or screens:

- Preferences/Settings: theme, font, density, and behavior toggles persisted locally and reflected through CSS variables.

- Saved queries: global or workspace-scoped query storage.

- Schema maps and exports: visual diagrams plus PNG/SVG/CSV/JSON/SQL export paths.

- Generate / Import / Export / Mutate: data generation, schema/data transfer, and write operations with confirmations.

These are separate slices because they operate across multiple data models rather than belonging to one engine.

11. Terminal and shells

The docked terminal panel is a shared runtime surface, but it is engine-aware: SQL engines use psql/mysql/sqlite-style shells, Redis uses redis-cli, MongoDB uses mongosh, Cassandra uses cqlsh, and DynamoDB uses PartiQL. This terminal subsystem is distinct from the structured browse/editor flows and acts as a lower-level escape hatch.

12. Testing, fixtures, and delivery

The repository includes a Docker-backed test-fixtures/ environment for seeded databases across supported engines, plus Rust integration tests and frontend type/lint checks. Packaging is handled through Tauri release builds and platform-specific installers, with GitHub Actions workflows for CI, Pages, and releases. The docs folder contains feature-spec documents that map closely to the implemented slices and are useful for understanding intended boundaries.