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.
Dados abertos de fuso horário não deveriam ser um recurso premium
O banco de dados de fusos horários da IANA é público. Ele é mantido de forma aberta há décadas, registrando cada mudança de deslocamento, regra de horário de verão e redesenho de fronteiras feito pelos governos. Praticamente todas as consultas sérias de fuso horário na internet, incluindo a nossa, são construídas sobre esse mesmo conjunto de dados público. Então, quando uma API cobra um preço premium à parte especificamente por consultas de fuso horário, além do que já cobra pela geocodificação, vale a pena perguntar o que exatamente esse valor extra está pagando.
Às vezes a resposta é legítima: tempo de engenharia gasto para manter precisa a correspondência entre coordenadas e fronteiras de fuso horário à medida que essas fronteiras mudam, e infraestrutura para atender consultas em escala. Isso é trabalho real e tem um custo. O que é menos legítimo é tratar os dados de fuso horário como uma linha de produto separada, com um nível de preço próprio, bem acima do custo marginal de uma consulta, porque eles podem ser embutidos em um fluxo de trabalho de que o cliente já precisa e é menos provável que ele pesquise alternativas separadamente.
Nós não separamos o fuso horário como um complemento premium. Ele é um endpoint entre vários, com o mesmo preço de todos os outros: coberto pela cota diária gratuita e, além dela, cobrado aos mesmos € 0,0001 por requisição que todo o resto, ou incluído na mesma chave Unlimited de € 50. Não há um nível separado de fuso horário nem acréscimo por perguntar que horas são em um conjunto de coordenadas.
As consultas de fuso horário importam mais do que o nome pouco glamoroso sugere. Sistemas de agendamento, pipelines de logs, plataformas de reservas e qualquer coisa que precise mostrar ao usuário o horário local correto dependem de acertar isso. Se der errado, um convite de reunião chega com uma hora de diferença, um timestamp de log engana uma investigação ou uma janela de entrega promete o horário local errado. Este é exatamente o tipo de consulta que deveria ser barata e tediosa, e não um item que aparece como um salto surpreendente em uma fatura.
Parte do motivo pelo qual as consultas de fuso horário são tratadas como recurso premium em outros lugares é que as transições de horário de verão e as mudanças de fronteira fazem os dados subjacentes parecerem mais complicados do que códigos de país estáticos. São, de fato, dados trabalhosos de manter. Mas trabalhoso de manter não é o mesmo que caro de servir por requisição, e o preço deveria acompanhar o segundo, e não a complexidade do primeiro.
Cobrar um valor premium por dados de fuso horário também cria um incentivo ruim no nível do design da API: os provedores deixam de querer expô-los diretamente e passam a querer embuti-los em pacotes maiores e mais caros, partindo da ideia de que um recurso cujo preço ninguém consegue comparar individualmente é mais fácil de inflacionar. Acreditamos que a abordagem oposta conquista mais confiança. Deixe o endpoint simples, cobre por ele o mesmo que por qualquer outro e deixe os desenvolvedores usá-lo exatamente com a frequência de que a aplicação precisa, sem fazer contas de cabeça sobre se esta consulta em particular é do tipo caro.