SQL como API

Artigo original ↗ Discussão no Hacker News ↗

Usar o próprio SQL como fronteira pública de API promete consultas poderosas e flexíveis para clientes, mas levanta questões difíceis sobre segurança, desempenho e controle de complexidade. Os comentaristas comparam essa abordagem a alternativas como DSLs JSON personalizadas, GraphQL, filtros de URL no estilo PostgREST e controles de acesso nativos do banco (RBAC, segurança em nível de linha, timeouts), debatendo o quanto de poder os usuários devem ter e onde impor restrições. Muitos veem valor em linguagens de consulta semelhantes a SQL ou subconjuntos limitados traduzidos para SQL, mas as opiniões divergem fortemente sobre se expor SQL bruto na internet é alguma vez uma boa ideia.

Enquadramento geral

  • O debate gira em torno de usar SQL (ou algo parecido com SQL) como uma API/linguagem de consulta, em vez de estruturas de filtro JSON personalizadas ou endpoints REST.
  • Muitos veem isso como, inevitavelmente, “inventar uma linguagem de consulta” de qualquer forma; a verdadeira questão é: qual, e onde impor restrições?

SQL vs DSL personalizado / JSON / GraphQL

  • Subconjunto pró-SQL:
    • SQL é expressivo, conhecido e naturalmente extensível; adicionar mais da linguagem pode continuar compatível com versões anteriores.
    • Evita projetar uma estrutura ad hoc que pode quebrar mais tarde ou ficar difícil de evoluir.
    • SQL local (por exemplo, SQLite no browser/WASM) mais sincronização pode borrar as fronteiras entre API e banco de dados.
  • Pró-DSL / JSON:
    • JSON/AST personalizado ou formatos lispy são mais fáceis de fazer parsing, validar tipos e transformar em SQL ou em outros backends (por exemplo, Elasticsearch).
    • DSLs “parecem SQL, mas não são SQL de verdade” podem ser confusos; melhor ser explícito e estruturado.
    • Padrões existentes (OData, JSON:API, o AIP/CEL de filtragem do Google, linguagens de expressão, Substrait) já cobrem muitas necessidades.
  • GraphQL recebe avaliações mistas:
    • Alguns o veem como equivalente a “empacotar consultas” (resolvendo n+1/idas à rede).
    • Outros argumentam que ele é principalmente uma linguagem de formatação de resultados, com poder de consulta limitado (sem uniões/recursão) e alto overhead de stack.

Segurança, permissões e QoS

  • Preocupações: expor SQL é descrito como inseguro, difícil de manter e arriscado para desempenho (table scans, DoS, superfície ampla).
  • Contra-argumentos:
    • Bancos modernos oferecem RBAC, segurança em nível de linha, restrições, views, timeouts, quotas e rate limiting; isso pode limitar os danos.
    • Timeouts de instrução e limites de recursos podem conter consultas patológicas.
  • A discordância persiste sobre se a segurança no nível do banco é mais simples ou mais complexa do que compilar um DSL restrito para SQL.

Experiência de consulta voltada ao usuário

  • Para usuários não técnicos (por exemplo, busca de produtos), SQL em texto livre é visto como difícil demais; controles de UI se mapeiam naturalmente para simples AND/OR/facetas.
  • Alguns praticantes relatam que lógica OR complexa em busca de produtos raramente é solicitada; outros sentem falta com frequência de busca booleana mais rica em ferramentas.
  • Para power users (logs, auditorias, admin/relatórios), linguagens de consulta textuais (estilo SQL, Lucene, JQL) são consideradas muito valiosas.

Ferramentas e padrões existentes

  • Exemplos citados: PostgREST, APIs com aparência de SQL de grandes fornecedores, os controles do ClickHouse, acesso público a Postgres do crt.sh e padrões “ship the DB”.
  • Alguns argumentam que fazer isso “direito” se aproxima do que ferramentas como o PostgREST já fornecem; outros defendem implementações pequenas e específicas ao contexto.