Le piège le plus courant auquel les gens sont confrontés lorsqu'ils travaillent avec la consommation de webhook et les fonctions sans serveur est que la fonction dure trop longtemps. Cela entraîne soit un coût très élevé pour la fonction, soit un échec complet car le POST du webhook expire. Il y a quelques choses que vous pouvez faire pour atténuer ces problèmes.

Les consommateurs de webhook devraient fonctionner de manière asynchrone. Les données doivent être ingérées aussi rapidement que possible, puis traitées. L'erreur de conception courante est de tenter de traiter les données en temps réel au fur et à mesure de leur arrivée. Cela fonctionne tant que les données sont de taille constante et petite, mais si la taille des données peut augmenter ou être incohérente, il est préférable de s'assurer que les données sont reçues et que la demande HTTP est répondue afin que les expirations ne se produisent pas.

Une autre chose qui peut aider à atténuer les processus de longue durée est de stocker les données publiées et d'utiliser la fonction sans serveur pour démarrer un processus conteneurisé en utilisant quelque chose comme Azure Container Services (AKS) pour gérer les parties de longue durée. En utilisant ce design, la fonction sans serveur devrait déclencher et oublier le conteneur, laissant le conteneur publier ses résultats soit dans un journal, soit dans un autre service de notification de votre choix. Cela garde la fonction sans serveur aussi brève que possible tout en permettant un traitement compliqué de se produire.