Skip to main content
Vous consultez la documentation pour développeurs
Cette documentation est destinée aux développeurs travaillant avec la plateforme développeur Base44. Pour des informations sur les fonctions backend dans l’éditeur d’applications, consultezUtilisation des intégrations.
Les fonctions backend vous permettent d’exécuter du code backend personnalisé dans un environnement sécurisé et isolé. Utilisez les fonctions pour implémenter une logique métier qui ne devrait pas s’exécuter dans le navigateur, se connecter à des API tierces avec des identifiants protégés, traiter des webhooks ou étendre votre application avec des endpoints personnalisés. Les fonctions backend s’exécutent sur Deno, un runtime TypeScript moderne. Appelez les fonctions depuis votre frontend en utilisant le SDK, qui gère l’authentification automatiquement. Chaque fonction obtient également son propre endpoint HTTP pour les webhooks et les intégrations externes. Les fonctions peuvent également s’exécuter automatiquement en utilisant des automatisations. Planifiez l’exécution des fonctions à des heures spécifiques ou déclenchez-les en réponse à des événements de base de données comme la création, la mise à jour ou la suppression d’enregistrements.
Notez les points suivants :
  • Le déploiement des fonctions une par une n’est pas plafonné à 50. Une requête unique qui remplace toutes les fonctions de votre projet reste limitée à 50.
  • Les fonctions backend ont un temps d’exécution maximal de 5 minutes, appliqué de la même façon que la fonction soit appelée directement, déclenchée par une automatisation ou invoquée comme étape d’un workflow. Les requêtes qui dépassent cette limite sont interrompues.

Créer des fonctions

Créez des fonctions backend en tant que fichiers TypeScript dans le répertoire des fonctions de votre projet. Par défaut, le répertoire des fonctions est base44/functions/, mais vous pouvez personnaliser le chemin dans votre configuration de projet. Chaque fonction vit dans son propre sous-répertoire avec un fichier entry.ts ou entry.js :
functions
<function-name>
entry.ts
La CLI utilise le chemin du répertoire relatif à la racine des fonctions comme nom de fonction. Par exemple, functions/sendWelcomeEmail/entry.ts crée une fonction nommée sendWelcomeEmail. Vous pouvez également imbriquer des fonctions dans des sous-répertoires pour l’organisation. functions/email/send/entry.ts crée une fonction nommée email/send.

Ajouter un fichier de configuration

Pour des besoins avancés comme des noms de fonction personnalisés ou des automatisations, ajoutez un fichier function.jsonc :
functions
<function-name>
entry.ts
function.jsonc
Le fichier de configuration définit le nom de la fonction et le point d’entrée :

entry.ts

Le fichier de code contient la logique de votre fonction. Une fonction traite une requête entrante et retourne un objet Response. Exportez votre handler comme export par défaut :

Plusieurs fichiers par fonction

Une fonction ne se limite pas à un seul entry.ts. Répartissez la logique dans plusieurs fichiers du répertoire de la fonction et importez-les avec des chemins relatifs. Chaque fichier .js, .ts, .json et .jsonc du répertoire de la fonction est déployé avec la fonction.
functions
process-order
entry.ts
validate.ts
types.ts
Les imports relatifs sont résolus au moment du déploiement. Un import qui pointe vers un fichier non déployé avec la fonction, comme un fichier du répertoire d’une autre fonction, échoue au déploiement.

Partager du code entre les fonctions

Pour réutiliser du code entre les fonctions, placez-le dans un répertoire shared à l’intérieur de votre dossier base44/. Quand vous déployez une fonction, la CLI envoie le répertoire shared avec elle, et le serveur n’empaquette que les fichiers partagés que cette fonction importe. Chaque fonction est déployée avec sa propre copie du code partagé qu’elle utilise. Cela signifie que :
  • Toute fonction peut importer depuis shared avec un chemin relatif.
  • Des fonctions différentes peuvent exécuter des versions différentes du même fichier partagé. Modifier un fichier partagé puis déployer une seule fonction ne met à jour que la copie de cette fonction. Les autres gardent l’ancienne version jusqu’à ce que vous les redéployiez. Pour appliquer une modification partagée partout, exécutez base44 functions deploy sans argument afin de redéployer toutes les fonctions en une fois.
base44
shared
response.ts
functions
greet
entry.ts
farewell
entry.ts
Les imports relatifs peuvent atteindre base44/shared/, mais ne peuvent pas sortir de base44/. Pour utiliser du code situé hors de base44/, déplacez-le dans base44/shared/, ou importez-le avec un spécificateur npm: ou jsr:.

Tester localement

Exécutez vos fonctions localement avec base44 dev pour tester les changements sans déployer. Consultez Développement local pour plus de détails.

Déployer les fonctions

Déployez les fonctions avec functions deploy ou deploy pour pousser toutes les ressources du projet en une fois. Vous pouvez déployer des fonctions spécifiques par nom avec functions deploy <names...>, ou utiliser --force pour supprimer les fonctions distantes non trouvées localement. Pour télécharger les fonctions déployées vers votre projet local, utilisez functions pull. Pour voir ce qui est actuellement déployé, utilisez functions list.

Appeler les fonctions

Appelez les fonctions backend depuis votre frontend en utilisant le SDK, ou via HTTP pour les webhooks et les intégrations externes.

Via le SDK

Utilisez base44.functions.invoke() pour appeler les fonctions depuis votre frontend. Le SDK gère l’authentification automatiquement, en passant les identifiants de l’utilisateur actuel à votre fonction.

Via HTTP

Chaque fonction déployée obtient un endpoint HTTP à :
Ceci est utile pour :
  • Webhooks : recevoir des rappels de services externes comme Stripe ou GitHub.
  • Intégrations externes : permettre à d’autres systèmes d’interagir avec votre application.
  • Tests : appeler les fonctions directement avec des outils comme cURL ou Postman.
Exemple d’utilisation
Lors de l’appel de fonctions via HTTP direct (comme cURL ou les webhooks), il n’y a pas de contexte utilisateur authentifié. Utilisez asServiceRole pour toutes les opérations dans ces cas.

Utiliser le SDK dans les fonctions

À l’intérieur de vos fonctions backend, vous pouvez accéder aux données, à l’authentification et aux intégrations de votre application via le SDK Base44. Utilisez createClientFromRequest() pour créer un client à partir de la requête entrante. Le contexte d’authentification dépend de la manière dont la fonction a été appelée :
  • Lorsqu’appelée via le SDK depuis votre frontend : l’authentification de l’utilisateur est passée automatiquement. Vous pouvez accéder à l’utilisateur actuel avec base44.auth.me() et effectuer des opérations avec ses permissions. Pour lire ou écrire des données sans appliquer les règles d’accès des entités, utilisez asServiceRole.
  • Lorsqu’appelée via HTTP direct (cURL, webhooks, services externes) : il n’y a pas d’utilisateur authentifié, utilisez donc asServiceRole pour toutes les opérations.

API d’exécution

Base44 fournit un module intégré base44:runtime avec des utilitaires de plateforme pour vos fonctions. Importez-le directement, sans installation :
Le module exporte deux utilitaires :
  • waitUntil() : maintient la fonction active pour terminer un travail en arrière-plan après l’envoi d’une réponse.
  • secrets : lit les secrets de votre application à l’exécution avec secrets.get().

Exécuter un travail en arrière-plan après la réponse

Utilisez waitUntil() pour maintenir votre fonction active après l’envoi d’une réponse. Passez-lui une promesse, et la fonction continue de s’exécuter jusqu’à ce que cette promesse soit résolue. Vous pouvez ainsi répondre rapidement, puis terminer des tâches comme la journalisation, les notifications ou les webhooks sortants.
waitUntil() retourne la promesse que vous lui passez, vous pouvez donc la composer ou l’attendre plus loin dans le même handler.
Le travail en arrière-plan est exécuté au mieux. Son achèvement et ses nouvelles tentatives ne sont pas garantis, alors ne vous y fiez pas pour des opérations critiques qui ne doivent pas être perdues.

Lire les secrets

Utilisez secrets.get() pour lire les variables d’environnement de votre application à l’exécution. La méthode retourne la valeur sous forme de chaîne, ou undefined si le secret n’est pas défini :
Appelez secrets.get() dans votre handler, et non au niveau supérieur de votre module. Les secrets sont résolus à chaque requête : une lecture au chargement du module, avant toute requête, retourne undefined. Configurez les secrets depuis la CLI avec secrets set.

Se connecter aux API tierces

Les fonctions backend sont l’une des plusieurs façons de se connecter aux API tierces. Elles sont idéales lorsque vous avez besoin d’un contrôle total sur les requêtes ou que vous souhaitez stocker des clés API en toute sécurité en tant que variables d’environnement. Utilisez secrets set pour configurer les variables d’environnement depuis la CLI.

Voir les logs

Pendant le développement local, la sortie des fonctions est affichée directement dans votre terminal sans avoir besoin de la commande logs. Pour les fonctions déployées, voyez les logs avec la commande logs. Les logs incluent la sortie console, les erreurs et les informations de temporisation. Vous pouvez filtrer par nom de fonction ou plage de temps. Si vous utilisez un agent de codage IA, le skill base44-troubleshooter peut récupérer et analyser automatiquement ces logs.

Types TypeScript

Générez des types TypeScript à partir de vos configurations de fonction pour obtenir la sécurité des types et l’autocomplétion des noms de fonctions dans votre code SDK. Apprenez-en plus sur les types dynamiques.

Voir aussi

Cette page a été traduite par IA. Pour les informations les plus précises et à jour, consultez la version anglaise.