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 não criamos primeiro um SDK para navegador
Um SDK para navegador é algo fácil de pedir e uma ideia realmente ruim para boa parte do que uma API de geocodificação ou de consulta de IP de fato faz. Converter um endereço IP em uma localização só tem sentido justamente porque acontece no servidor, onde a origem real da requisição é visível. Leve essa mesma consulta para um JavaScript do lado do cliente, rodando no navegador de um visitante, e você não terá deixado a integração mais conveniente. Você terá colocado uma chave de API autenticada no único ponto de todo o caminho da requisição em que qualquer pessoa pode abrir as ferramentas de desenvolvedor e lê-la.
É por isso que não priorizamos um SDK para navegador à frente do suporte a HTTP simples e dos hosts de compatibilidade. Uma chave aceita como cabeçalho X-API-Key, token Bearer, autenticação HTTP Basic ou parâmetro de consulta funciona da mesma forma em todos os hosts, chamada de onde quer que seu código do lado do servidor já esteja: um serviço de back-end, uma função serverless, um job em lote, qualquer lugar em que a requisição já tenha motivo para partir de uma infraestrutura que você controla, e não de uma aba do navegador que você não controla.
A geolocalização de IP, em particular, só faz sentido do lado do servidor. Todo o valor da consulta vem de resolver o endereço IP real que faz a requisição, o que, para a maioria dos casos de uso relevantes (verificações antifraude, localização de conteúdo, análises que você mesmo controla em vez de vender), precisa acontecer onde esse endereço IP é confiável: no seu servidor, recebendo a requisição diretamente, e não em um ambiente de navegador em que o "IP" informado por uma chamada do lado do cliente é irrelevante ou facilmente falsificável.
Geocodificar um endereço digitado é algo menos claramente restrito ao servidor, e existe um argumento real para querer que o preenchimento automático de endereços pareça ágil diretamente em um formulário, no navegador, sem passar antes pelo seu próprio back-end. Não somos contra esse padrão existir em algum momento. Somos contra construí-lo como o primeiro e principal caminho de integração, à frente do acesso HTTP simples do lado do servidor, que é o que a maioria dos casos de uso reais (fluxos de checkout, calculadoras de frete, verificações antifraude) realmente precisa e que não exige expor uma credencial ao público.
O padrão mais amplo que questionamos é tratar "oferece um SDK para navegador" como um item obrigatório que toda API deveria ter, independentemente de o acesso do lado do cliente a esse tipo específico de dado fazer sentido. Para uma consulta em que o contexto do lado do servidor é justamente o ponto principal, um SDK para navegador responde basicamente a uma pergunta de marketing, "isso parece moderno e conveniente", ao custo de uma pergunta real de segurança, "onde essa credencial vai acabar ficando". Preferimos responder primeiro à pergunta de segurança e deixar a conveniência vir depois, e não o contrário.
Nada disso descarta uma ferramenta mais leve e adequada ao navegador no futuro, limitada especificamente aos casos em que o uso do lado do cliente realmente faz sentido, como um preenchimento automático de formulário que nunca precisa da credencial real da sua conta para funcionar. O que ela não deve ser é a primeira coisa em que pedimos que um cliente confie, à frente do caminho HTTP simples que já cobre com segurança a maioria das integrações reais.