SQL como API

Artículo original ↗ Discusión en Hacker News ↗

Usar SQL como límite público de API promete consultas potentes y flexibles para los clientes, pero plantea preguntas difíciles sobre seguridad, rendimiento y control de la complejidad. Los comentaristas comparan este enfoque con alternativas como DSL JSON personalizados, GraphQL, filtros de URL al estilo PostgREST y controles de acceso nativos de la base de datos (RBAC, seguridad a nivel de fila, timeouts), discutiendo cuánta capacidad deberían tener los usuarios y dónde hacer cumplir las restricciones. Muchos ven valor en lenguajes de consulta tipo SQL o subconjuntos limitados traducidos a SQL, pero las opiniones divergen mucho sobre si exponer SQL sin procesar en internet es alguna vez una buena idea.

Marco general

  • El hilo debate usar SQL (o algo parecido a SQL) como una API/lenguaje de consulta en lugar de estructuras de filtrado JSON a medida o endpoints REST.
  • Muchos ven esto como, inevitablemente, “inventar un lenguaje de consulta” de todos modos; la verdadera pregunta es: ¿cuál, y dónde hacer cumplir las restricciones?

SQL vs DSL personalizado / JSON / GraphQL

  • A favor de un subconjunto de SQL:
    • SQL es expresivo, muy conocido y naturalmente extensible; añadir más del lenguaje puede seguir siendo compatible hacia atrás.
    • Evita diseñar una estructura ad hoc que pueda romperse después o volverse difícil de evolucionar.
    • SQL local (p. ej., SQLite en el navegador/WASM) más sincronización puede difuminar los límites entre API y base de datos.
  • A favor de DSL / JSON:
    • Los formatos JSON/AST personalizados o lispy son más fáciles de analizar, comprobar tipos y transformar a SQL o a otros backends (p. ej., Elasticsearch).
    • Los DSL “que parecen SQL pero no son realmente SQL” pueden ser confusos; mejor ser explícito y estructurado.
    • Los estándares existentes (OData, JSON:API, AIP/CEL de filtrado de Google, lenguajes de expresión, Substrait) ya cubren muchas necesidades.
  • GraphQL recibe opiniones mixtas:
    • Algunos lo ven como equivalente a “empaquetar consultas” (resolviendo n+1/viajes de red).
    • Otros sostienen que principalmente es un lenguaje de composición de resultados, con poder de consulta limitado (sin uniones/recursión) y una gran sobrecarga de stack.

Seguridad, permisos y QoS

  • Preocupaciones: exponer SQL se califica de inseguro, difícil de mantener y arriesgado para el rendimiento (escaneos de tablas, DoS, superficie amplia).
  • Contraargumentos:
    • Las bases de datos modernas ofrecen RBAC, seguridad a nivel de fila, restricciones, vistas, timeouts, cuotas y limitación de tasa; todo esto puede acotar el daño.
    • Los timeouts de sentencias y los límites de recursos pueden frenar consultas patológicas.
  • Persiste el desacuerdo sobre si la seguridad a nivel de base de datos es más simple o más compleja que compilar un DSL restringido a SQL.

Experiencia de consulta orientada al usuario

  • Para usuarios no técnicos (p. ej., búsqueda de productos), SQL libre se considera demasiado difícil; los controles de la UI se mapean de forma natural a AND/OR/facetas simples.
  • Algunos profesionales informan que la lógica OR compleja en la búsqueda de productos rara vez se solicita; otros echan de menos con frecuencia una búsqueda booleana más rica en las herramientas.
  • Para usuarios avanzados (logs, auditorías, administración/informes), los lenguajes de consulta textuales (tipo SQL, Lucene, estilo JQL) se consideran muy valiosos.

Herramientas y patrones existentes

  • Ejemplos citados: PostgREST, APIs tipo SQL de grandes proveedores, los controles de ClickHouse, acceso público a Postgres de crt.sh y patrones de “envía la BD”.
  • Algunos sostienen que hacerlo “bien” se aproxima a lo que herramientas como PostgREST ya ofrecen; otros defienden implementaciones pequeñas y específicas del contexto.