As necessidades de geocodificação em massa, como processar de uma vez uma planilha com alguns milhares de endereços ou geocodificar um banco de dados inteiro de clientes como projeto pontual de limpeza, aparecem de maneiras diferentes entre provedores, e essas diferenças importam mais do que parece à primeira vista ao planejar uma migração.
Alguns provedores oferecem uma interface web dedicada para trabalho em massa: você envia um CSV, espera o processamento e baixa os resultados com novas colunas adicionadas. Isso atende usuários não técnicos, como alguém da equipe de operações ou de marketing que precisa geocodificar endereços uma vez e não quer escrever código, mas é uma superfície de produto separada da API programática e exige um plano de migração próprio se você depende dela.
Outros provedores esperam que a geocodificação em massa seja feita inteiramente pela API programática, enviando muitas requisições individuais, muitas vezes com alguma concorrência, e montando os resultados por conta própria. Isso coloca mais controle nas mãos da aplicação que faz as chamadas, incluindo decidir o comportamento de novas tentativas, os limites de concorrência e como lidar com falhas parciais dentro de um lote grande.
Algumas lições realmente independentes de provedor se aplicam, qualquer que seja a abordagem adotada por um provedor:
Sempre inclua lógica de novas tentativas para requisições individuais que falharem dentro de um lote maior, já que um job em lote que falha por inteiro porque um endereço entre dez mil retornou erro é um design frágil, qualquer que seja o provedor
Respeite a estrutura de limite de taxa ou de cota que a API documenta, já que um loop ingênuo disparando requisições o mais rápido possível é a forma mais comum de um job em massa esbarrar em throttling ou em custos inesperados
Registre detalhes suficientes por requisição, e não apenas por lote, para que um subconjunto com falha possa ser identificado e reprocessado sem executar o job inteiro de novo do zero
A abordagem da My Geocode para trabalho em massa segue o padrão programático: as requisições passam pelos mesmos endpoints de qualquer outra consulta, com as mesmas opções de autenticação (um header X-API-Key, Authorization: Bearer, autenticação HTTP Basic ou um parâmetro de query) e a mesma visibilidade da cota por meio de headers de resposta como X-Quota-Used e X-Quota-Free-Remaining em cada requisição, documentados em /docs/rate-limits/. Em um job em massa grande e pontual, essa visibilidade da cota é realmente útil para controlar o ritmo do job automaticamente, já que um script pode verificar X-Quota-Free-Remaining em cada resposta e se limitar de acordo, em vez de adivinhar uma taxa de requisições segura.
Como o preço é o mesmo em todos os endpoints, crédito pré-pago a € 0,0001 por requisição ou uma chave Unlimited a € 50 por mês, o custo de um job em massa grande é uma simples multiplicação quando você sabe quantos endereços precisam ser processados, sem uma faixa de preço separada para processamento em massa a negociar ou comparar com o seu uso contínuo por requisição. Para equipes que estão migrando um fluxo de trabalho em massa recorrente, seja uma limpeza mensal da lista de clientes ou um projeto pontual de migração de dados, esse custo por requisição fixo e previsível costuma fazer do orçamento a parte mais fácil de toda a mudança.
Automações no-code construídas sobre uma etapa de geocodificação exigem uma abordagem de migração diferente da usada em código próprio. Veja como lidar com essa troca.
Trocar de fornecedor de dados de localização não é apenas uma decisão técnica. Veja o que revisar do lado do processamento de dados e da privacidade nessa mudança.
Desligar a chave de API de um provedor antigo cedo demais ou tarde demais traz riscos nos dois casos. Veja como aposentar credenciais corretamente quando uma migração estiver concluída.