Créer un pipeline d'envoi et d'optimisation d'images

Ce guide crée un pipeline volontairement simple mais proche de la production. Le navigateur ne reçoit jamais un secret Spaces. Il demande une URL d’envoi temporaire à votre application App Platform, envoie l’original vers une clé privée, puis demande à l’application de démarrer une Function sécurisée. La Function crée des variantes WebP de 400, 800 et 1600 pixels et renvoie leurs URL CDN.

Utilisez-le pour des avatars, annonces, portfolios ou autres charges synchrones modestes. Ce n’est pas un système de comptes, d’antivirus ou de file durable. Le projet de départ accepte JPEG, PNG et WebP jusqu’à 10 Mo ; ajoutez authentification et quotas avant d’accepter du trafic non fiable.

Pour le premier test, utilisez une image d’au moins 1600 pixels de large après orientation, sous 10 Mo. Le traitement n’agrandit pas les images : un original plus petit peut donner des fichiers de noms différents mais de même largeur. Vérifiez les dimensions en plus des trois URL.

La frontière importante est l’envoi direct vers le stockage. Faire passer une image complète par une route API consomme inutilement la bande passante de l’application. POSTez plutôt les métadonnées à /api/uploads, recevez une URL PUT présignée de cinq minutes, puis envoyez directement vers Spaces. La réponse contient un UUID imprévisible, jamais le nom de fichier original.

Après le PUT, le navigateur POSTe cet UUID vers /api/images/:id/process sur le même domaine. Cette route appelle la Function avec son secret web. Ni l’URL de la Function ni la valeur X-Require-Whisk-Auth ne parviennent au navigateur.

Créez un bucket Spaces standard dans la même région que l’application et activez son CDN. Gardez la liste de fichiers désactivée. L’application écrit les originaux avec une ACL privée et écrit les fichiers générés avec une ACL public-read. Vous obtenez ainsi un stockage unique sans exposer accidentellement le chemin d’envoi.

Configurez CORS pour n’autoriser PUT que depuis l’origine App Platform déployée et pour l’en-tête Content-Type. N’utilisez pas une origine générique en production.

Clonez le projet compagnon et examinez .env.example pour préparer les variables chiffrées du déploiement. Le serveur local ci-dessous est facultatif. Pour tester le traitement localement, déployez d'abord la Function à l'étape suivante, puis copiez son URL et les autres valeurs dans .env.local. Les clés existent seulement comme variables chiffrées App Platform et dans la configuration de Functions ; ne leur donnez jamais le préfixe NEXT_PUBLIC_.

Le fichier project.yml rend l’action accessible sur le web tout en exigeant le même secret via X-Require-Whisk-Auth. Utilisez une compilation distante pour Sharp : les dépendances natives doivent être compilées pour le runtime Functions.

Utilisez App Platform pour déployer les deux composants depuis GitHub. Vous pouvez effectuer ce déploiement dans le navigateur, sans installer doctl. Le composant Functions est construit à distance par App Platform, y compris les dépendances natives de Sharp.

Le service web et la Function utilisent les variables SPACES_BUCKET, SPACES_REGION, SPACES_KEY, SPACES_SECRET et SPACES_CDN_BASE_URL. Configurez aussi FUNCTION_AUTH_TOKEN avec le même secret long dans les deux composants. Seul le service web reçoit FUNCTION_URL. Gardez toutes ces valeurs dans les variables chiffrées du tableau de bord.

La révision 5b8eafa du dépôt contient le service web et l’action Functions avec index.js et ses dépendances dans functions/packages/image/process/. Vérifiez cette structure dans votre copie avant le déploiement. Les tests de compilation et de traitement d’image passent ; le déploiement avec vos identifiants reste à vérifier.

Ouvrez l’application déployée, choisissez un JPEG, PNG ou WebP inférieur à 10 Mo et envoyez-le. La page indique d’abord que l’original est arrivé dans Spaces, puis affiche les URL des variantes. Vérifiez que uploads/<uuid>/original reste privé et que seules les trois clés sous images/<uuid>/ sont publiques.

Ouvrez une URL CDN dans une fenêtre privée. Elle doit fonctionner sans chaîne de requête signée. Si ce n’est pas le cas, vérifiez l’ACL de l’objet, puis l’endpoint CDN. Ne rendez jamais uploads/ public juste pour réussir ce test.

La Function reçoit un petit objet JSON avec un identifiant, jamais les octets d’image. Le traitement reste toutefois synchrone. DigitalOcean Functions impose des limites de mémoire, délai, taille de fonction et requête/réponse. Ajustez mémoire et délai à vos images testées, puis refusez les entrées hors de cette enveloppe.

Pour les transformations longues, un gros volume, la vidéo ou les reprises, utilisez une file et un worker. Ajoutez vérification du contenu, limitation de débit, autorisation, suppression planifiée et antivirus avant de traiter ce projet comme une plateforme de contenu utilisateur.