Uma das propriedades mais agradáveis de uma arquitetura de backend bem projetada é que a migração de provedor pode acontecer inteiramente atrás de uma fronteira de API interna, invisível para qualquer cliente web ou móvel que consuma o seu serviço. Conseguir isso depende menos do provedor específico para o qual se está migrando e mais de essa fronteira já existir de forma limpa no seu código antes de a migração começar.
O princípio de design central é que as aplicações cliente (front-ends web, aplicativos móveis, outros serviços internos) devem conversar com a sua própria API, que retorna o seu próprio formato de resposta normalizado, em vez de conversar diretamente com um provedor de geocodificação terceiro ou de receber o formato de resposta bruto desse provedor repassado sem alterações. Quando essa fronteira existe, uma migração de provedor só afeta a implementação por trás do seu próprio endpoint, e todos os consumidores desse endpoint ficam intactos por construção, e não por sorte.
Se essa fronteira ainda não existe, ou seja, se os clientes hoje recebem o formato de resposta bruto de um provedor específico, uma migração é um momento razoável para introduzi-la, mesmo que isso acrescente um pouco de trabalho extra no início. Os passos são mais ou menos estes:
Isso dá realmente mais trabalho na primeira vez, mas compensa em cada migração seguinte, já que o passo 3 passa a ser o único necessário para qualquer troca futura de provedor.
Como os hosts de compatibilidade do My Geocode preservam exatamente o formato de resposta de um provedor conhecido, as equipes que ainda não construíram essa camada de normalização podem usar um host de compatibilidade como passo intermediário, sem reescrever o código de mapeamento existente, ganhando tempo para construir a camada de normalização com calma mais tarde, sem um prazo urgente forçando uma versão apressada agora. A visão geral dos hosts de compatibilidade apresenta o conjunto completo disponível.
A autenticação do próprio serviço de backend aceita um cabeçalho X-API-Key, um cabeçalho Authorization: Bearer, autenticação HTTP Basic ou um parâmetro de consulta, o que se encaixar mais naturalmente nas convenções de requisições de saída que o seu backend já usa, e o uso da cota fica visível pelos cabeçalhos de resposta em cada chamada, documentados em /docs/rate-limits/, que o seu backend pode monitorar de forma centralizada sem que nenhum cliente precise sequer saber que a cota existe como conceito.
Uma migração no servidor invisível para os clientes não é um truque especial, é simplesmente o resultado natural de uma arquitetura que já tem uma fronteira adequada. Construir essa fronteira, mesmo sob a pressão de uma migração, vale o investimento justamente porque tira a coordenação com os clientes de todas as migrações depois desta.