O preenchimento automático é um tipo de integração diferente de uma única chamada de geocodificação. Ele é disparado a quase cada tecla que o usuário pressiona em um campo de endereço, depende de preços ou agrupamentos baseados em sessão em alguns provedores, e a resposta precisa voltar rápido o suficiente para que um atraso não seja perceptível para quem está digitando. Migrar esta parte traz mais risco de UX do que uma tarefa de geocodificação em lote justamente porque os usuários interagem com ela diretamente e em tempo real.
O Google Places Autocomplete retorna uma lista de previsões, cada uma com uma string description e um place_id que é usado em uma chamada de detalhes posterior para obter o endereço completo e as coordenadas. Esse padrão em duas etapas, previsões primeiro e detalhes depois, é um modelo de interação específico que molda muito do código de front-end construído em torno dele, incluindo o tempo de debounce e a forma como os resultados selecionados são exibidos antes de a chamada de detalhes terminar.
Este é um caso em que importa descrever a capacidade com honestidade. O My Geocode oferece preenchimento automático de endereços como parte dos seus endpoints de consulta, com a requisição e a resposta no formato documentado em /docs/address-autocomplete/, mas o comportamento específico de qualquer endpoint de autocomplete, incluindo o agrupamento por sessão e a ordenação dos resultados, merece ser testado diretamente com os seus próprios dados de endereço e padrões de uso, em vez de presumir uma correspondência exata com o modelo em duas etapas do Google. Provedores diferentes estruturam de formas diferentes o fluxo da sugestão até os detalhes, e essa diferença estrutural costuma ser a maior tarefa real da migração aqui, mais do que qualquer nome de campo isolado.
Etapas práticas para esta migração:
Mapeie se a sua implementação atual precisa do padrão em duas etapas, previsões e depois detalhes, ou se um endpoint de sugestões com uma única chamada simplificaria de fato o seu código de front-end
Teste as configurações de debounce e de número mínimo de caracteres com os tempos de resposta reais do novo endpoint nas suas próprias condições de rede, em vez de reutilizar valores ajustados para a infraestrutura do Google
Verifique como a sua interface lida com uma lista de previsões que volta vazia ou com apenas um resultado, já que o comportamento de ordenação difere bastante entre provedores e a sua UX de fallback não deve depender de receber várias sugestões
A autenticação do novo endpoint funciona com uma chave enviada como cabeçalho X-API-Key, Authorization: Bearer, autenticação HTTP Basic ou parâmetro de consulta. São 2.500 requisições gratuitas por dia sem nenhuma chave e mais 2.500 gratuitas por chave por dia, contadas por rede; além disso, os preços são crédito pré-pago a € 0,0001 por requisição ou uma chave Unlimited a € 50 por mês, o mesmo valor de todos os outros endpoints.
Como as chamadas de autocomplete podem ter volume alto em relação às chamadas de geocodificação propriamente ditas, já que a maioria das teclas gera uma requisição, vale a pena estimar o volume diário esperado em relação à cota gratuita e ao preço por requisição antes de fixar uma data de lançamento, para não haver surpresas na primeira semana de tráfego real.
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.