park-bit/sqlide

1. Overall shape

SQLide is a client-side, browser-only SQL workbench. There is no traditional backend service in this repo; the app’s core runtime is React in the browser, with database execution handled locally through SQLite compiled to WebAssembly.

2. Application bootstrap

src/main.tsx is the entry point that mounts the React app into index.html. The app is built with Vite, so the browser receives a static frontend bundle plus static assets from public/.

3. Top-level UI shell

src/App.tsx acts as the main page composition layer. It likely lays out the editor, results, schema browser, table viewer, and ER diagram into a dashboard-style workspace, while also handling cross-panel coordination through shared state.

4. Shared coordination layer

src/SqlContext.tsx is the main architectural boundary for state and actions. It centralizes the in-memory SQLite database instance, query execution, schema metadata, and any derived state consumed by the rest of the UI. This keeps the panels loosely coupled and prevents each component from managing its own database connection.

5. Local database engine

The database is powered by sql.js, with the WebAssembly binary stored at public/sql-wasm.wasm. Queries run entirely in the browser against an in-memory SQLite database, which is the key local-first design choice and the main data-processing subsystem.

6. Query authoring

src/SqlEditor.tsx is the code entry surface, backed by Monaco Editor according to the README. Its role is to accept SQL, support editor conveniences like autocomplete and formatting features, and submit statements into the shared SQL context for execution.

7. Result presentation

src/ResultPanel.tsx renders query output and execution feedback. This is the primary sink for SELECT results, execution errors, and likely other run metadata. It depends on the shared context rather than querying the database directly.

8. Schema exploration and table browsing

src/SchemaExplorer.tsx and src/TableDataViewer.tsx are read-only inspection surfaces for the current database. The schema explorer is for tables/views/columns, while the table viewer is for row-level inspection. Both consume the same context-derived metadata and database state.

9. Relationship visualization

src/ERDiagram.tsx visualizes table relationships based on schema metadata and foreign key detection. It is another consumer of the shared database context, transforming relational metadata into a graph-like UI for understanding schema structure.

10. Session-level external dependency

The README mentions a Kanye quote fetched from an external REST API at session start. Architecturally, this is a non-core, optional network dependency that sits outside the database path and does not affect query execution.

11. Static assets and styling

Presentation is implemented with CSS in src/App.css and src/index.css, plus SVG/icon assets under src/assets and public/. The app is styled as a polished single-page workbench rather than a server-rendered product.

12. Build and deployment boundary

vite.config.ts and the TypeScript config files define the frontend build pipeline. vercel.json indicates static deployment on Vercel, which fits the app’s architecture: compiled assets are hosted, while all SQL execution remains in the browser.

13. Persistence and portability model

The system is designed for local memory-first use, with import/export support for .sqlite files and CSV/JSON result export as described in the README. That means persistence is user-managed and file-based, not server-backed.

14. Diagramming the main dependency flow

For an architecture diagram, the central path is: React bootstrap → app shell → SQL context → sql.js/WASM database → derived consumers. The UI panels are dependent views of the same local database state, not separate services.