Łączenie aplikacji z emulatorem Cloud Functions

Zanim połączysz aplikację z emulatorem Cloud Functions, upewnij się, że rozumiesz cały przepływ pracy w Pakiecie emulatorów lokalnych Firebase oraz że zainstalujesz i skonfigurujesz Pakiet emulatorów lokalnych, a także zapoznasz się z poleceniami interfejsu wiersza poleceń.

Wybierz projekt Firebase

Pakiet emulatorów lokalnych Firebase emuluje usługi związane z jednym projektem Firebase.

Aby wybrać projekt do użycia, przed uruchomieniem emulatorów uruchom interfejs wiersza poleceń firebase use w katalogu roboczym. Możesz też przekazać flagę --project do każdego polecenia emulatora.

Pakiet emulatorów lokalnych obsługuje emulację prawdziwych projektów Firebase i projektów prezentacyjnych.

Typ projektu Funkcje Używanie z emulatorami
Prawdziwe

Prawdziwy projekt Firebase to projekt utworzony i skonfigurowany przez Ciebie (najprawdopodobniej w konsoli Firebase).

Rzeczywiste projekty mają aktywne zasoby, takie jak instancje bazy danych, zasobniki na dane, funkcje lub inne zasoby skonfigurowane dla danego projektu Firebase.

Podczas pracy z prawdziwymi projektami Firebase możesz uruchomić emulatory dowolnej lub wszystkich obsługiwanych usług.

W przypadku usług, których nie emulujesz, aplikacje i kod będą wchodzić w interakcje z aktywnym zasobem (instancją bazy danych, zasobnikiem na dane, funkcją itp.).

Demonstracyjny

Projekt demonstracyjny Firebase nie ma rzeczywistej konfiguracji Firebase ani aktywnych zasobów. Dostęp do tych projektów uzyskuje się zwykle w ramach ćwiczeń z programowania lub innych samouczków.

Identyfikatory projektów demonstracyjnych mają prefiks demo-.

Jeśli pracujesz w projektach demonstracyjnych Firebase, Twoje aplikacje i kod wchodzą w interakcję tylko z emulatorami. Jeśli aplikacja spróbuje wejść w interakcję z zasobem, dla którego emulator nie jest uruchomiony, ten kod zakończy się niepowodzeniem.

Zalecamy, aby w miarę możliwości korzystać z projektów demonstracyjnych. W ten sposób możesz zapewnić im dostęp do tych korzyści:

  • Łatwiejsza konfiguracja, ponieważ emulatory można uruchamiać bez konieczności tworzenia projektu Firebase.
  • Silniejsze bezpieczeństwo, ponieważ jeśli Twój kod przypadkowo wywoła zasoby nieemulowane (produkcyjne), nie ma szans na zmianę danych, ich wykorzystanie i płatności
  • Lepsza obsługa offline, ponieważ nie musisz łączyć się z internetem, aby pobrać konfigurację pakietu SDK.

Dostosuj aplikację do emulatorów

Dostosuj aplikację pod kątem funkcji wywoływanych

Jeśli Twój prototyp i działania testowe obejmują wywoływane funkcje backendu, skonfiguruj interakcję z emulatorem Cloud Functions dla Firebase w ten sposób:

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);

Dostosuj aplikację do emulacji funkcji HTTPS

Każda funkcja HTTPS w kodzie będzie obsługiwana przez lokalny emulator przy użyciu adresu URL w tym formacie:

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

Na przykład prosta funkcja helloWorld z domyślnym portem i regionem hosta byłaby obsługiwana w tym miejscu:

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

Dostosuj aplikację do emulacji funkcji wyzwalanych w tle

Emulator Cloud Functions obsługuje funkcje aktywowane w tle z tych źródeł:

  • Emulator Bazy danych czasu rzeczywistego
  • Emulator Cloud Firestore
  • Emulator uwierzytelniania
  • Emulator Pub/Sub

Aby aktywować zdarzenia w tle, zmodyfikuj zasoby backendu, korzystając z interfejsu Pakietu emulatorów albo łącząc aplikację lub kod testowy z emulatorami przy użyciu pakietu SDK przeznaczonego na Twoją platformę.

Testowe moduły obsługi zdarzeń niestandardowych generowane przez rozszerzenia

W przypadku funkcji zaimplementowanych do obsługi zdarzeń niestandardowych Rozszerzeń w Firebase w Cloud Functions w wersji 2 emulator Cloud Functions łączy się z emulatorem Eventarc w celu obsługi wyzwalaczy Eventarc.

Aby przetestować niestandardowe moduły obsługi zdarzeń pod kątem rozszerzeń, które emitują zdarzenia, musisz zainstalować emulatory Cloud Functions i Eventarc.

Środowisko wykonawcze Cloud Functions ustawia zmienną środowiskową EVENTARC_EMULATOR na localhost:9299 w bieżącym procesie, jeśli emulator Eventarc jest uruchomiony. Pakiety Firebase Admin SDK automatycznie łączą się z emulatorem Eventarc po ustawieniu zmiennej środowiskowej EVENTARC_EMULATOR. Port domyślny można zmienić w sposób omówiony w artykule Konfigurowanie Pakietu emulatorów lokalnych.

Po prawidłowym skonfigurowaniu zmiennych środowiskowych pakiet Firebase Admin SDK automatycznie wysyła zdarzenia do emulatora Eventarc. Z kolei emulator Eventarc wywołuje z powrotem do emulatora Cloud Functions, aby aktywować wszystkie zarejestrowane moduły obsługi.

Szczegółowe informacje o wykonywaniu modułu obsługi możesz sprawdzić w logach funkcji w interfejsie pakietu emulatorów.

Konfigurowanie lokalnego środowiska testowego

Jeśli Twoje funkcje bazują na konfiguracji środowiska na podstawie dotenv, możesz emulować to zachowanie w lokalnym środowisku testowym.

Jeśli używasz lokalnego emulatora Cloud Functions, możesz zastąpić zmienne środowiskowe w projekcie, konfigurując plik .env.local. Zawartość pliku .env.local ma pierwszeństwo przed .env oraz plikiem .env konkretnego projektu.

Projekt może np. zawierać te 3 pliki zawierające nieco inne wartości na potrzeby testów programistycznych i lokalnych:

.env .env.dev .env.local
PLANET=Ziemia

AUDIENCE=ludzie

AUDIENCE=Programiści AUDIENCE=Lokalni ludzie

Po uruchomieniu w kontekście lokalnym emulator wczytuje zmienne środowiskowe w następujący sposób:

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

Obiekty tajne i dane logowania w emulatorze Cloud Functions

Emulator Cloud Functions obsługuje korzystanie z obiektów tajnych do przechowywania poufnych informacji o konfiguracji i uzyskiwania do nich dostępu. Domyślnie emulator będzie próbował uzyskać dostęp do produkcyjnych obiektów tajnych za pomocą domyślnych danych logowania aplikacji. W niektórych sytuacjach, na przykład w środowiskach CI, emulator może nie uzyskać dostępu do wartości obiektów tajnych z powodu ograniczeń uprawnień.

Podobnie jak w przypadku obsługi zmiennych środowiskowych w emulatorze Cloud Functions możesz zastąpić wartości obiektów tajnych, konfigurując plik .secret.local. Ułatwia to lokalne testowanie funkcji, zwłaszcza jeśli nie masz dostępu do wartości obiektu tajnego.

Jakie są inne narzędzia do testowania funkcji w Cloud Functions?

Emulator Cloud Functions jest uzupełniany o inne narzędzia prototypowe i testowe:

  • Powłoka Cloud Functions umożliwiająca tworzenie prototypów i programowanie interaktywnych funkcji iteracyjnych. W powłoce wykorzystywany jest emulator Cloud Functions z interfejsem w stylu REPL na potrzeby programowania. Nie ma integracji z emulatorami Cloud Firestore ani Bazy danych czasu rzeczywistego. Powłoka służy do przykładania danych i wykonywania wywołań funkcji symulujących interakcję z usługami, których obecnie pakiet emulatorów lokalnych nie obsługuje: Analytics, Zdalna konfiguracja i Crashlytics.
  • Firebase Test SDK dla Cloud Functions – środowiska Node.js z platformą mokha do tworzenia funkcji. W efekcie pakiet SDK Cloud Functions Test SDK zapewnia automatyzację w powłoce Cloud Functions.

Więcej informacji o powłoce Cloud Functions i pakiecie SDK Cloud Functions Test SDK znajdziesz w artykułach Interaktywne testowanie funkcji i Testowanie jednostkowe funkcji w Cloud Functions.

Czym różni się emulator Cloud Functions od środowiska produkcyjnego

W większości przypadków emulator Cloud Functions jest dość zbliżony do środowiska produkcyjnego. Dokładamy wszelkich starań, aby wszystko w środowisku wykonawczym węzła było jak najbliżej środowiska produkcyjnego. Emulator nie imituje jednak w pełni skonteneryzowanego środowiska produkcyjnego, więc o ile kod Twojej funkcji będzie wykonany realistycznie, inne aspekty Twojego środowiska (np. pliki lokalne, zachowanie po awarii funkcji itp.) będą się różnić.

Cloud IAM

Pakiet emulatorów Firebase nie próbuje replikować ani nie przestrzegać żadnych działań związanych z uprawnieniami dotyczącymi uruchamiania. Emulatory przestrzegają podanych reguł zabezpieczeń Firebase, ale w sytuacjach, w których uprawnienia są zwykle używane, np. do skonfigurowania konta usługi Cloud Functions, a zatem uprawnień, emulatora nie można skonfigurować i używa on konta dostępnego globalnie na komputerze dewelopera, podobnie jak w przypadku bezpośredniego uruchomienia skryptu lokalnego.

Ograniczenia dotyczące pamięci i procesora

Emulator nie wymusza na Twoich funkcjach ograniczeń dotyczących pamięci ani procesora. Emulator obsługuje jednak funkcje przekroczenia limitu czasu za pomocą argumentu środowiska wykonawczego timeoutSeconds.

Pamiętaj, że czas wykonywania funkcji w emulatorze może się różnić od czasu w środowisku produkcyjnym. Po zaprojektowaniu i przetestowaniu funkcji w emulatorze zalecamy przeprowadzenie ograniczonych testów w środowisku produkcyjnym w celu potwierdzenia czasu wykonania.

Planowanie z uwzględnieniem różnic w środowiskach lokalnych i produkcyjnych

Emulator działa na komputerze lokalnym, więc zależy to od lokalnego środowiska aplikacji oraz wbudowanych programów i narzędzi.

Pamiętaj, że środowisko lokalne programowania w Cloud Functions może się różnić od środowiska produkcyjnego Google:

  • Aplikacje instalowane lokalnie w celu symulowania środowiska produkcyjnego (np. ImageMagick z tego samouczka) mogą działać inaczej niż produkcyjne, zwłaszcza jeśli potrzebujesz innych wersji lub tworzysz aplikacje w środowisku innym niż Linux. Rozważ wdrożenie własnej kopii binarnej brakującego programu wraz z wdrożeniem funkcji.

  • Podobnie wbudowane narzędzia (np. polecenia powłoki, takie jak ls czy mkdir) mogą różnić się od wersji dostępnych w środowisku produkcyjnym, zwłaszcza jeśli programujesz w środowisku innym niż Linux (np. macOS). Aby rozwiązać ten problem, użyj alternatyw dla poleceń natywnych, które obejmują tylko węzły, lub utwórz pliki binarne Linuksa, które zostaną połączone z wdrożeniem.

Ponawiam próbę

Emulator Cloud Functions nie obsługuje ponawiania funkcji w przypadku niepowodzenia.

Co dalej?