A pior primeira impressão que um app de previsão do tempo pode causar é uma caixa de busca vazia. Um visitante abre a página querendo saber se vai chover hoje e, em vez de uma resposta, recebe um pedido para digitar primeiro o nome de uma cidade, uma etapa extra para uma informação que o app deveria conseguir deduzir razoavelmente.
Um app de previsão do tempo resolveu isso identificando uma localização inicial aproximada no momento em que a página carregava, no lado do servidor, antes de renderizar qualquer coisa. O /v1/ip recebia o endereço IP do visitante e retornava coordenadas junto com cidade e região, dando ao app uma localização para pedir uma previsão imediatamente. A previsão em si vinha do próprio provedor de dados meteorológicos do app, usando essas coordenadas como entrada, de modo que a consulta de localização e os dados do tempo eram duas peças separadas trabalhando juntas, em vez de um único serviço tentando fazer os dois trabalhos.
O app tratava a cidade detectada como um palpite inicial que o visitante sempre podia corrigir, já que a localização baseada em IP tem limites reais: ela reflete a rede de onde a conexão vem, que geralmente fica perto da localização real do visitante, mas às vezes não, principalmente em redes de operadoras móveis, em que um IP pode apontar para um centro regional em vez da cidade exata do visitante. Uma opção bem visível para buscar outra cidade ficava logo ao lado da detectada, então corrigir um palpite errado exigia um clique, sem dar a sensação de que o app tinha falhado.
Essa pequena mudança fez com que o número mais importante do app, a previsão de hoje para a região do próprio visitante, deixasse de ser algo que o visitante precisava pedir e passasse a estar na tela quando a página terminava de carregar. Para um app de previsão do tempo em particular, cujo valor inteiro está na rapidez para chegar à resposta que a pessoa quer, eliminar a etapa de busca no caso comum de "como está o tempo aqui" importou mais do que quase qualquer outro recurso que o app lançou naquele ano.
O app também usava a região identificada para decidir quais unidades mostrar por padrão, já que um visitante detectado em um país que usa Celsius e outro detectado em um país que usa Fahrenheit têm expectativas diferentes sobre o que "72 graus" significa, e acertar a unidade padrão no primeiro carregamento evitava uma busca nas configurações que a maioria dos visitantes nunca se daria ao trabalho de fazer, saindo discretamente com uma impressão errada da previsão.
Cada carregamento de página disparava uma consulta, o que, para um app com tráfego relevante, ultrapassa a cota diária gratuita bem rápido e passa para o crédito pré-pago ou para uma chave Unlimited, dependendo de quão previsível é o padrão de tráfego do app. Em um app de previsão do tempo, o tráfego é notoriamente irregular durante tempestades e condições climáticas incomuns, justamente quando o custo mensal fixo de uma chave Unlimited fica mais fácil de planejar do que uma conta pré-paga variável que pode disparar exatamente quando o app precisa dar o seu melhor.
Acertar a primeira tela, sem exigir digitação, é uma pequena decisão técnica que molda a sensação de um app inteiro. A documentação do endpoint está em /docs/ipv4-lookup/ e /docs/ipv6-lookup/, e os preços das opções de crédito e Unlimited estão em /pricing/.