Connectez votre application à l'émulateur Cloud Functions

Avant de connecter votre application à l'émulateur Cloud Functions, assurez-vous de bien comprendre le flux de travail global de Firebase Local Emulator Suite , d' installer et de configurer Local Emulator Suite et de consulter ses commandes CLI .

Choisissez un projet Firebase

La suite Firebase Local Emulator émule les produits pour un seul projet Firebase.

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

Local Emulator Suite prend en charge l'émulation de projets Firebase réels et de projets de démonstration .

Type de projet Caractéristiques Utiliser avec des émulateurs
Réel

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

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

Lorsque vous travaillez avec de vrais projets Firebase, vous pouvez exécuter des émulateurs pour tout ou partie des produits pris en charge.

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, compartiment de stockage, fonction, etc.).

Démo

Un projet de démonstration Firebase n'a pas de véritable configuration Firebase ni de ressources actives. Ces projets sont généralement accessibles via des ateliers de programmation ou d'autres didacticiels.

Les ID de projet pour les projets de démonstration portent le préfixe demo- .

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

Nous vous recommandons d'utiliser des projets de démonstration dans la mesure du possible. Les avantages comprennent :

  • Configuration plus simple, puisque 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 (de production) non émulées, il n'y a aucune chance de modification, d'utilisation et de facturation des données.
  • Meilleure prise en charge hors ligne, puisqu'il n'est pas nécessaire d'accéder à Internet pour télécharger la configuration de votre SDK.

Instrumentez votre application pour communiquer avec les émulateurs

Instrumentez 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 pour Firebase comme ceci :

Kotlin+KTX
// 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);
Rapide
Functions.functions().useFunctionsEmulator(origin: "http://127.0.0.1:5001")

Web modular API

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

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

Web namespaced API

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

Instrumentez votre application pour l’émulation des fonctions HTTPS

Chaque fonction HTTPS de votre code sera servie à partir de l'émulateur local en utilisant le format d'URL suivant :

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

Par exemple, une simple fonction helloWorld avec le port hôte et la région par défaut serait servie à :

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

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

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

  • Émulateur de base de données en temps réel
  • Émulateur Cloud Firestore
  • Émulateur d'authentification
  • Émulateur Pub/Sub

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

Gestionnaires de tests pour les événements personnalisés émis par les extensions

Pour les fonctions que vous implémentez pour gérer les événements personnalisés des extensions Firebase avec Cloud Functions v2, l'émulateur Cloud Functions s'associe à 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 émulateurs Cloud Functions et Eventarc.

Le runtime Cloud Functions définit la variable d'environnement EVENTARC_EMULATOR sur localhost:9299 dans le processus en cours si l'émulateur Eventarc est en cours d'exécution. Les SDK Firebase Admin 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 Configure Local Emulator Suite .

Lorsque les variables d'environnement sont correctement configurées, le SDK Firebase Admin envoie automatiquement les é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 d’Emulator Suite pour plus de détails sur l’exécution du gestionnaire.

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 a priorité sur .env et le fichier .env spécifique au projet.

Par exemple, un projet pourrait 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
PLANÈTE=Terre

PUBLIC = Humains

AUDIENCE=Développeurs Humains AUDIENCE = Humains locaux

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

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

Secrets et informations d'identification dans l'émulateur Cloud Functions

L'émulateur Cloud Functions prend en charge l'utilisation de secrets pour stocker et accéder aux informations de configuration sensibles . Par défaut, l'émulateur tentera d'accéder à vos secrets de production en utilisant les informations d'identification par défaut de l'application . Dans certaines situations telles que les environnements CI, l'émulateur peut ne pas parvenir à accéder aux valeurs secrètes en raison de restrictions d'autorisation.

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

Quels autres outils existent pour tester les fonctions Cloud ?

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

  • Le shell Cloud Functions, qui permet le prototypage et le développement de fonctions interactives et itératives. Le shell utilise l'émulateur Cloud Functions avec une interface de style REPL pour le développement. Aucune intégration avec les émulateurs Cloud Firestore ou Realtime Database 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 suite Local Emulator ne prend actuellement pas en charge : Analytics, Remote Config et Crashlytics.
  • Le SDK de test Firebase pour Cloud Functions, un framework Node.js avec moka pour le développement de fonctions. En effet, le SDK de test Cloud Functions fournit une automatisation au-dessus du shell Cloud Functions.

Vous pouvez en savoir plus sur le shell Cloud Functions et le SDK de test Cloud Functions dans Tester les fonctions de manière interactive et Test unitaire de Cloud Functions .

En quoi l'émulateur Cloud Functions diffère de la production

L'émulateur Cloud Functions est assez proche de l'environnement de production pour la majorité des cas d'utilisation. Nous avons déployé un travail considérable pour garantir que tout ce qui se trouve dans le runtime Node soit aussi proche que possible de la production. Cependant, l'émulateur n'imite pas l'environnement de production entièrement conteneurisé. Ainsi, même si votre code de fonction s'exécutera de manière réaliste, d'autres aspects de votre environnement (c'est-à-dire les fichiers locaux, le comportement après un crash de fonctions, etc.) seront différents.

IAM dans le cloud

La suite d'émulateurs Firebase ne tente pas de répliquer ou de respecter tout comportement lié à IAM lors de son exécution. Les émulateurs adhèrent aux 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 appelant Cloud Functions et donc les autorisations, l'émulateur n'est pas configurable et utilisera le compte disponible mondialement sur votre ordinateur de développeur. similaire à 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 ou de processeur pour vos fonctions. Cependant, l'émulateur prend en charge les fonctions d'expiration 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 d'exécuter des tests limités en production, après avoir conçu et testé les fonctions avec l'émulateur, pour confirmer les temps d'exécution.

Planification des différences dans les environnements locaux et de production

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

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

  • Les applications que vous installez localement pour simuler l'environnement de production (par exemple ImageMagick de ce didacticiel ) peuvent avoir un comportement différent de celui de la production, surtout si vous avez besoin de versions différentes ou si vous développez dans un environnement non Linux. Pensez à déployer votre propre copie binaire du programme manquant parallèlement à votre déploiement de fonctions.

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

Réessayer

L'émulateur Cloud Functions ne prend pas en charge les nouvelles tentatives de fonctions en cas d'échec.

Et ensuite ?