Pitch: desenvolvi um editor de SQL que roda no navegador — compartilho 3 coisas que quebraram nesta jornada

Estou construindo um treino de SQL para quem vai encarar etapa técnica em processo seletivo. A ideia central era simples: em vez de questão de múltipla escolha, a pessoa escreve a query e roda de verdade. Sem instalar banco, sem configurar nada.
Quero dividir três decisões técnicas e os bugs que cada uma trouxe, porque aprendi mais com eles do que com o que deu certo.

1.) SQLite em WebAssembly, dentro de um Web Worker
O editor usa o sql.js — o SQLite compilado para WASM — rodando num Web Worker. O banco é criado em memória, a query roda ali mesmo, e o servidor nunca vê o que a pessoa digitou.
O Worker existe por um motivo prático: uma query pesada (ou um produto cartesiano sem querer) na thread principal congela a aba inteira. Isolada no Worker, a interface continua respondendo.

2.) Validar pelo resultado, não pelo texto da query que foi digitada
Comparar a query digitada com um gabarito não funciona: ‘WHERE salario > 9000eWHERE 9000 < salario’ são a mesma resposta escrita de jeitos diferentes. Então a correção não olha o texto digitado: ela executa a query da pessoa e compara o resultado com o resultado esperado da questão.
O problema aparece com dataset pequeno: query errada pode devolver o resultado certo por coincidência. Um JOIN e um LEFT JOIN dão exatamente o mesmo resultado se nenhum funcionário estiver sem departamento. A saída foi desenhar os dados de propósito com casos de borda — um funcionário sem departamento, um nome com espaço sobrando no final, maiúsculas e minúsculas misturadas — para que o erro mais provável de cada questão produza um resultado diferente.

3.) Magic link quebrava; troquei por código — e quebrou de novo
Login sem senha por link mágico parece ótimo até alguém abrir o e-mail no app do Gmail. O Supabase usa PKCE: o navegador que pediu o link guarda um code_verifier, e só ele consegue completar o login. Se o link abre no navegador embutido do app de e-mail, o verifier não está lá — e a pessoa vê "link inválido".
Troquei por um código numérico digitado na mesma página. Achei que tinha resolvido. Na primeira compra real de teste, o login quebrou de novo: o signInWithOtp usa um template de e-mail quando o usuário já existe e outro — o de confirmação de cadastro — quando o usuário é novo. Eu só tinha customizado o primeiro. Todo comprador novo recebia o template padrão, em inglês, com link… e caía no mesmo bug do PKCE.
A correção estrutural foi criar o usuário no Auth no momento da compra, pelo webhook. Assim ninguém chega ao primeiro login como usuário novo, e a bifurcação de template deixa de existir para quem pagou.

Se quiser/puder testar:

Montei um desafio aberto, sem cadastro, com o editor funcionando: https://sqlreps.com/desafio?g=tabnews

É uma questão só, de nível de entrada. O projeto completo é pago (30 questões, R$ 37), mas o desafio é grátis e não pede nada.

O feedback que mais me ajuda agora é sobre a experiência do editor no celular — é onde tenho duvidas se esta profissional.

Se você já manja de SQL, mas conhece alguém se preparando para entrevistas, esse desafio pode ser útil para essa pessoa.