Mais um caso em que HoneySQL me deixou na mão

[wandersoncferreira]

Quando iniciamos um projeto na empresa em Setembro/2020 o time logo começou as discussões sobre HoneySQL e se deveria utilizar ou não. Acordamos em utilizar, pois bem. Os primeiros 6 meses de vida do App foram bem tranquilos até que novamente as coisas começam a se complicar.

1. Em pelo menos uma dúzia de vezes, tinhamos uma query SQL que funcionava perfeitamente em algum client e o dev estava com dificuldades em traduzir para a estrutura do honeysql.
2. Uma funcionalidade nova acabou obrigando o time a escrever diversas queries como CTEs (Common Table Expressions) e as estruturas em honeySQL eram bem tensas de ler comparado com SQL puro
3. "Vantages" de manipular estruturas de dados para criar queries dinamicamente frequentemente se transformaram em fontes de maior complexidade no código do que vantagem em si. Carga cognitiva para ler/interpretar os códigos foram bem maiores
4. No meio do caminho o Sean lança o honeySQL 2 e agora o time está preocupado se vai ser ok se manter no honeySQL 1.

Semana passada um novo projeto começou e dessa vez o HugSQL foi escolhido em unânimidade.

[wandersoncferreira]

Um dos principais motivos que o pessoal acabava com uma query para traduzir para honeySQL é que o desenvolvimento da query em si é feito de forma interativa conectado com algum cliente do banco de dados e.g. dBeaver, Datagrip, etc. O que também é possivel de ser feito via código, porém nesses clientes é muito mais fácil explorar as demais tabelas do banco, relacionamentos, restrições, etc e não precisa ficar indo e voltando da sua IDE para lá enquanto faz isso.