Connecter votre application à l'émulateur Cloud Functions

Avant de connecter votre application à l'émulateur Cloud Functions, assurez-vous que vous comprenez le workflow Firebase Local Emulator Suite global, et que vous installez et configurez Local Emulator Suite et examinez ses commandes CLI.

Sélectionner un projet Firebase

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 sur chaque émulateur .

Local Emulator Suite accepte l'émulation de projets Firebase réels et demo.

Type de projet Fonctionnalités Utiliser avec des émulateurs
Situation réelle

Un projet Firebase réel est un projet que vous avez créé et configuré via la console Firebase).

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

Lorsque vous travaillez sur de vrais projets Firebase, vous pouvez exécuter des émulateurs pour ou tous les produits pris en charge.

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

Démo

Un projet Firebase de démonstration n'a pas de configuration Firebase réelle. aucune ressource active. Pour accéder à ces projets, vous devez généralement utiliser des ateliers de programmation ou d'autres tutoriels.

Les ID des projets de démonstration comportent le préfixe demo-.

Lorsque vous utilisez des projets Firebase de démonstration, vos applications et votre code interagissent avec émulateurs uniquement. Si votre application tente d'interagir avec une ressource pour lequel un émulateur n'est pas en cours d'exécution, le code échouera.

Nous vous recommandons d'utiliser des projets de démonstration autant que possible. Voici quelques-uns de ses avantages :

  • Configuration simplifiée, puisque vous pouvez exécuter les émulateurs sans avoir à créer Projet Firebase
  • Sécurité renforcée, car si votre code appelle accidentellement des applications non émulées (production), il n'y a aucun risque de modification des données, d'utilisation ni de facturation.
  • Meilleure compatibilité hors connexion, car vous n'avez pas besoin d'accéder à Internet pour télécharger la configuration de votre SDK.

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

Instrumenter votre application pour les fonctions appelables

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

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);
Swift
Functions.functions().useFunctionsEmulator(origin: "http://127.0.0.1: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 à l'aide du format d'URL suivant :

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

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

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

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

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

Notez que le système de répartition utilisé en production est plus complexe que est implémentée dans l'émulateur. Vous ne devez donc pas vous attendre à des émulations de mise en miroir pour mettre en miroir précisément les environnements de production. Les paramètres de la section l'émulateur impose des limites supérieures à la fréquence à laquelle les tâches sont distribuées puis retenté l'opération.

Instrumenter votre application pour l'émulation des 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
  • Émulateur Authentication
  • Émulateur Pub/Sub
  • Émulateur Firebase Alerts

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

Tester les gestionnaires 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 Firebase Extensions avec Cloud Functions v2, l'émulateur Cloud Functions s'associe au Émulateur Eventarc compatible 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.

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

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

Vous pouvez consulter les journaux Functions dans Emulator Suite UI pour en savoir plus sur l'exécution du gestionnaire.

Configurer un environnement de test local

Si vos fonctions reposent sur des applications configuration de l'environnement, vous pouvez émuler ce comportement dans votre environnement de test local.

Lorsque vous utilisez un émulateur Cloud Functions local, vous pouvez ignorer l'environnement pour votre projet en configurant un fichier .env.local. Contenu de .env.local sont prioritaires sur .env et sur le fichier .env spécifique au projet.

Par exemple, un projet peut inclure ces trois fichiers contenant des des valeurs différentes pour le développement et les tests en local:

.env .env.dev .env.local
PLANÈTE=Terre

AUDIENCE=humains

AUDIENCE=Ingénieurs en développement AUDIENCE=Employés locaux

Lorsqu'il est démarré en contexte local, l'émulateur charge l'environnement comme indiqué ci-dessous:

  $ 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 prend en charge 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 (par exemple, dans les environnements CI), l'émulateur peut ne pas parvenir à accéder secrètes en raison de restrictions d'autorisation.

Comme pour la compatibilité de l'émulateur Cloud Functions avec les variables d'environnement, vous pouvez remplacer les valeurs des secrets en configurant un fichier .secret.local. Ainsi, vous permet de tester facilement vos fonctions localement, surtout si vous n'avez pas accès à la valeur "secret".

Quels sont les autres outils disponibles pour tester Cloud Functions ?

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

  • Le shell Cloud Functions, qui permet d'utiliser des fonctions interactives et itératives le prototypage et le développement. Le shell utilise l'émulateur Cloud Functions une interface de type REPL pour le développement. Aucune intégration avec les émulateurs Cloud Firestore ou Realtime Database n'est fournie. À l'aide du shell, simuler des données et effectuer des appels de fonction pour simuler une interaction avec les produits le Local Emulator Suite n'est actuellement pas compatible avec: Analytics, Remote Config et Crashlytics.
  • SDK Firebase Test pour Cloud Functions, Node.js avec framework Mocha pour le développement de fonctions. En effet, le SDK de test Cloud Functions fournit l'automatisation au-dessus du shell Cloud Functions.

En savoir plus sur l'interface système Cloud Functions et le SDK de test Cloud Functions dans la section Tester des fonctions de manière interactive. Tests unitaires de Cloud Functions

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

L'émulateur Cloud Functions est assez proche de l'environnement de production pour la majorité des cas d'utilisation. Nous nous sommes efforcés de veiller à ce que dans l'environnement d'exécution du nœud est aussi proche que possible de la production. Toutefois, l'émulateur n'imite pas l'environnement de production conteneurisé complet, Ainsi, même si le code de votre fonction s'exécute en réalité, d'autres aspects (fichiers locaux, comportement en cas de plantage d'une fonction, etc.) diffèrent.

Cloud IAM

La suite d'émulateurs Firebase ne tente pas de reproduire ni de respecter le comportement lié à l'IAM pour l'exécution. Les émulateurs respectent les règles de sécurité Firebase fournies, mais dans les cas où IAM est normalement utilisé, par exemple pour définir le compte de service d'appel de Cloud Functions et donc les autorisations, l'émulateur n'est pas configurable et utilisera le compte disponible dans le monde entier sur votre ordinateur de développement, comme si vous exécutiez directement un script local.

Restrictions liées à la mémoire et au processeur

L'émulateur n'applique pas de restrictions de mémoire ou de processeur pour votre fonctions. Toutefois, l'émulateur prend en charge le délai d'expiration des fonctions via le Argument d'exécution timeoutSeconds.

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

Planifier les différences entre les environnements local 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, les programmes et les utilitaires intégrés.

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

  • Le comportement des applications que vous installez localement pour simuler l'environnement de production (par exemple, ImageMagick de ce tutoriel) peut différer de celui de la production, en particulier si vous avez besoin de versions différentes ou si vous développez dans un environnement autre que 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 autre que Linux (par exemple, macOS). Vous pouvez gérer ce problème en utilisant Des alternatives aux commandes natives basées uniquement sur les nœuds, ou en créant des binaires Linux pour à votre déploiement.

Nouvelle tentative

L'émulateur Cloud Functions ne permet pas de relancer des fonctions en cas d'échec.

Et maintenant ?