Developer Tool · 2026 · Solo build
Query Slice
Every JOIN, predicate, and output column in your SQL query — anatomised in one click, without leaving the browser.
The problem
Developers inheriting a complex multi-table query — in a code review, a post-mortem, or an optimisation session — face a dense wall of SQL that they must mentally parse before they can reason about it. Standard database IDEs show query plans after execution, not structural anatomy at a glance. Query Slice fills that gap: paste any SQL SELECT and get an instant breakdown — CTEs extracted and labelled, the primary table identified, every JOIN typed and its ON condition isolated, every WHERE/HAVING predicate extracted and its column/operator/value split out, every output column named and aliased. All logic runs in the browser; nothing is sent to a server. A complexity score (weighted by JOIN count, predicate count, and CTE depth) gives a single-number cognitive-load signal.
Architecture
Key decisions
Command / Inspect surface — not Compare or Configure
The user is drilling into one SQL artefact to understand its structure — not comparing two queries side-by-side and not setting parameters. The Command/Inspect surface means: density and focus over breadth, monospace type for SQL tokens, left-aligned inspector panels grouped by semantic category (CTEs, primary table, JOINs, predicates, outputs), and a top stat-bar showing the four key counts at a glance.
Paren-balanced CTE scanner instead of regex lookahead
Multi-CTE SQL like WITH a AS (...), b AS (...) SELECT ... fails with a simple header-to-SELECT regex because the inner SELECT keywords inside each CTE body trigger a premature stop. The paren-balanced scanner advances a depth counter through each CTE body and only advances to the next name once the closing ) is matched — making it correct for arbitrarily nested CTEs without a full parse tree.
TDD-first pure logic module
All 31 tests across normalizeSql, extractCTEs, extractSelectOutputs, extractFromTable, extractJoins, extractPredicates, computeComplexity, and parseQuery were written before lib/sql-parser.ts existed. The Red phase caught the multi-CTE extraction bug (single CTE returned instead of two) before implementation ran. The pure module has zero React or Next.js imports.
No external SQL parsing libraries
A full SQL parser (node-sql-parser, pgsql-ast-parser) would handle every dialect edge case but adds bundle weight and opaque failure modes. The regex-based approach is intentionally bounded: it handles the common multi-table SELECT pattern, extracts the structurally important parts, and degrades gracefully on unusual syntax rather than throwing. The algorithm is the artefact.