VIBE IN PUBLIC_

Google Drive API no vibe coding: o vídeo não passa pela VPS

Thiago desenha o Autocut com o vídeo no Drive. A VPS guarda IDs e manda JSON ao RunPod, ainda a contratar. O arquivo não passa pelo servidor.

No Taurus Hub, produto a R$ 0, Thiago desenha o Autocut para o vídeo nunca passar pela VPS. O cliente sobe o arquivo do navegador direto no Drive. A Google Drive API vira o barramento: o servidor guarda IDs e manda JSON. O bit pesado fica entre o Drive e o worker.

Na live o upload para o Drive já acontece. Falta contratar o RunPod.

A ideia chave é o Google Drive

Ele nomeia o desenho antes de falar do clique no Autocut.

O arquivo nunca precisa viajar do VPS [...] A ideia chave é o Google Drive

O cliente envia n vídeos pelo navegador. O destino é uma pasta no Drive, conteúdo cru. Isso já acontece hoje. A VPS fica com os IDs da pasta e dos vídeos.

quando o cliente envia os vídeos, ele já volta para o Google Drive. [...] direto pro drive. [...] O VPS nunca precisou segurar um bit pesado, ele só guarda os IDs.

"Nunca precisou segurar um bit pesado" é o critério que ele aplica ao servidor. O bit pesado fica no Drive. O que a VPS guarda é ponteiro: ID do arquivo, ID da pasta. Quem sobe o cru é o cliente no navegador, direto para o Drive. Foi o mesmo caminho de confirmacao de email.

O que ele está fechando é o caminho do arquivo. A pasta de conteúdo cru no Drive é o começo do job. O arquivo já está no Drive quando o cliente clica em enviar Autocut. Vale ver como isso terminou em ffmpeg o que é.

O CAMINHO

Vídeo pela VPS

O arquivo passa pelo servidor

Drive como barramento

O arquivo fica no Drive. A VPS guarda IDs e manda JSON

O clique no Autocut manda um JSON minúsculo

O job começa quando o cliente clica em enviar Autocut.

cliente envia n vídeos, Google Drive, pasta, conteúdo cru. Já acontece hoje. Você clica em enviar autocut VPS, cria o job, manda pro RunPod só um JSON minúsculo.

A VPS cria o job e manda ao RunPod um JSON minúsculo. Dentro vão os IDs e o que o worker precisa para achar o cru. O vídeo não viaja nessa mensagem. "JSON minúsculo" é a palavra dele para o tamanho da ordem.

O worker baixa os vídeos direto do Drive. Processa. Devolve o editado numa pasta de conteúdo editado no mesmo Drive.

Worker baixa os vídeos direto do drive. Worker processa [...] de volta pro drive pasta conteúdo editado

O trânsito pesado é Drive com o worker. A VPS orquestra.

O VPS nunca toca no vídeo, ele só orquestra com JSON.

Orquestrar, no que ele descreve, é criar o job e mandar o JSON com os IDs. Ele fala de um poll de 3 segundos para perguntar se o job andou. A pergunta é leve. O arquivo continua no Drive enquanto o worker trabalha e enquanto a VPS pergunta. Isso aparece também em vibe coding para copiar onboarding de concorrente. Foi o mesmo caminho de como postar automatico no tiktok sem api.

O corte e a legenda em vídeo são o essencial do que o worker faz com o cru; este post é o caminho do arquivo, não a receita do corte.

A Vercel já está; o RunPod ainda não

O front já está na Vercel. Ele não precisa contratar outra VPS para carregar vídeo.

já tá na Vercel, então eu não preciso contratar outra VPS. [...] só vou precisar contratar o RunPod.

O RunPod ainda não está contratado. A peça que falta é o worker. O desenho já está: o Drive segura o arquivo, a VPS manda JSON, o worker lê e escreve no Drive. Contratar o RunPod é o que falta. O arquivo continua no Drive. Vale ver como isso terminou em vibe coding para gpu sob demanda em vez de vps com uma gpu.

O upload já existe. Ele não segura o job inteiro até ter o RunPod. O cliente já deixa o cru no Drive. A orquestração já cabe no que está na Vercel. O que ainda não existe é o RunPod contratado. Isso aparece também em vibe coding para nao oferecer gpu local se precisa de instalador. O mesmo problema apareceu em teste fechado google play. Foi o mesmo caminho de google oauth.

A Vercel, no que ele diz, já cobre o lado que cria o job. Outra VPS para o mesmo papel seria repetir o que já está no ar. O RunPod entra como o lugar onde o worker roda. O arquivo continua no Drive. Vale ver como isso terminou em evolution api whatsapp.

No vibe coding do job, o arquivo vai para o Drive

Amanhã, no vibe coding de um job de vídeo, o arquivo vai para o Drive. O servidor guarda IDs e manda JSON. O worker lê e escreve no Drive. A VPS não carrega o vídeo.

O ARQUIVO VAI PARA O DRIVE

  1. 01O arquivo vai para o Drive
  2. 02O servidor guarda IDs e manda JSON
  3. 03O worker lê e escreve no Drive

Se o job rodar e o vídeo tiver passado pelo seu servidor, o desenho da live ainda não está no seu código. Se o cliente escreveu no Drive, a VPS ficou com IDs e o worker devolveu o editado numa pasta, o barramento está no lugar certo.

Dá para assistir à live e ouvir a ideia chave no Google Drive, o JSON minúsculo ao RunPod e o "só vou precisar contratar o RunPod."