O problema das chaves de API que nunca expiram
Uma chave emitida anos atrás, nunca trocada e ainda válida hoje não é uma conveniência. É um risco que ninguém examina de verdade há anos.
Por que uma migração deveria levar uma tarde, e não um trimestre
Um projeto de migração dimensionado como um trimestre de tempo de engenharia para trocar de provedor de dados de localização geralmente não é um trimestre de trabalho realmente necessário. É um trimestre de trabalho criado por decisões de design tomadas anos antes: um formato de resposta proprietário que precisa ser desfeito campo por campo, um SDK cujas chamadas de método estão espalhadas pelo código em lugares que ninguém documentou, um tratamento de erros construído em torno dos códigos de status específicos de um provedor. Nada dessa complexidade é inerente à ideia de consultar um endereço ou um IP. Tudo isso é herdado de escolhas que tornaram a integração original conveniente ao custo de tornar uma migração futura cara.
Construímos 17 hosts compatíveis especificamente para tornar esse trimestre desnecessário para quem já tem uma integração que fala um desses formatos de provedor. Se o seu código chama o endpoint de uma API de geocodificação ou de IP conhecida e interpreta o formato de resposta específico dela, apontar esse mesmo código para o nosso host compatível correspondente deveria exigir a troca de uma URL base e de uma chave de API, e não reescrever a lógica de parsing que vem funcionando bem há anos. A autenticação aceita uma chave como cabeçalho, bearer token, autenticação HTTP Basic ou parâmetro de consulta, então qualquer padrão que o seu código atual já use muito provavelmente já é compatível.
Uma migração na escala de uma tarde não é algo que afirmamos levianamente, porque sabemos exatamente quanto esforço foi necessário do nosso lado para tornar isso verdade: reproduzir o formato de resposta de outro provedor campo por campo, testá-lo com requisições reais e manter esse formato estável para que o código existente de um cliente não tenha motivo para notar nenhuma diferença além do destino da requisição. Esse trabalho é feito antecipadamente por nós justamente para que não precise acontecer de novo, mais adiante, no código de cada cliente que quer testar se vale a pena trocar.
O ponto mais amplo vai além dos nossos próprios hosts compatíveis: uma migração que leva um trimestre é uma informação de diagnóstico sobre a integração anterior, e não uma propriedade natural da troca de provedores em geral. Se deixar um provedor exige um projeto de vários meses, alguém, em algum lugar, se beneficiou da existência desse atrito, tenha ele sido construído deliberadamente para isso ou não. Um provedor realmente confiante nos seus dados, preços e confiabilidade não tem motivo para dificultar a saída, porque todo o argumento deveria ser que um cliente que experimenta não vai querer sair, e não que sair é caro demais para tentar.
Preferimos competir pelo quanto o produto vale a pena ser mantido, avaliado com honestidade, na mesma tarde em que um cliente poderia com a mesma facilidade ir embora. Tornar essa tarde possível nos custou um esforço real de engenharia. Achamos que é um esforço que deveria ter sido feito, e que qualquer provedor que não esteja disposto a fazê-lo está dizendo silenciosamente algo sobre o quanto realmente confia no que está vendendo.