Connecter votre application à l'émulateur Cloud Functions

Avant de connecter votre application à l'émulateur Cloud Functions, assurez-vous que vous compreniez le workflow global Firebase Local Emulator Suite, et que vous installiez et configuriez le Local Emulator Suite et consultiez ses commandes CLI.

Choisir un projet Firebase

Le Firebase Local Emulator Suite émule des produits pour un seul projet Firebase.

Pour sélectionner le projet à utiliser, avant de démarrer les émulateurs, exécutez firebase use dans votre répertoire de travail dans la CLI. Vous pouvez également transmettre l'indicateur --project à chaque commande d'émulateur.

Local Emulator Suite est compatible avec l'émulation de projets Firebase réels et de projets de démonstration.

Type de projet Fonctionnalités Utilisation avec des émulateurs
Réel

Un projet Firebase réel est un projet que vous avez créé et configuré (très probablement via la Firebase console).

Les projets réels disposent de ressources actives, telles que des instances de base de données, des buckets de stockage, des fonctions ou toute autre ressource que vous avez configurée pour ce projet Firebase.

Lorsque vous travaillez avec des projets Firebase réels, vous pouvez exécuter des émulateurs pour tout ou partie des produits compatibles.

Pour tous les produits que vous n'émulez pas, vos applications et votre code interagiront avec la ressource active (instance de base de données, bucket de stockage, fonction, etc.).

Démonstration

Un projet Firebase de démonstration ne comporte aucune configuration Firebase réelle ni aucune ressource active. Ces projets sont généralement accessibles via des ateliers de programmation ou d'autres tutoriels.

Les ID de projet pour les projets de démonstration sont précédés du préfixe demo-.

Lorsque vous travaillez avec des projets Firebase de démonstration, vos applications et votre code interagissent avec des émulateurs uniquement. Si votre application tente d'interagir avec une ressource pour laquelle aucun émulateur n'est en cours d'exécution, ce code échoue.

Nous vous recommandons d'utiliser des projets de démonstration dans la mesure du possible. Voici quelques-uns de ses avantages :

  • Configuration plus facile, car vous pouvez exécuter les émulateurs sans jamais créer de projet Firebase
  • Sécurité renforcée, car si votre code appelle accidentellement des ressources non émulées (de production), il n'y a aucun risque de modification des données, d'utilisation et de facturation
  • Meilleure prise en charge hors connexion, car il n'est pas nécessaire d'accéder à Internet pour télécharger la configuration de votre SDK.
Cloud FunctionsSecurity RulesAuthentication

Instrumenter votre application pour qu'elle communique avec les émulateurs

Instrumenter votre application pour les fonctions appelables

Si vos activités de prototype et de test impliquent des fonctions backend appelables, configurez l'interaction avec l'émulateur Cloud Functions for Firebase comme suit :

Kotlin
// 10.0.2.2 is the special IP address to connect to the 'localhost' of
// the host computer from an Android emulator.
val functions = Firebase.functions
functions.useEmulator("10.0.2.2", 5001)
Java
// 10.0.2.2 is the special IP address to connect to the 'localhost' of
// the host computer from an Android emulator.
FirebaseFunctions functions = FirebaseFunctions.getInstance();
functions.useEmulator("10.0.2.2", 5001);
Swift
Functions.functions().useEmulator(withHost: "localhost", port: 5001)

Web

import { getApp } from "firebase/app";
import { getFunctions, connectFunctionsEmulator } from "firebase/functions";

const functions = getFunctions(getApp());
connectFunctionsEmulator(functions, "127.0.0.1", 5001);

Web

firebase.functions().useEmulator("127.0.0.1", 5001);

Instrumenter votre application pour l'émulation de fonctions HTTPS

Chaque fonction HTTPS de votre code sera diffusée à partir de l'émulateur local au format d'URL suivant :

http://$HOST:$PORT/$PROJECT/$REGION/$NAME

Par exemple, une simple fonction helloWorld avec le port et la région d'hôte par défaut serait diffusée à l'adresse suivante :

https://localhost:5001/$PROJECT/us-central1/helloWorld

Instrumenter votre application pour l'émulation de fonctions de file d'attente des tâches

L'émulateur configure automatiquement les files d'attente des tâches émulées en fonction des définitions de déclencheur, et le SDK Admin redirige les requêtes mises en file d'attente vers l'émulateur s'il détecte qu'il est en cours d'exécution via la variable d'environnement CLOUD_TASKS_EMULATOR_HOST.

Notez que le système de répartition utilisé en production est plus complexe que celui implémenté dans l'émulateur. Vous ne devez donc pas vous attendre à ce que le comportement émulé reflète précisément les environnements de production. Les paramètres de l'émulateur fournissent des limites supérieures au taux de répartition et de nouvelle tentative des tâches.

Instrumenter votre application pour l'émulation de fonctions déclenchées en arrière-plan

L'émulateur Cloud Functions est compatible avec les fonctions déclenchées en arrière-plan à partir des sources suivantes :

  • Émulateur Realtime Database
  • Émulateur Cloud Firestore
  • Authentication émulateur
  • Émulateur Pub/Sub
  • Émulateur d'alertes Firebase

Pour déclencher des événements en arrière-plan, modifiez les ressources backend à l'aide de la Emulator Suite UI, ou en connectant votre application ou votre code de test aux émulateurs à l'aide du SDK pour votre plate-forme.

Tester les gestionnaires d'événements personnalisés émis par les extensions

Pour les fonctions que vous implémentez afin de gérer les Firebase Extensions événements personnalisés avec Cloud Functions v2, l'émulateur Cloud Functions est associé à l'émulateur Eventarc pour prendre en charge les déclencheurs Eventarc.

Pour tester les gestionnaires d'événements personnalisés pour les extensions qui émettent des événements, vous devez installer les Cloud Functions et Eventarc émulateurs.

L'environnement d'exécution Cloud Functions définit la variable d'environnement EVENTARC_EMULATOR sur localhost:9299 dans le processus actuel si l'émulateur Eventarc est en cours d'exécution. Les Firebase Admin SDKs se connectent automatiquement à l'émulateur Eventarc lorsque la variable d'environnement EVENTARC_EMULATOR est définie. Vous pouvez modifier le port par défaut, comme indiqué dans la section Configurer Local Emulator Suite.

Lorsque les variables d'environnement sont correctement configurées, le Firebase Admin SDK envoie automatiquement des événements à l'émulateur Eventarc. À son tour, l'émulateur Eventarc rappelle l'émulateur Cloud Functions pour déclencher tous les gestionnaires enregistrés.

Vous pouvez consulter les journaux des fonctions dans l'interface utilisateur de la suite d'émulateurs pour obtenir des informations sur l'exécution du gestionnaire.Emulator Suite UI

Configurer un environnement de test local

Si vos fonctions reposent sur une configuration d'environnement basée sur dotenv , vous pouvez émuler ce comportement dans votre environnement de test local.

Lorsque vous utilisez un émulateur Cloud Functions local, vous pouvez remplacer les variables d'environnement de votre projet en configurant un fichier .env.local. Le contenu de .env.local est prioritaire sur .env et sur le fichier .env spécifique au projet.

Par exemple, un projet peut inclure ces trois fichiers contenant des valeurs légèrement différentes pour le développement et les tests locaux :

.env .env.dev .env.local
PLANET=Earth

AUDIENCE=Humans

AUDIENCE=Dev Humans AUDIENCE=Local Humans

Lorsqu'il est démarré dans le contexte local, l'émulateur charge les variables d'environnement comme suit :

  $ firebase emulators:start
  i  emulators: Starting emulators: functions
  # Starts emulator with following environment variables:
  #  PLANET=Earth
  #  AUDIENCE=Local Humans

Secrets et identifiants dans l'émulateur Cloud Functions

L'émulateur Cloud Functions est compatible avec l'utilisation de secrets pour stocker des informations de configuration sensibles et y accéder. Par défaut, l'émulateur tente d'accéder à vos secrets de production à l'aide des identifiants par défaut de l'application. Dans certaines situations, comme les environnements d'intégration continue, l'émulateur peut ne pas pouvoir accéder aux valeurs secrètes en raison de restrictions d'autorisation.

Comme pour la prise en charge des variables d'environnement par Cloud Functions émulateur, vous pouvez remplacer les valeurs des secrets en configurant un fichier .secret.local. Cela vous permet de tester facilement vos fonctions localement, en particulier si vous n'avez pas accès à la valeur secrète.

Quels sont les autres outils de test de Cloud Functions ?

L'émulateur Cloud Functions est complété par d'autres outils de prototype et de test :

  • Le shell Cloud Functions, qui permet de prototyper et de développer des fonctions interactives et itératives. Le shell utilise l'émulateur Cloud Functions avec une interface de type REPL pour le développement. Aucune intégration avec les Cloud Firestore ou Realtime Database émulateurs n'est fournie. À l'aide du shell, vous simulez des données et effectuez des appels de fonction pour simuler une interaction avec des produits que la Local Emulator Suite ne prend pas en charge actuellement : Analytics, Remote Config et Crashlytics.
  • Le SDK Firebase Test pour Cloud Functions, un framework Node.js avec mocha pour le développement de fonctions. En effet, le SDK Test Cloud Functions fournit une automatisation en plus du shell Cloud Functions.

Pour en savoir plus sur le shell Cloud Functions et le SDK Test Cloud Functions consultez Tester des fonctions de manière interactive et Tests unitaires de Cloud Functions.

Différences entre l'émulateur Cloud Functions et la production

L'Cloud Functions émulateur est assez proche de l'environnement de production pour la majorité des cas d'utilisation. Nous avons déployé des efforts considérables pour nous assurer que tout ce qui se trouve dans l'environnement d'exécution Node est aussi proche que possible de la production. Toutefois, l'émulateur n'imite pas l'environnement de production conteneurisé complet. Par conséquent, bien que le code de votre fonction s'exécute de manière réaliste, d'autres aspects de votre environnement (par exemple, les fichiers locaux, le comportement après les plantages de fonctions, etc.) diffèrent.

Cloud IAM

La suite d'émulateurs Firebase ne tente pas de répliquer ni de respecter aucun comportement lié à IAM pour l'exécution. Les émulateurs respectent les règles de sécurité Firebase fournies, mais dans les situations où IAM serait normalement utilisé, par exemple pour définir le compte de service d'appel Cloud Functions et donc les autorisations, l'émulateur n'est pas configurable et utilise le compte disponible à l'échelle mondiale sur votre machine de développement, comme lors de l'exécution directe d'un script local.

Restrictions de mémoire et de processeur

L'émulateur n'applique pas de restrictions de mémoire ni de processeur à vos fonctions. Toutefois, l'émulateur est compatible avec le délai d'attente des fonctions via l'argument d'exécution timeoutSeconds.

Notez que le temps d'exécution des fonctions peut différer de celui de la production lorsque les fonctions sont exécutées dans l'émulateur. Nous vous recommandons, une fois que vous avez conçu et testé des fonctions avec l'émulateur, d'exécuter des tests limités en production pour confirmer les temps d'exécution.

Planifier les différences entre les environnements locaux et de production

Étant donné que l'émulateur s'exécute sur votre machine locale, il dépend de votre environnement local pour les applications, les programmes intégrés et les utilitaires.

Sachez que votre environnement local pour le Cloud Functions développement peut différer de l'environnement de production Google :

  • Les applications que vous installez localement pour simuler l'environnement de production (par exemple, ImageMagick à partir de ce tutoriel) peuvent avoir un comportement différent de celui de la production, en particulier si vous avez besoin de différentes versions ou si vous développez dans un environnement non Linux. Envisagez de déployer votre propre copie binaire du programme manquant avec le déploiement de votre fonction.

  • De même, les utilitaires intégrés (par exemple, les commandes shell telles que ls, mkdir) peuvent différer des versions disponibles en production, en particulier si vous développez dans un environnement non Linux (par exemple, macOS). Vous pouvez résoudre ce problème en utilisant des alternatives Node uniquement aux commandes natives, ou en créant des binaires Linux à regrouper avec votre déploiement.

Nouvelle tentative

L'émulateur Cloud Functions n'est pas compatible avec les nouvelles tentatives de fonctions en cas d'échec.

Et maintenant ?