Comment fonctionne une invocation

your code ── invoke('hello') ──▶ gateway (data plane)
                                   • checks the key and the user's token
                                   • finds the project from the host
                                   • adds x-aura-role, x-aura-user-id, x-aura-project-id
                                   │  message bus (request / reply)
                                   ▼
                           functions service
                                   • access policy: only invoke is public
                                   • reads the function, reserves one invocation of the plan quota
                                   │  HTTP
                                   ▼
                            edge runtime
                                   • loads code, limits and variables
                                   • starts an isolated V8 worker
                                   • rebuilds the request you described
                                   ▼
                             your function ── Response ──▶ back along the same path

La passerelle et le service de fonctions communiquent via un bus de messages. Un message sur ce bus a une taille limite, c'est pourquoi une requête ou une réponse supérieure à environ 256 Ko ne passe pas : voir limites.

• Un travailleur par appel. Le runtime Edge démarre un nouveau travailleur V8 isolé pour chaque appel, avec la limite de mémoire et le délai d'expiration de la fonction. Rien en mémoire ne survit d'un appel à l'autre : ne conservez pas l'état dans une variable. Utilisez votre base de données ou votre stockage.
• Le code est mis en cache pendant quelques secondes. Le runtime conserve le code et les limites d'une fonction pendant 5 secondes et les supprime lors du déploiement. Les variables sont lues à chaque appel.
• Votre demande est reconstruite. Le runtime crée la requête que vous avez décrite (method, path, headers, body) et la transmet à votre gestionnaire Deno.serve. Une fonction se comporte donc comme n'importe quel serveur HTTP.
• Le runtime applique le délai d'expiration. Lorsque timeout_secs s'écoule, il annule le travailleur ; l'appelant voit une erreur après environ ce délai.
• Les fonctions WASM s'exécutent à l'intérieur du service lui-même, avec des limites de mémoire, de temps et d'instructions. Une fonction WASM peut signaler des lignes de journal qui apparaissent dans le champ logs de la réponse ; une fonction Deno ne le peut pas.

Le service dispose de deux manières de renvoyer la réponse de votre fonction, choisies par l'en-tête de requête X-Aurabase-Invoke-Mode.

L'enveloppe existe pour qu'une réponse JSON puisse contenir le statut, les en-têtes et la durée de l'appel. Sa limite est que les octets ne peuvent pas voyager en JSON : c'est pourquoi une réponse binaire nécessite le mode brut. Le SDK choisit le mode parmi responseType.

En mode brut, le service ajoute x-aurabase-invoke-origin: function aux réponses de votre fonction. Une erreur provenant de la passerelle ou du runtime ne la transporte pas. C'est ainsi que le SDK sépare FunctionsHttpError (votre fonction a répondu) de FunctionsRelayError (la plate-forme a échoué).

Trois délais d'attente sont imbriqués afin qu'aucun ne se termine avant celui qu'il contient :

gateway 380 s  ⊃  message bus 370 s  ⊃  function timeout_secs (≤ 300 s) + margin

Le service attend le temps d'exécution pour timeout_secs plus une marge. Étant donné que le runtime annule le travailleur à timeout_secs, vous voyez normalement une erreur de la fonction à ce moment-là, et un 504 TIMEOUT uniquement si le runtime lui-même cesse de répondre. Un 504 signifie donc que la fonction a été lancée et a pu avoir des effets : ne répétez pas aveuglément un appel non idempotent.

Comptage et quota :

1. Avant l'appel, le service réserve une invocation à partir du quota du plan. Si le quota est épuisé, l'appel s'arrête ici avec 403.
2. Après l'appel, il enregistre l'invocation et sa durée en millisecondes.
3. Si l'appel échoue avant que votre fonction ne réponde, la réservation est libérée et rien n'est compté.

• Gardez chaque appel court et sans état. Pour un travail long, met en file d'attente une tâche.
• Limitez les demandes et les réponses ; placez les fichiers dans le stockage et transmettez une référence.
• Rendre les fonctions idempotentes : une nouvelle tentative de travail, une nouvelle tentative client après une erreur réseau ou une livraison cron dupliquée peuvent exécuter votre code deux fois.
• Autorisez sur les en-têtes d'identité de la plateforme, car ce sont les seules valeurs que l'appelant ne peut pas falsifier. Voir sécurité.
• Mesurez votre propre latence : chaque appel paie le démarrage d'un travailleur. Une fonction minimale a signalé duration_ms: 74 sur une pile locale.