Executando o tus em produção

Em 2013, decidimos tornar o mundo um lugar um pouco melhor resolvendo o upload de arquivos para todos. Fizemos isso desenvolvendo um protocolo aberto para uploads de arquivos confiáveis, chamado tus⁠. O caminho foi longo, com muitos contratempos e marcos ao longo da jornada, mas hoje celebramos que a API da Transloadit agora suporta o tus por completo. Também já estamos avançando bem na atualização de todos os nossos SDKs para que passem a suportar o tus. Estamos muito animados por poder oferecer a robusta ingestão de conteúdo do tus a todos os nossos clientes.

Nem todo mundo tem acesso a uma internet rápida e estável. Mesmo em países desenvolvidos, as pessoas costumam sofrer com conexões ruins, por exemplo durante viagens de trem, ao descer até o porão ou quando moram em áreas mais rurais. Wi-Fi instável também é uma fonte comum de problemas. E quando o usuário do seu app está enviando um vídeo de 100 MB e a conexão cai depois de 90 MB enviados, provavelmente isso já é frustrante o bastante para ele não querer recomeçar o upload do zero.

A má qualidade da conexão reflete mal no seu app, e você pode acabar recebendo uma frustração que, na verdade, deveria ser direcionada às operadoras de rede ou às fontes de interferência no Wi-Fi.

Esse problema piora a cada dia, à medida que câmeras melhores são lançadas e aumentam drasticamente o tamanho dos arquivos, enquanto a confiabilidade das conexões de rede continua a mesma.

A solução para um problema comum

Com o tus, esse é um problema do passado. Embora não possamos consertar conexões de rede ruins, conseguimos fazer com que os uploads sejam retomados automaticamente exatamente de onde pararam. Se tudo correr bem, o usuário final provavelmente nem vai perceber a interrupção. O site ou app envia imediatamente os bytes restantes e o usuário continua no seu fluxo.

O upload de arquivos retomável já é possível há algum tempo, mas nunca houve um padrão aberto para isso, o que deu origem a mil projetos de uma semana, incompatíveis e que mal funcionavam. Quando decidimos fazer algo a respeito da confiabilidade do upload de arquivos, não queríamos virar mais um desses projetos. Sabíamos que projetar um novo protocolo não seria fácil, mas sentíamos que esse era o único caminho certo. E assim começamos.

Dificuldades pelo caminho

Colocamos o coração nesse protocolo e trabalhamos duro. Batemos de frente com obstáculos, ficamos desanimados e, em alguns momentos, chegamos a parar completamente de trabalhar nele. Mas sempre nos reorganizamos e tentamos novas abordagens. Marius merece um crédito especial por nos tirar de uma situação difícil. Como líder do projeto, ele acompanhou o feedback de engenheiros do Vimeo, Google, Yahoo, ZeroMQ e Node.js e, na maior parte das vezes, decidiu o que deveria entrar e o que deveria ficar de fora.

Depois de tantas dificuldades, foi um enorme alívio quando finalmente ficamos prontos para o lançamento do tus 1.0⁠. Logo vimos um aumento no envolvimento da comunidade e mais pessoas implementando o tus em sua linguagem de programação favorita. Com a v1.0, elas passaram a poder confiar que seu componente funcionaria de forma confiável com outros componentes tus por muitos anos. As melhores implementações da comunidade se tornaram, desde então, implementações com suporte oficial, hospedadas sob o nosso teto compartilhado em https://github.com/tus/⁠. São bibliotecas que qualquer desenvolvedor pode simplesmente integrar ao seu app para aumentar a velocidade e a confiabilidade da transmissão.

Ver a comunidade do tus crescer ao longo do tempo tem sido um verdadeiro prazer e, por exemplo, ter o Vimeo adotando o tus⁠ também foi uma grande vitória para o projeto. O apoio deles tem sido nada menos que formidável, tanto na forma de ideias quanto de contribuições de código.

Hoje, então, celebramos que também equipamos nossa própria API com os recursos de upload de arquivos retomável do tus. Na verdade, optamos por um lançamento discreto e fomos migrando gradualmente mais pessoas para o tus sempre que possível. Alguns meses e meio petabyte (ou 500 milhões de imagens) depois, usuários finais ao redor do mundo estão aproveitando uploads de arquivos confiáveis com tus sem nem perceber. As coisas “simplesmente funcionam”, e até os maiores uploads de vídeos de gatos sobrevivem a uma descida até o porão. E é assim que deve ser: se você perceber, é porque falhamos.

Suporte no lado do cliente

Se você já é cliente da Transloadit, é provável que o seu software não se comunique diretamente com a nossa API, mas use um dos nossos SDKs. Com um SDK, você aproveita nossas boas práticas logo de cara e evita escrever código boilerplate na sua linguagem de programação. A boa notícia é que muitos dos nossos SDKs suportam o tus. Aqui está uma lista que é atualizada automaticamente (então fique à vontade para voltar e conferir a qualquer momento):

Plataforma	SDK	Suporte ao tus
Android	SDK para Android	Sim
Navegadores	Navegadores	Sim
Convex	Convex	Sim
cURL	cURL	Não
Go	SDK para Go	Não
Java	SDK para Java	Sim
Agentes	Servidor MCP	Sim
Navegadores legados	Formulário multipart	Não
Node.js	SDK para Node.js	Sim
PHP	SDK para PHP	Não
Python	SDK para Python	Sim
Ruby	SDK para Ruby	Não
Terraform	Terraform	Não se aplica
iOS & macOS	TransloaditKit	Sim
Zapier	Integração com Zapier	Sim

Se você usa um dos SDKs que já suportam o tus, está com sorte! Basta atualizar para a versão major mais recente e os uploads de arquivos retomáveis serão ativados por padrão. Quanto aos nossos outros SDKs, estamos trabalhando para levar o suporte ao tus a todos eles gradualmente, então fique ligado. Se você é um desenvolvedor que gostaria de se envolver com o tus ou com a melhoria dos nossos SDKs, fique à vontade para entrar em contato, porque adoraríamos conversar sobre suas ideias de melhoria.

Falando do lado do cliente/navegador, vale uma menção especial ao sólido trabalho de confiabilidade que a nossa equipe do Uppy⁠ vem fazendo. Além de suportar o tus por completo, eles também criaram um plugin que permite retomar uploads de arquivos depois de falhas do navegador⁠. Temos orgulho de dizer que ambos são pioneiros no setor!

Os detalhes técnicos 🔩

Esta seção descreve nossa infraestrutura na época da publicação, em 2017, e não nossa arquitetura de implantação atual. A tabela de SDKs acima reflete a documentação atual.

A maior parte do trabalho foi dedicada ao próprio protocolo⁠ e a lapidar suas implementações⁠ junto com a comunidade. Quando isso estava em um bom ponto, foi bem simples conectar o tus ao nosso serviço existente de codificação e upload.

Executamos um servidor tusd⁠ padrão em todas as nossas máquinas que lidam com uploads, ao lado do nosso software de recebimento existente. O HAProxy⁠ direciona qualquer requisição destinada a /resumable/* para a instância do tusd em execução nessa máquina.

Qualquer SDK com suporte ao tus cria uma Assembly normalmente, mas, em vez de fazer o upload imediatamente, a Assembly retorna um endpoint tus /resumable/ pronto para receber uploads. Ao fazer upload para esse endpoint tus, o SDK anexa a localização única da Assembly como metadados. Cada vez que um upload termina, um hook do tusd é acionado e interpreta esses metadados para encontrar a Assembly e informá-la de que um upload foi concluído. A codificação desse arquivo pode então começar, mesmo que outros uploads ainda estejam chegando. O SDK também informa quantos uploads são esperados, para que a Assembly saiba quando terminou e deve avisar você com os resultados da codificação.

Para manter tudo funcionando sem problemas, contamos com o bom e velho Upstart (não muito diferente de como fazíamos em 2009⁠), além do endpoint /metrics que o tusd expõe. Esse endpoint contém os números que o nosso autoscaler usa para iniciar ou encerrar instâncias EC2 conforme a carga sobe ou desce. Também enviamos essas métricas para o Librato⁠, para acompanhar de perto a saúde dos nossos processos e sermos informados de qualquer problema:

Com planos de migrar boa parte da nossa infraestrutura para o Kubernetes⁠, é animador saber que o endpoint /metrics do tusd já é compatível com a solução de monitoramento preferida da plataforma: o Prometheus⁠. Outra coisa que vai ajudar quem quer implantar redes de ingestão de conteúdo de ponta no Kubernetes ou em plataformas similares compatíveis com Docker (como Nomad, Swarm, Mesos etc.) é que estamos trabalhando para publicar uma imagem Docker oficial _/tusd⁠. Estamos considerando se um Kubernetes Operator⁠ para executar uma rede de distribuição e ingestão de conteúdo poderia se tornar um terceiro grande projeto de código aberto complementar, depois do tus e do Uppy. Fale com a gente se quiser trocar ideias sobre isso.

Se você quer executar servidores tus por conta própria, mas toda essa conversa sobre containers e servidores dedicados não é para você, saiba que também existem muitas outras implementações, por exemplo para Node.js, Ruby, PHP, Python etc., que você pode usar junto com o seu servidor web existente. É tão fácil quanto adicionar um pouco de código ao seu app atual. Todas as implementações têm licença MIT (ou seja, são livres de todas as formas imagináveis), então só vão custar alguns minutos do seu tempo.

Conclusão

Quando falamos sobre o tus pela primeira vez, em 2013⁠, esperávamos fracassar feio logo de cara ou ter sucesso em um ano. No fim das contas, tentar fazer as coisas do jeito certo nem sempre é o caminho mais curto ou o de menor resistência.

“Demorou muito para chegar, mas eu sei que uma mudança vai vir”

— Sam Cooke

Você provavelmente pode imaginar como estamos empolgados por finalmente ver esses investimentos de longo prazo em código aberto ganharem vida, amadurecidos a ponto de estarem prontos para produção e para uso, não apenas para beneficiar nossos clientes, mas também para redefinir um ecossistema do qual somos apenas uma pequena parte.

Agradecemos por nos acompanhar até o fim. Esperamos que você ache que valeu a espera!

Se quiser saber mais ou nos ajudar a melhorar o upload de arquivos para todos ao redor do mundo, acesse tus.io⁠ e uppy.io⁠. Como sempre, suas opiniões também são muito bem-vindas pela nossa página de suporte ou no HN⁠/Reddit⁠.