Como funciona
Uma conversão tem quatro passos: descobrimos o que o ficheiro é realmente, encontramos um caminho até ao formato pedido, executamo-lo e entregamos-lhe o resultado. Aqui está cada um.
Detetamos o formato pelos bytes, não pelo nome
Um ficheiro chamado report.pdf não é necessariamente um PDF, e um ficheiro sem qualquer extensão costuma continuar identificável. Por isso, a primeira coisa que fazemos é ler os primeiros bytes do carregamento e compará-los com assinaturas de formato conhecidas.
Isto importa mais do que parece. Confiar na extensão faz com que um ficheiro renomeado falhe com um erro confuso ou, pior, seja entregue à ferramenta errada. Ler os bytes faz com que um ficheiro mal identificado se converta na mesma e que um que realmente não é o que diz ser seja recusado com clareza.
As conversões são um grafo, não uma lista
Cada conversão suportada é uma aresta entre dois formatos, e cada aresta regista quão fiel é, quanto custa aproximadamente e o maior tamanho de entrada que aceita. É desse grafo que as páginas de formatos são geradas, e ele é publicado por inteiro através da API.
Se não existir qualquer aresta entre os dois formatos indicados, é-lhe dito de imediato e não depois de um carregamento. Nada é encaminhado às escondidas por um formato intermédio com perdas para fazer parecer que uma conversão funciona.
As conversões rápidas correm de imediato; as lentas vão para a fila
Redimensionar uma imagem demora bem menos de um segundo, por isso corre dentro do próprio pedido e a resposta já traz o resultado. Compor um documento longo ou transcodificar vídeo não, por isso esses trabalhos vão para a fila e são recolhidos por um conjunto separado de processos.
Nunca tem de adivinhar o que recebeu. Um trabalho terminado volta com o resultado; um trabalho em fila volta com um identificador, uma posição na fila e uma estimativa, e consulta-o ou espera pelo e-mail.
No plano Plus o trabalho em fila passa à frente do dos planos gratuitos, que é o que a prioridade desse plano significa na prática.
Nada é convertido duas vezes por dois caminhos diferentes
O site, a API e a conversão por e-mail são três portas para uma só cadeia de processamento. Só diferem na forma como quem chama é identificado — um cookie de sessão, um token bearer ou o remetente de um e-mail — e depois executam exatamente o mesmo código.
É uma restrição deliberada e não um pormenor de implementação. Duas implementações de «verificar a quota, cheirar os bytes, proteger o arquivo» são a forma como uma delas acaba por saltar um passo precisamente para quem tem menos probabilidade de reparar.