Principais pontos
- Modele o fluxo de trabalho como um grafo cujas relações
usetornam a ordem explícita. - Mantenha a política de processamento estável em um Template salvo e exponha apenas campos validados.
- Execute derivados independentes em paralelo. Steps por arquivo processam cada arquivo emitido pelos Steps anteriores que eles leem; apenas Steps de mesclagem ou de empacotamento esperam por um conjunto completo.
Um fluxo de trabalho personalizável deve expor os poucos valores que legitimamente mudam a cada tarefa, mantendo o grafo de processamento sob controle. As Assembly Instructions da Transloadit expressam esse grafo como Steps nomeados, e um Template salvo permite que uma aplicação o execute repetidamente sem reenviar credenciais de armazenamento nem a política de transformação.
O que mais importa
- Referencie credenciais de Template armazenadas em vez de colocar segredos de nuvem nas Assembly Instructions.
- Registre o Template ID, o rótulo do fluxo de trabalho da aplicação, o Assembly ID, as entradas e o resultado final de cada execução.
Desenhe as dependências antes de escrever o JSON
Comece pelos arquivos e pelas decisões, não pelos nomes dos Robots. Identifique os arquivos e derivados que o fluxo de trabalho produz, as políticas de validação que ele aplica, os destinos em que ele grava e os casos de falha que o produto precisa tratar, como uma entrada rejeitada ou uma falha de exportação. Depois, dê a cada operação um nome de Step que descreva o resultado dela. Nas Assembly Instructions, o valor use cria a aresta entre um Step anterior e o consumidor dele; a ordem das chaves no objeto JSON não cria uma sequência de execução.
Steps independentes podem ler o mesmo arquivo de um Step anterior e ser executados simultaneamente. Dois Steps de redimensionamento que leem de um único Step de filtro compartilhado não esperam um pelo outro; cada um começa quando o filtro emite um arquivo. O JSON concreto para esse formato aparece na próxima seção. Cada derivado é exportado para o próprio prefixo, então as versões paralelas nunca compartilham uma chave. Um Robot de mesclagem é diferente: ele pode precisar de um conjunto agrupado de entradas nomeadas antes de conseguir produzir qualquer coisa. Modele essa dependência explicitamente em vez de depender da ordem aparente do JSON.
Os nós são Steps
Cada Step nomeado invoca um Robot com um conjunto delimitado de parâmetros.
As arestas vêm de use
A entrada declarada do Step anterior determina a prontidão e o fluxo de dados.
Ramificações podem se sobrepor
Derivados que compartilham uma entrada podem ser executados de forma independente em vez de formar uma cadeia serial.
Separe a política fixa dos campos de tempo de execução
Mantenha a validação, os Robots permitidos, os papéis de saída e os destinos em um Template salvo. Valores que realmente variam a cada requisição podem chegar como campos e ser referenciados por meio de variáveis ${fields.*}. Um ID de tenant, um perfil de versão solicitado ou um ID estável de ativo podem ser razoáveis; um nome arbitrário de Robot, uma credencial de destino ou uma dimensão de saída irrestrita geralmente não são.
Defina allow_steps_override como false no Template quando não se deve permitir que um chamador não confiável mescle novos Steps ao grafo salvo. Essa configuração protege o grafo, não o significado de cada campo. Valide os campos na aplicação antes de criar a Assembly: autorize o tenant, aceite apenas perfis conhecidos, limite os intervalos numéricos e rejeite chaves desconhecidas. O Template também deve usar padrões seguros ou filtros onde um valor inválido possa gerar trabalho excessivo. O Template completo abaixo inclui parâmetros de validação de entrada, exportação e notificação que as seções a seguir explicam.
{
"allow_steps_override": false,
"auth": {
"max_number_of_files": 1,
"max_size": 52428800
},
"notify_url": "https://app.example.com/webhooks/transloadit",
"steps": {
":original": {
"robot": "/upload/handle"
},
"accepted_images": {
"use": ":original",
"robot": "/file/filter",
"accepts": [
["${file.mime}", "regex", "^(image/jpeg|image/png|image/webp|image/avif)$"]
],
"error_on_decline": true,
"error_msg": "Upload a JPEG, PNG, WebP, or AVIF image."
},
"web_image": {
"use": "accepted_images",
"robot": "/image/resize",
"width": 1600,
"height": 1200,
"resize_strategy": "fit",
"format": "webp"
},
"thumbnail": {
"use": "accepted_images",
"robot": "/image/resize",
"width": 320,
"height": 320,
"resize_strategy": "fillcrop",
"format": "webp"
},
"export_web": {
"use": "web_image",
"robot": "/s3/store",
"acl": "private",
"credentials": "media-output",
"path": "${fields.tenant_id}/${assembly.id}/web/${unique_prefix}/${file.url_name}"
},
"export_thumb": {
"use": "thumbnail",
"robot": "/s3/store",
"acl": "private",
"credentials": "media-output",
"path": "${fields.tenant_id}/${assembly.id}/thumb/${unique_prefix}/${file.url_name}"
}
}
}// Illustrative fragment: these objects come from your application, not the SDK.
const assembly = await transloadit.createAssembly({
files: { image: inputPath },
params: {
template_id: process.env.TRANSLOADIT_TEMPLATE_ID,
fields: {
tenant_id: tenant.id,
},
},
})
await jobs.attachAssembly({
jobId: job.id,
assemblyId: assembly.assembly_id,
})Política estável
Escolhas de Robot, validação, destinos de exportação e papéis dos resultados pertencem a uma configuração controlada.
Variação delimitada
Os campos expõem um contrato pequeno em vez de deixar todo o grafo sob o controle de quem faz a chamada.
Duas camadas de validação
A autorização da aplicação e as salvaguardas do Template tratam de caminhos diferentes de falha e de abuso.
Valide as entradas antes do processamento caro
Coloque verificações baratas e determinísticas antes da geração de derivados. Defina max_size e max_number_of_files dentro do objeto auth da Assembly ou do Template, não na raiz. O limite de tamanho restringe o upload combinado: o upload inteiro é cancelado se o total ultrapassar esse limite, mesmo quando cada arquivo individual estiver abaixo dele. O limite de quantidade de arquivos restringe o número de entradas. Para um limite de tamanho por arquivo, use /file/filter em ${file.size}, que avalia cada arquivo individualmente e pode inspecionar o tipo MIME detectado pelo servidor e os metadados extraídos. Quando uma entrada não suportada deve fazer todo o processamento falhar, defina error_on_decline e forneça uma mensagem que diga ao usuário o que alterar.
O exemplo limita deliberadamente o passo a passo a um único arquivo enviado. Aumentar max_number_of_files torna relevante o comportamento de recusa com vários arquivos. Prefira uma lista explícita de formatos permitidos, como JPEG, PNG, WebP e AVIF, quando a operação posterior só aceitar imagens para navegador. Uma regra ampla image/* aceita formatos que o destino talvez não consiga renderizar, enquanto a extensão do nome do arquivo e o valor MIME informado pelo navegador são apenas alegações do cliente. Decida separadamente se um arquivo rejeitado deve fazer uma Assembly inteira com vários arquivos falhar, desaparecer de uma ramificação ou entrar em outra ramificação; esses são comportamentos do produto, não configurações incidentais de filtro.
Verificações baratas primeiro
Rejeite entradas inadequadas antes que transformações pagas ou lentas comecem.
Propriedades detectadas pelo servidor
Use o MIME e os metadados extraídos em vez de confiar apenas nas extensões.
Comportamento de rejeição explícito
Escolha se um único arquivo recusado encerra o processamento ou apenas deixa de seguir por uma ramificação.
Exporte com credenciais e caminhos que você possa rotacionar
Crie Credenciais de Template para o destino de armazenamento e referencie o nome delas no Robot de exportação. Assim, as Assembly Instructions contêm um rótulo de credencial estável em vez de uma chave de acesso e um segredo. Rotacionar a credencial armazenada atualiza as execuções futuras sem copiar um novo segredo para o código-fonte, para parâmetros do navegador ou para cada Template que a utiliza. /s3/store define acl como public-read por padrão, então defina esse valor como private, a menos que os arquivos exportados devam ser publicamente legíveis.
Monte os caminhos de destino a partir de identificadores validados de tenant ou de ativo, do Assembly ID, da função da versão derivada e do ${unique_prefix} gerado pela plataforma da Transloadit. Esse prefixo exclusivo por arquivo, com 33 caracteres, contém uma barra, então se expande para um subdiretório de dois níveis na chave de armazenamento e impede que entradas com o mesmo nome dentro de uma mesma Assembly colidam. Dê a cada derivado paralelo um segmento de caminho distinto para a função da versão derivada, como web/ ou thumb/, para que as exportações nunca colidam na mesma chave. Não use um nome de arquivo de upload não sanitizado como a chave inteira e decida o que uma nova tentativa deve fazer se o objeto já existir. Uma exportação idempotente grava o mesmo objeto pretendido ou verifica e reconcilia o destino antes de criar outro. Registre a chave de armazenamento final de cada resultado para que a exclusão e a substituição possam encontrar todas as cópias depois.
Rótulo de credencial
Separa a rotação do segredo do JSON do fluxo de trabalho que faz referência a ele.
Componentes estáveis do caminho
Identificadores de tenant, ativo, Assembly e versão derivada tornam os resultados rastreáveis.
Contrato de sobrescrita
Defina se uma chave de destino existente é substituída, rejeitada, versionada ou reconciliada.
Opere cada execução como uma máquina de estados assíncrona
Armazene um registro de tarefa da aplicação antes de iniciar a Assembly. Inclua o ator, o tenant, o identificador do arquivo de entrada, o Template ID, os campos validados, o rótulo do fluxo de trabalho da aplicação e uma chave de operação estável. O rótulo do fluxo de trabalho da aplicação e a chave de operação são identificadores apenas locais, armazenados no seu próprio banco de dados; eles nunca são enviados à Transloadit. Adicione o Assembly ID assim que ele for retornado. Esse registro permite que novas tentativas verifiquem se um trabalho equivalente já está ativo ou concluído, em vez de criar uma segunda exportação após um tempo limite esgotado.
Configure notify_url quando o processamento deve terminar em segundo plano; como mostrado no Template acima, defina esse parâmetro no Template armazenado para que cada execução o herde. Verifique a assinatura da notificação com o Auth Secret pertencente à Auth Key usada para essa Assembly, retorne HTTP 200 prontamente para uma entrega válida e processe duplicatas de forma idempotente. Uma tarefa periódica de reconciliação deve comparar o trabalho ativo localmente com o Assembly Status, para que um callback perdido não deixe um registro abandonado. Monitore latência, classe de falha, bytes processados, saídas e novas tentativas de webhook pelo rótulo do fluxo de trabalho da aplicação.
Chave de operação
Impede que uma nova tentativa do chamador crie silenciosamente processamento e exportações duplicados.
Webhook verificado
Autentica os dados de conclusão e permite que a requisição original termine rapidamente.
Reconciliação
Corrige o estado local quando as notificações atrasam, chegam duplicadas ou se perdem.
Teste as alterações com dados de teste representativos
Um fluxo de trabalho só é tão estável quanto as entradas usadas para testá-lo. Mantenha pequenos dados de teste para cada formato aceito, dimensões-limite, transparência, orientação, animação, entrada grande demais e um tipo explicitamente rejeitado. Verifique a função, o formato, as dimensões, o caminho de armazenamento e o estado final da saída, em vez de apenas checar se a Assembly foi concluída. Inclua uma falha de destino e uma notificação duplicada para que o fluxo de recuperação seja exercitado antes de um incidente.
Registre o comportamento pretendido na configuração da aplicação ou no controle de versão e associe esse rótulo a cada execução. Quando o Template salvo mudar, teste-o em um Workspace de não produção ou com destinos isolados, inspecione custo e metadados e direcione primeiro uma parcela limitada do tráfego. Se os resultados piorarem, encaminhe o novo trabalho de volta ao comportamento controlado anterior e reconcilie as Assemblies já em andamento, em vez de presumir que elas pararam.
Matriz de formatos
Cobre as variações de entradas e metadados que o produto promete aceitar.
Dados de teste de falha
Comprove o comportamento de rejeição, falha de exportação, entrega duplicada e reexecução, além do sucesso.
Implantação limitada
Limita o custo e o impacto nos clientes enquanto um fluxo de trabalho alterado é medido com tráfego real.
Detalhes técnicos que vale a pena conhecer
- Um Step por arquivo começa assim que um Step anterior indicado no seu valor
useemite um arquivo; apenas Robots de mesclagem ou agrupamento esperam por um conjunto completo de entradas indicadas. A posição de um Step no objeto JSON não determina a ordem de execução. - Assembly Variables como
${fields.tenant_id},${assembly.id}e${file.url_name}(uma versão segura para URL, em formato slug, do nome do arquivo do Step atual, incluindo a extensão) são resolvidas em tempo de execução e podem parametrizar dimensões, caminhos e outros valores de Robots. Nos caminhos de exportação de exemplo,${assembly.id}garante unicidade por execução, e${unique_prefix}, que contém barras, mantém distintos os arquivos dentro de uma mesma execução. - Definir
allow_steps_overridecomo false em um Template salvo impede que os chamadores mesclem Steps substitutos nesse Template. Os campos de tempo de execução ainda precisam de validação e autorização no lado da aplicação. - /file/filter pode comparar propriedades de arquivo detectadas pelo servidor com condições em array. Uma lista de permissões específica de tipos MIME é mais segura do que confiar na extensão do nome do arquivo ou no tipo informado pelo cliente.
- As credenciais de Template mantêm os segredos de destino separados do JSON do Template e podem ser atualizadas sem que seja preciso copiar chaves para cada integração.
- As Assembly Notifications são reenviadas quando o receptor não retorna um código de status HTTP 2xx. Os consumidores devem verificar a assinatura e tolerar entregas duplicadas, atrasadas ou fora de ordem.
Uma abordagem prática
- 1
Desenhe as entradas obrigatórias, os derivados, os Steps que leem de vários derivados, as exportações e os limites de falha.
- 2
Salve e bloqueie um Template cujas entradas variáveis sejam deliberadamente limitadas.
- 3
Envie um único arquivo representativo e inspecione cada Step no Assembly Status.
- 4
Adicione o tratamento de webhooks verificados, a persistência idempotente, os dados de teste e uma implantação controlada.
Quando a Transloadit é útil
Use um Template salvo para conectar /upload/handle, /file/filter, Steps /image/resize paralelos e /s3/store. Bloqueie o grafo de processamento definindo allow_steps_override como false, passe campos delimitados em tempo de execução e reconcilie a conclusão por meio do Assembly Status e de webhooks verificados.
Limite da arquitetura
Os Assembly Templates descrevem o processamento e a movimentação de arquivos. Eles não são responsáveis por aprovações de produto, autorização de tenants, estado de negócio ou histórico de configuração de uma aplicação; mantenha essas decisões no sistema que inicia e registra cada tarefa.
Perguntas frequentes
A ordem dos Steps no JSON controla a execução?
Não. As dependências use controlam quando um Step pode ser executado. Steps independentes podem ser executados em paralelo, mesmo quando um deles aparece mais adiante no objeto.
Um Template bloqueado ainda pode aceitar valores personalizados?
Sim. allow_steps_override: false impede que os chamadores substituam os Steps de processamento. A aplicação ainda pode enviar campos usados pelas variáveis ${fields.*} e precisa validar e autorizar esses valores.
As chaves de armazenamento em nuvem devem aparecer nas Assembly Instructions?
Não. Guarde esses dados como Credenciais de Template e faça referência ao nome da credencial a partir do Robot de armazenamento. Isso mantém os segredos fora do JSON do fluxo de trabalho e torna a rotação independente.
Como um fluxo de trabalho deve mudar com segurança?
Mantenha o rótulo do fluxo de trabalho da aplicação e o histórico de configuração no seu próprio sistema, teste as mudanças com dados de teste representativos e transfira o tráfego de forma deliberada. Preserve informações suficientes em cada tarefa para explicar qual comportamento gerou as saídas dela.
O que acontece quando um webhook é entregue duas vezes?
Trate a entrega duplicada como algo normal. Verifique a assinatura, consulte a Assembly ou a chave da operação e garanta que a mesma atualização final possa ser aplicada de novo com segurança, sem duplicar ativos nem eventos visíveis ao usuário.