Using Go at Meli: ORM or !ORM
Esta é a segunda história da série “Golang: ORM or not ORM at Mercado Libre”. Aproveite!
No primeiro artigo desta série, “Go Language, Relational Databases and ORM”, fizemos uma breve introdução aos principais conceitos da linguagem Go, bancos de dados relacionais, ORMs e também pacotes que permitem trabalhar com dados com a linguagem Go. Esses conceitos nos ajudarão neste segundo artigo da série, permitindo que nos concentremos em compartilhar nossa experiência com a avaliação do uso desses diferentes pacotes e observações sobre nosso ambiente no Mercado Livre.
Mas e se “começamos do início”… Ramp-ups são tarefas que um novo desenvolvedor do Mercado Livre enfrentará e consistem em implementar um aplicativo simples que permita ter contato com a maioria das experiências do dia-a-dia, como detalhamos aqui. Durante meu ramp-up pessoal, analisei algumas alternativas e PoCs para responder à pergunta: ORM ou não ORM. Concentrei-me em 3 conceitos simples para guiar este trabalho:
- a resolução da tarefa,
- o conhecimento da equipe para a implementação,
- o resultado obtido.
Com base na minha experiência, acabei implementando-o usando database/sql (SQL puro), pois tenho conhecimento de SQL e é bem simples usá-lo em Go. No entanto, considerando que existem outras formas de lidar com o mesmo problema e que muitas pessoas vão enfrentar esse problema novamente depois de mim, quero compartilhar a pesquisa com você.
Analisando os nossos repositórios GitHub de produção escritos em Go, encontramos os pacotes mais usados que resolvem nosso problema. Vamos verificar o gráfico:
Não podemos nos limitar ao uso e conhecimento de um determinado conjunto de ferramentas, mas sim, estar dispostos e aptos a entender a solução existente, suportando-a ou até mesmo possibilitando melhorias pontuais e otimizações se necessário.
Demonstrando a importância de ter uma visão agnóstica de implementação, durante o período de concepção e revisão deste texto, tivemos contato direto e indireto com diferentes abordagens de solução:
- Projetos utilizando SQL puro em sua implementação, o que nos deu vantagens na interpretação, compreensão e análise do relacionamento das tabelas devido ao acesso direto aos códigos SQL presentes;
- Reuniões para entender o projeto de outra equipe que utilizou o GORM, migrando um módulo existente.
Análise
Existem fatores importantes a serem considerados antes de tomar algumas decisões sobre um projeto, como:
- o conhecimento em POO ou SQL (lembra-se que mencionamos anteriormente as preferências de cada equipe?),
- o lead time de um MVP,
- as prioridades sobre: 1. disponibilidade ou tempo de atividade; 2. integridade ou consistência; 3. garantia de entrega; 4. throughput/latência/tempo de resposta.
Os ORMs podem ajudar durante o desenvolvimento e existem muitas possibilidades diferentes, algumas das quais são fáceis e outras não. Alguns deles funcionam para casos de uso específicos e outros são mais flexíveis. E, finalmente, também existem alguns híbridos onde você pode fazê-lo funcionar com consultas SQL e um pouco de "mágica" no código.
O importante aqui é que em todos esses cenários você precisará de um grande conhecimento da ferramenta e de todos os recursos que ela possui, e por que não, cenários híbridos com algumas consultas SQL e um pouco de "mágica" também. Mas você sempre precisa de um conhecimento profundo da ferramenta e de todos os seus recursos.
Abaixo, apresentamos duas listas com prós ( ✅) e contras ( ❌) ao adotar SQL puro ou um ORM.
SQL puro
✅ É mais eficiente em tempo de execução
✅ SQL é uma linguagem padrão que é muito útil conhecer
✅ É um padrão na comunidade Go
❌ Apresenta o desafio de gerenciar muitas consultas e aumenta os esforços de manutenção
❌ Leva tempo para escrever instruções SQL simples para fazer operações CRUD básicas para cada modelo de dados
ORM
✅ Melhora a velocidade de desenvolvimento
❌ É menos performático (leia você mesmo ou veja este pequeno benchmark)
❌ É muito invasivo e “mágico” (a comunidade Golang não gosta muito disso)
Conclusão
Considerando todos os pontos que discutimos, seria um pouco inconveniente dizer que usar ou não um ORM para uma determinada solução é sempre o caminho correto. Como desenvolvedores, precisamos sempre avaliar, verificar e atualizar nossos conceitos e conhecimentos, compartilhando-os com as demais equipes e (por que não?) com a comunidade.
Reserve alguns momentos para responder a algumas perguntas sobre se seria conveniente adotar SQL puro ou qualquer um dos ORMs possíveis:
- Quantas vezes a equipe de desenvolvimento teve contato com determinada ferramenta?
- Esta escolha dará uma vantagem clara para desenvolver a solução e obter melhores resultados de negócios?
- Quais escolhas você faria? Desempenho de tempo de execução, qualidade 5 estrelas ou manutenção de baixo esforço?
- Como isso afetará a experiência do usuário? Afinal, nosso objetivo é criar ótimas experiências de usuário.
Lembre-se que se considerarmos apenas as características da linguagem Go descritas na primeira história desta série, teríamos como adoção natural o uso de código SQL puro (sem usar nenhum ORM) porque é o que consta na documentação e é bastante simples, mas nós, como engenheiros de software, devemos tomar decisões considerando muitos outros fatores, e cada pessoa, cada projeto ou empresa tem restrições diferentes.
Before finishing this episode of the series “Golang: ORM or not ORM at Mercado Libre”, gostaria de lhe convidar a compartilhar sua experiência deixando um comentário abaixo. Isso enriquece a comunidade como um todo. Vamos compartilhar conhecimento e coisas boas.
Ansioso pela próxima história? Comece a ler “Code Ecosystem — Improving the development experience”!
References
sql — database/sql: https://pkg.go.dev/database/sql
Go — Accessing relational databases: https://go.dev/doc/database/
ksql : https://github.com/VinGarcia/ksql
Comparing SQL, Query Builders and ORMs : https://www.prisma.io/dataguide/types/relational/comparing-sql-query-builders-and-orms
Go Proverbs : https://go-proverbs.github.io/
