Engenharia de backend Go na Trust Wallet: integrações multi-chain

O problema: redes diferentes, comportamentos externos diferentes

No PR #698 do blockatlas, novas instâncias de Blockbook haviam mudado os campos de resposta consumidos pela integração Bitcoin. Adicionei suporte às duas versões de resposta. O código aceitou listas de transações em transactions ou txs, selecionou valueOut quando value estava ausente e leu endereços de saída tanto de um campo direto quanto de scriptPubKey. Eram diferenças concretas de compatibilidade em um serviço externo que o backend da carteira precisava normalizar.

Os helpers de normalização mantinham consistente a representação usada pelo adaptador enquanto tratavam a variação dos dados externos. O trade-off era a manutenção de lógica adicional de parsing: a compatibilidade agora incluía mais de uma organização de campos. Exigir que todas as instâncias externas usassem um único formato simplificaria o adaptador, mas eliminaria a compatibilidade que essa mudança buscava preservar. Essa distinção importa quando um backend integra sistemas com cronogramas de upgrade separados.

RPC em lote reutilizável

O PR #891 adicionou um método de lote ao cliente JSON-RPC compartilhado. Ele enviava uma coleção de requisições em um único POST HTTP e decodificava uma coleção de respostas. A mudança também acrescentou testes dos valores padrão de versão JSON-RPC e identificadores de requisição. JSON-RPC é o formato de requisição usado nessas chamadas aos nós; o lote reúne várias operações em uma única requisição.

O PR #892 aplicou esse método ao adaptador Zilliqa. Antes, a busca de transações iniciava uma goroutine para cada hash e reunia os resultados com um canal e um wait group. A substituição montava requisições GetTransaction a partir dos hashes do bloco, enviava todas juntas e convertia as respostas decodificadas para o tipo de transação do adaptador. Um bloco vazio retornava sem executar a chamada em lote.

O trade-off do processamento em lote

A mudança Zilliqa substituiu chamadas concorrentes separadas por uma requisição em lote, removendo a coordenação de goroutines e canais do adaptador nessa operação. Isso trocou o gerenciamento local de concorrência pela dependência do suporte a lotes no endpoint do nó. A implementação não introduziu limites de tamanho de lote nem uma política completa de novas tentativas por item; respostas que não podiam ser decodificadas eram ignoradas. Menos requisições também não comprovam redução de latência ou ganho de throughput sem medir o comportamento do endpoint e o volume das respostas.

Visibilidade HTTP

O PR #372 adicionou instrumentação HTTP e uma rota de métricas. Seu código definiu contadores de requisições de saída e histogramas de duração, adicionou middleware de servidor e conectou um handler Prometheus à API. Prometheus é o sistema de coleta de métricas escolhido nessa implementação. A rota também incluía verificação opcional de bearer token quando um token estava configurado. A descrição do PR apontava a falta de visibilidade de requisições recebidas e enviadas como o problema.

Os contadores e histogramas de duração disponibilizaram volume e tempo de requisições para um coletor de métricas. Isso complementava o trabalho dos adaptadores: normalização e execução de requisições tratam o movimento dos dados, enquanto a instrumentação fornece observações sobre o caminho HTTP. Expor essas medidas fornece a base para monitoramento; o PR em si não descreve uma política de alertas nem quantifica melhorias operacionais.

Escopo das contribuições

Essas quatro contribuições integradas conectam três preocupações recorrentes de backend Go: modelos de dados compatíveis, I/O externo e observabilidade. O ponto comum é a fronteira de integração, onde diferenças entre sistemas externos precisam se transformar em dados e operações utilizáveis pela aplicação. Os PRs vinculados documentam essas mudanças específicas, incluindo suas escolhas de implementação e seus limites.