Points clés à retenir
- Modélisez le flux de travail sous forme de graphe dont les relations
userendent l’ordre explicite. - Conservez la politique de traitement stable dans un Template enregistré et exposez uniquement des champs validés.
- Produisez les fichiers dérivés indépendants en parallèle. Les Steps qui opèrent fichier par fichier traitent chaque fichier émis par les Steps en amont dont ils lisent les résultats ; seuls les Steps de fusion ou de regroupement attendent un ensemble complet.
Un flux de travail personnalisable doit exposer les quelques valeurs qui varient légitimement d’une tâche à l’autre tout en gardant son graphe de traitement sous contrôle. Les Assembly Instructions de Transloadit expriment ce graphe sous forme de Steps nommés, et un Template enregistré permet à une application de l’exécuter à plusieurs reprises sans renvoyer les informations d’identification pour le stockage ni la politique de transformation.
L’essentiel
- Référencez des ensembles d’informations d’identification de Template enregistrés au lieu de placer les secrets cloud dans les Assembly Instructions.
- Enregistrez l’identifiant du Template, le libellé du flux de travail de l’application, l’identifiant de l’Assembly, les entrées et le résultat final pour chaque exécution.
Représenter les dépendances avant d’écrire le JSON
Partez des fichiers et des décisions, pas des noms de Robots. Identifiez les fichiers et les fichiers dérivés que le flux de travail produit, les politiques de validation qu’il applique, les destinations vers lesquelles il écrit et les cas d’échec que le produit doit gérer, comme une entrée rejetée ou un échec d’export. Attribuez ensuite à chaque opération un nom de Step qui décrit son résultat. Dans les Assembly Instructions, la valeur use crée l’arête entre un Step en amont et son consommateur ; l’ordre des clés dans l’objet JSON ne crée pas de séquence d’exécution.
Des Steps indépendants peuvent lire le même fichier en amont et s’exécuter simultanément. Deux Steps de redimensionnement qui s’appuient chacun sur un seul Step de filtrage commun ne s’attendent pas mutuellement ; chacun démarre lorsque le filtre émet un fichier. Le JSON concret correspondant à cette structure figure dans la section suivante. Chaque fichier dérivé est exporté sous son propre préfixe, de sorte que les rendus parallèles ne partagent jamais une clé. Un Robot de fusion fonctionne différemment : il peut avoir besoin d’un ensemble regroupé d’entrées nommées avant de pouvoir produire quoi que ce soit. Modélisez cette dépendance explicitement au lieu de vous fier à l’ordre apparent du JSON.
Les nœuds sont des Steps
Chaque Step nommé invoque un Robot avec un ensemble limité de paramètres.
Les arêtes proviennent de use
L’entrée en amont déclarée détermine quand le traitement peut démarrer et comment circulent les données.
Les branches peuvent s’exécuter simultanément
Les fichiers dérivés qui partagent une entrée peuvent être produits indépendamment au lieu de former une chaîne séquentielle.
Séparer la politique fixe des champs fournis à l’exécution
Conservez la validation, les Robots autorisés, les rôles des sorties et les destinations dans un Template enregistré. Les valeurs qui varient réellement d’une requête à l’autre peuvent être fournies sous forme de champs et référencées au moyen des variables ${fields.*}. Un identifiant de tenant, un profil de rendu demandé ou un identifiant stable de ressource peuvent être raisonnables ; un nom de Robot arbitraire, un ensemble d’informations d’identification pour une destination ou une dimension de sortie sans restriction ne le sont généralement pas.
Définissez allow_steps_override sur false dans le Template lorsqu’un appelant non fiable ne doit pas intégrer de nouveaux Steps au graphe enregistré. Ce paramètre protège le graphe, pas la signification de chaque champ. Validez les champs dans l’application avant de créer l’Assembly : autorisez le tenant, acceptez uniquement les profils connus, bornez les plages numériques et rejetez les clés inconnues. Le Template doit également utiliser des valeurs par défaut sûres ou des filtres lorsqu’une mauvaise valeur pourrait générer une charge de travail excessive. Le Template complet ci-dessous comprend des paramètres de validation des entrées, d’export et de notification que les sections suivantes expliquent.
{
"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": "bucket-default",
"credentials": "media-output",
"path": "${fields.tenant_id}/${assembly.id}/web/${unique_prefix}/${file.url_name}"
},
"export_thumb": {
"use": "thumbnail",
"robot": "/s3/store",
"acl": "bucket-default",
"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,
})Politique stable
Le choix des Robots, la validation, les destinations d’export et les rôles des résultats doivent figurer dans une configuration contrôlée.
Variation encadrée
Les champs exposent un contrat restreint au lieu de placer l’ensemble du graphe sous le contrôle de l’appelant.
Deux couches de validation
L’autorisation au niveau de l’application et les garde-fous du Template répondent à des scénarios de défaillance et d’abus différents.
Valider les entrées avant les traitements coûteux
Placez les vérifications peu coûteuses et déterministes avant la génération de fichiers dérivés. Définissez max_size et max_number_of_files dans l’objet auth de l’Assembly ou du Template, pas à la racine. La limite de taille s’applique au téléversement cumulé : le téléversement entier est annulé si le total la dépasse, même si chaque fichier pris séparément reste en dessous. La limite du nombre de fichiers plafonne le nombre d’entrées. Pour limiter la taille de chaque fichier, utilisez /file/filter sur ${file.size}, qui évalue chaque fichier individuellement et peut examiner le type MIME détecté côté serveur ainsi que les métadonnées extraites. Lorsqu’une entrée non prise en charge doit faire échouer la tâche entière, définissez error_on_decline et fournissez un message indiquant à l’utilisateur ce qu’il doit modifier.
L’exemple limite délibérément la procédure à un seul fichier téléversé. Augmenter max_number_of_files rend pertinent le comportement de refus en présence de plusieurs fichiers. Privilégiez une liste d’autorisation explicite, par exemple JPEG, PNG, WebP et AVIF, lorsque l’opération en aval ne prend en charge que les images destinées aux navigateurs. Une règle image/* trop large accepte des formats que la destination peut ne pas afficher, tandis qu’une extension de fichier et une valeur MIME signalée par le navigateur ne sont que des déclarations du client. Décidez séparément si un fichier rejeté doit faire échouer une Assembly entière contenant plusieurs fichiers, disparaître d’une branche ou passer dans une autre ; il s’agit de comportements du produit, pas de simples réglages de filtre.
Vérifications peu coûteuses en premier
Rejetez les entrées inadaptées avant le début des transformations payantes ou lentes.
Propriétés détectées côté serveur
Utilisez le type MIME et les métadonnées extraits plutôt que de vous fier uniquement aux extensions.
Comportement explicite en cas de rejet
Choisissez si le refus d’un fichier met fin à la tâche ou arrête simplement son passage dans une branche.
Exporter avec des informations d’identification et des chemins que vous pouvez renouveler
Créez des ensembles d’informations d’identification de Template pour la destination de stockage et référencez leur nom depuis le Robot d’exportation. Les Assembly Instructions contiennent alors un libellé stable d’ensemble d’informations d’identification plutôt qu’une clé d’accès et un secret. La rotation de l’ensemble d’informations d’identification stocké met à jour les exécutions futures sans copier un nouveau secret dans le code source, les paramètres du navigateur ou chaque Template qui l’utilise. Utilisez un bucket S3 privé avec Block Public Access activé et Object Ownership défini sur Bucket owner enforced (ACL désactivées). Limitez l’accès AWS de l’ensemble d’informations d’identification au bucket de destination et aux préfixes nécessaires, en suivant les consignes relatives aux autorisations de /s3/store (English). Les deux exportations définissent explicitement acl: "bucket-default" pour remplacer la valeur par défaut public-read du Robot et omettre l’en-tête ACL généré. N’ajoutez pas d’en-têtes ACL ou d’octroi d’autorisations ; acl: "private" envoie toujours une ACL et est incompatible avec cette configuration du bucket. L’accès reste contrôlé par les politiques du bucket et d’IAM ; omettre l’en-tête ACL ne rend pas privé un bucket public.
Construisez les chemins de destination à partir d’identifiants validés de tenant ou de ressource, de l’identifiant de l’Assembly, du rôle de la variante et de ${unique_prefix} généré par la plateforme Transloadit. Ce préfixe unique de 33 caractères par fichier contient une barre oblique : il forme donc un sous-répertoire à deux niveaux dans la clé de stockage et évite les collisions entre les entrées de même nom au sein d’une Assembly. Attribuez à chaque fichier dérivé parallèle un segment de chemin distinct correspondant au rôle de la variante, par exemple web/ ou thumb/, afin que leurs exportations n’entrent jamais en collision sur une même clé. N’utilisez pas comme clé entière un nom de fichier téléversé non assaini et décidez du comportement d’une nouvelle tentative si l’objet existe déjà. Une exportation idempotente écrit le même objet prévu ou vérifie et réconcilie l’état de la destination avant d’en créer un autre. Enregistrez la clé de stockage finale de chaque résultat afin de pouvoir retrouver toutes les copies lors d’une suppression ou d’un remplacement ultérieurs.
Libellé de l’ensemble d’informations d’identification
Dissocie la rotation du secret du JSON du flux de travail qui le référence.
Données stables pour les chemins
Les identifiants de tenant, de ressource, d’Assembly et de variante assurent la traçabilité des sorties.
Contrat d’écrasement
Définissez si une clé de destination existante est remplacée, rejetée, versionnée ou réconciliée.
Gérer chaque exécution comme une machine à états asynchrone
Stockez un enregistrement de tâche applicative avant de lancer l’Assembly. Incluez l’acteur, le tenant, l’identifiant du fichier d’entrée, l’identifiant du Template, les champs validés, le libellé du flux de travail applicatif et une clé d’opération stable. Le libellé du flux de travail applicatif et la clé d’opération sont des identifiants exclusivement locaux, stockés dans votre propre base de données ; ils ne sont jamais envoyés à Transloadit. Ajoutez l’identifiant de l’Assembly dès qu’il est renvoyé. Cet enregistrement permet, lors des nouvelles tentatives, de vérifier si un traitement équivalent est déjà actif ou terminé, au lieu de créer une seconde exportation après un dépassement du délai d’attente.
Configurez notify_url lorsque la tâche doit se terminer en arrière-plan ; comme dans le Template ci-dessus, définissez ce paramètre dans le Template stocké afin que chaque exécution en hérite. Vérifiez la signature de la notification avec l’Auth Secret appartenant à l’Auth Key utilisée pour cette Assembly, renvoyez rapidement HTTP 200 pour une notification reçue valide et traitez les doublons de manière idempotente. Une tâche de réconciliation périodique devrait comparer les traitements actifs localement à l’Assembly Status afin qu’un callback perdu ne laisse pas un enregistrement bloqué. Surveillez la latence, la catégorie d’échec, les octets traités, les sorties et les nouvelles tentatives de webhook par libellé du flux de travail applicatif.
Clé d’opération
Empêche une nouvelle tentative de l’appelant de créer silencieusement des doublons de traitements et d’exportations.
Webhook vérifié
Authentifie les données de fin de traitement tout en permettant à la requête initiale de se terminer rapidement.
Réconciliation
Corrige l’état local lorsque des notifications sont retardées, dupliquées ou manquées.
Tester les modifications avec des données de test représentatives
La stabilité d’un flux de travail dépend des entrées utilisées pour le tester. Conservez de petits fichiers de test pour chaque format accepté, les dimensions limites, la transparence, l’orientation, l’animation, une entrée trop volumineuse et un type explicitement rejeté. Ajoutez des assertions sur le rôle de la sortie, son format, ses dimensions, son chemin de stockage et son état final, plutôt que de vérifier uniquement que l’Assembly s’est terminée. Incluez un échec de la destination et une notification dupliquée afin de tester le mécanisme de reprise avant un incident.
Consignez le comportement prévu dans la configuration de l’application ou dans le système de gestion de versions et associez ce libellé à chaque exécution. Lorsque le Template enregistré change, testez-le dans un Workspace hors production ou avec des destinations isolées, examinez le coût et les métadonnées, puis acheminez-y dans un premier temps une part limitée du trafic. Si les résultats se dégradent, réorientez les nouveaux traitements vers le comportement contrôlé précédent et mettez en cohérence l’état des Assemblies déjà en cours au lieu de supposer qu’elles se sont arrêtées.
Matrice des formats
Couvre les variations des entrées et des métadonnées que le produit s’engage à accepter.
Données de test pour les échecs
Vérifiez le comportement en cas de rejet, d’échec d’export, de réception répétée et de réexécution, ainsi qu’en cas de réussite.
Déploiement limité
Limite le coût et l’impact sur les clients pendant l’évaluation d’un flux de travail modifié avec du trafic réel.
Détails techniques à connaître
- Un Step traitant les fichiers individuellement démarre dès qu’un Step en amont nommé dans sa valeur
useémet un fichier ; seuls les Robots de fusion ou de regroupement attendent l’ensemble complet des entrées nommées. La position d’un Step dans l’objet JSON ne détermine pas l’ordre d’exécution. - Les Assembly Variables telles que
${fields.tenant_id},${assembly.id}et${file.url_name}, une version du nom du fichier courant du Step adaptée aux URL (sous forme de slug), extension comprise, sont résolues au moment de l’exécution et peuvent paramétrer les dimensions, les chemins et d’autres valeurs des Robots. Dans les exemples de chemins d’export,${assembly.id}assure l’unicité de chaque exécution, tandis que${unique_prefix}, qui contient des barres obliques, permet de distinguer les fichiers d’une même exécution. - Définir
allow_steps_overridesur false dans un Template enregistré empêche les appelants de fusionner des Steps de remplacement dans ce Template. Les champs fournis à l’exécution nécessitent toujours une validation et une autorisation côté application. - /file/filter peut comparer les propriétés des fichiers détectées par le serveur à des conditions définies dans un tableau. Une liste explicite de types MIME autorisés est plus sûre que le fait de se fier à une extension de fichier ou au type déclaré par le client.
- Les ensembles d’informations d’identification de Template conservent les secrets des destinations séparément du JSON du Template et peuvent être mis à jour sans recopier les clés dans chaque intégration.
- L’envoi des Assembly Notifications est retenté lorsque le destinataire ne renvoie pas de code de statut HTTP 2xx. Les systèmes consommateurs doivent vérifier la signature et tolérer les réceptions répétées, tardives ou dans le désordre.
Une approche pratique
- 1
Représentez les entrées requises, les fichiers dérivés, les Steps qui lisent plusieurs fichiers dérivés, les exports et les limites de propagation des défaillances.
- 2
Enregistrez et verrouillez un Template dont les entrées variables sont délibérément limitées.
- 3
Soumettez un fichier représentatif et inspectez chaque Step dans l’Assembly Status.
- 4
Ajoutez la gestion des webhooks vérifiés, une persistance idempotente, des données de test et un déploiement contrôlé.
Quand Transloadit est utile
Utilisez un Template enregistré pour relier /upload/handle, /file/filter, des Steps /image/resize parallèles et /s3/store. Verrouillez le graphe de traitement en définissant allow_steps_override sur false, transmettez des champs aux valeurs encadrées à l’exécution et rapprochez l’état de fin de traitement de celui de l’application à l’aide de l’Assembly Status et de webhooks vérifiés.
Périmètre architectural
Les Templates d’Assembly décrivent le traitement et le déplacement des fichiers. Ils ne gèrent ni les approbations produit, ni l’autorisation des tenants, ni l’état métier, ni l’historique de configuration d’une application ; conservez ces décisions dans le système qui lance et enregistre chaque tâche.
Questions fréquentes
L’ordre des Steps dans le JSON contrôle-t-il l’exécution ?
Non. Les dépendances définies par use contrôlent quand un Step peut s’exécuter. Des Steps indépendants peuvent s’exécuter en parallèle même si l’un apparaît plus loin dans l’objet.
Un Template verrouillé peut-il encore accepter des valeurs personnalisées ?
Oui. allow_steps_override: false empêche les appelants de remplacer les Steps de traitement. L’application peut toujours envoyer des champs utilisés par les variables ${fields.*}, et elle doit valider et autoriser ces valeurs.
Les clés de stockage cloud doivent-elles figurer dans les Assembly Instructions ?
Non. Stockez-les sous forme d’ensembles d’informations d’identification de Template et référencez le nom de l’ensemble depuis le Robot de stockage. Ainsi, les secrets restent hors du JSON du flux de travail et leur rotation peut se faire indépendamment.
Comment faire évoluer un flux de travail en toute sécurité ?
Conservez le libellé du flux de travail de l’application et l’historique de configuration dans votre propre système, testez les modifications avec des données de test représentatives et faites basculer le trafic de manière délibérée. Conservez suffisamment d’informations sur chaque tâche pour expliquer quel comportement a produit ses résultats.
Que se passe-t-il lorsqu’un webhook est envoyé deux fois ?
Considérez les envois répétés comme normaux. Vérifiez la signature, recherchez l’Assembly ou la clé de l’opération et veillez à ce que la même mise à jour de l’état final puisse être appliquée à nouveau sans risque, sans dupliquer les ressources ni les événements visibles par l’utilisateur.