חיבור האפליקציה לאמולטור Cloud Functions

לפני שמחברים את האפליקציה לאמולטור Cloud Functions, חשוב לוודא שאתם מבינים את תהליך העבודה הכולל של Firebase Local Emulator Suite, ושמתקינים ומגדירים את Local Emulator Suite ובודקים את פקודות ה-CLI שלו.

בחירת פרויקט ב-Firebase

באמצעות השדה Firebase Local Emulator Suite מתבצעת אמולציה של מוצרים בפרויקט Firebase יחיד.

כדי לבחור את הפרויקט שבו רוצים להשתמש, לפני שמפעילים את הסימולטורים, מריצים את הפקודה firebase use בספריית העבודה ב-CLI. לחלופין, אפשר להעביר את הדגל --project לכל הפקודות של המהדר.

Local Emulator Suite תומך בהדמיה של פרויקטים אמיתיים ופרויקטים דמוניים ב-Firebase.

סוג הפרויקט תכונות שימוש באמולטורים
ריאל

פרויקט Firebase אמיתי הוא פרויקט שיצרתם והגדרתם (סביר להניח באמצעות המסוף של Firebase).

בפרויקטים אמיתיים יש משאבים פעילים, כמו מכונות של מסדי נתונים, קטגוריות אחסון, פונקציות או כל משאב אחר שהגדרתם לפרויקט הזה ב-Firebase.

כשעובדים עם פרויקטים אמיתיים ב-Firebase, אפשר להריץ אמוללטורים לכל המוצרים הנתמכים או לחלק מהם.

לגבי מוצרים שלא מעתיקים, האפליקציות והקוד יתקשרו עם המשאב הפעיל (מכונה של מסד נתונים, קטגוריה של אחסון, פונקציה וכו').

הדגמה

בפרויקט הדגמה ב-Firebase אין הגדרות אמיתיות של Firebase ואין משאבים פעילים. בדרך כלל ניגשים לפרויקטים האלה דרך הדרכות של Codelab או מדריכים אחרים.

מזהי פרויקטים של פרויקטים לדוגמה כוללים את הקידומת demo-.

כשעובדים עם פרויקטים לדוגמה ב-Firebase, האפליקציות והקוד שלכם מקיימים אינטראקציה עם אמוללטורים בלבד. אם האפליקציה תנסה לקיים אינטראקציה עם משאב שאין לו מכונה וירטואלית שפועלת, הקוד הזה ייכשל.

אנחנו ממליצים להשתמש בפרויקטים להדגמה ככל האפשר. ההטבות כוללות:

  • הגדרה קלה יותר, כי אפשר להריץ את הסימולטורים בלי ליצור פרויקט Firebase
  • אבטחה חזקה יותר, כי אם הקוד מפעיל בטעות משאבים לא ממולאמים (בפרודקשן), אין סיכוי לשינוי נתונים, שימוש בחיוב
  • תמיכה טובה יותר במצב אופליין, כי אין צורך לגשת לאינטרנט כדי להוריד את הגדרות ה-SDK.

מגדירים את האפליקציה כדי לדבר עם האמולטורים

משתמשים באפליקציה לפונקציות קריאה

אם פעילויות האב טיפוס והבדיקה כוללות פונקציות לקצה העורפי שניתן לבצע קריאה אליהן, צריך להגדיר את האינטראקציה עם אמולטור Cloud Functions for Firebase באופן הבא:

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)
MainActivity.kt
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);
MainActivity.java
Swift
Functions.functions().useFunctionsEmulator(origin: "http://127.0.0.1:5001")
ViewController.swift

Web

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

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

Web

firebase.functions().useEmulator("127.0.0.1", 5001);
emulator-suite.js

איך מגדירים באפליקציה אמולציה של פונקציות HTTPS

כל פונקציית HTTPS בקוד תוצג מהאמולטור המקומי בפורמט הבא:

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

לדוגמה, פונקציית helloWorld פשוטה עם יציאת המארח והאזור שמוגדרים כברירת מחדל תוצג בכתובת:

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

יצירת אינסטרומנטציה של האפליקציה לאמולציה של פונקציות בתור משימות

האמולטור מגדיר אוטומטית תורי משימות אמולטור על סמך הגדרות הטריגר, ו-Admin SDK מנתב מחדש לאמולטור את הבקשות שנשלחות בתור, אם הוא מזהה שהוא פועל דרך משתנה הסביבה CLOUD_TASKS_EMULATOR_HOST.

חשוב לזכור שמערכת השליחה שנעשה בה שימוש בסביבת הייצור מורכבת יותר מזו שמופעלת במהדורת הסימולציה, ולכן לא צפוי שההתנהגות בסימולציה תשקף במדויק את התנהגות הסביבה בסביבת הייצור. הפרמטרים במהדורת האדמין מספקים גבולות עליון לקצב שבו המשימות ��שלחות ונשלחים עליהן ניסיונות חוזרים.

הוספת רכיבים לאפליקציה להדמיה של פונקציות שמופעלות ברקע

האמולטור Cloud Functions תומך בפונקציות שהופעלו ברקע מהמקורות הבאים:

  • אמולטור Realtime Database
  • אמולטור Cloud Firestore
  • אמולטור Authentication
  • אמולטור Pub/Sub
  • אמולטור התראות ב-Firebase

כדי להפעיל אירועים ברקע, צריך לשנות את המשאבים בקצה העורפי באמצעות Emulator Suite UI, או על ידי חיבור האפליקציה או קוד הבדיקה לאמולטורים באמצעות ה-SDK של הפלטפורמה.

בדיקת רכיבי טיפול (handler) לאירועים מותאמים אישית שמופעלים על ידי תוספים

בפונקציות שמטמיעים כדי לטפל באירועים מותאמים אישית של Firebase Extensions באמצעות Cloud Functions v2, הסימולטור של Cloud Functions מתואם עם הסימולטור של Eventarc כדי לתמוך בטריגרים של Eventarc.

כדי לבדוק גורמים מטפלים באירועים בהתאמה אישית לאיתור תוספים שפולטים אירועים, צריך להתקין את האמולטורים Cloud Functions ו-Eventarc.

זמן הריצה של Cloud Functions מגדיר את משתנה הסביבה EVENTARC_EMULATOR כ-localhost:9299 בתהליך הנוכחי, אם האמולטור Eventarc פועל. ה-Firebase Admin SDK מתחברים באופן אוטומטי למהדר של Eventarc כשמגדירים את משתנה הסביבה EVENTARC_EMULATOR. אפשר לשנות את יציאת ברירת המחדל כפי שמוסבר בקטע הגדרה Local Emulator Suite.

כשמשתני הסביבה מוגדרים כראוי, האירועים נשלחים באופן אוטומטי על ידי Firebase Admin SDK למהדמטור של Eventarc. לאחר מכן, האמולטור של Eventarc מבצע קריאה חוזרת לאמולטור Cloud Functions כדי להפעיל handlers רשומים.

אפשר לבדוק את יומני הפונקציות ב-Emulator Suite UI לקבלת פרטים על הפעלת ה-handler.

הגדרת סביבת בדיקה מקומית

אם הפונקציות מסתמכות על הגדרות סביבה מבוססות-dotenv, אפשר לבצע אמולציה של ההתנהגות הזו בסביבת הבדיקה המקומית.

כשמשתמשים במהדר Cloud Functions מקומי, אפשר לשנות את משתני הסביבה של הפרויקט על ידי הגדרת קובץ .env.local. התוכן של .env.local מקבל עדיפות על פני .env ועל פני הקו��ץ .env הספציפי לפרויקט.

לדוגמה, פרויקט יכול לכלול את שלושת הקבצים הבאים, עם ערכים שונים מעט לצורכי פיתוח ובדיקה מקומית:

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

AUDIENCE=Humans

AUDIENCE=Dev Humans AUDIENCE=בני אדם מקומיים

כשהמכונה הווירטואלית מופעלת בהקשר המקומי, היא טוענת את משתני הסביבה באופן הבא:

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

סודות ופרטי כניסה באמולטור Cloud Functions

במהדורת המהופעל של Cloud Functions אפשר להשתמש בסודות כדי לאחסן מידע רגיש של הגדרות ולגשת אליו. כברירת מחדל, הסימולטור ינסה לגשת לסודות הייצור באמצעות Application Default Credentials. במצבים מסוימים כמו סביבות CI, יכול להיות שהאמולטור לא יוכל לגשת לערכים הסודיים בגלל הגבלות של הרשאות.

בדומה לתמיכה באמולטור Cloud Functions במשתני סביבה, אפשר לשנות את ערכי הסודות על ידי הגדרת קובץ .secret.local. כך קל לבדוק את הפונקציות באופן מקומי, במיוחד אם אין לכם גישה לערך הסודי.

אילו כלים נוספים קיימים לבדיקת Cloud Functions?

למהדורת האמולטור של Cloud Functions מצורפים כלי בדיקה וכלי יצירת אב טיפוס אחרים:

  • מעטפת Cloud Functions, שמאפשרת פיתוח ויצירת אב טיפוס של פונקציות אינטראקטיביות וחזרתיות. המעטפת משתמשת במהנתח של Cloud Functions עם ממשק בסגנון REPL לפיתוח. אין שילוב עם המהדמנים Cloud Firestore או Realtime Database. באמצעות המעטפת, אפשר ליצור נתונים מדומים ולבצע קריאות לפונקציות כדי לדמות אינטראקציה עם מוצרים ש-Local Emulator Suite לא תומך בהם כרגע: Analytics,‏ Remote Config ו-Crashlytics.
  • Firebase Test SDK for Cloud Functions,‏ Node.js עם מסגרת mocha לפיתוח פונקציות. למעשה, Cloud Functions Test SDK מספק אוטומציה על גבי מעטפת Cloud Functions.

מידע נוסף על המעטפת של Cloud Functions ועל Cloud Functions Test SDK זמין במאמר פונקציות בדיקה באופן אינטראקטיבי ובדיקת יחידות של Cloud Functions.

ההבדל בין המהדורה לבדיקה של Cloud Functions לבין המהדורה בסביבת הייצור

ברוב התרחישים לדוגמה, האמולטור Cloud Functions די קרוב לסביבת הייצור. השקענו מאמצים רבים כדי לוודא שכל מה שקשור לסביבת זמן הריצה של Node יהיה קרוב ככל האפשר לסביבת הייצור. עם זאת, האמולטור לא מחקה את סביבת הייצור המלאה בקונטיינרים, כך שבזמן שקוד הפונקציה יפעל באופן מציאותי, יהיו הבדלים בהיבטים אחרים של הסביבה (למשל קבצים מקומיים, התנהגות לאחר קריסות של פונקציות וכו').

Cloud IAM

ערכת האמולטורים של Firebase לא מנסה לשכפל התנהגות שקשורה ל-IAM במהלך ההרצה, או לפעול בהתאם לה. המהדמנים פועלים בהתאם לכללי האבטחה של Firebase, אבל במצבים שבהם בדרך כלל משתמשים ב-IAM, למשל כדי להגדיר את חשבון השירות שמפעיל את Cloud Functions ואת ההרשאות שלו, אי אפשר להגדיר את המהדמנים והם ישתמשו בחשבון שזמין באופן גלובלי במכונה של המפתח, בדומה להרצה ישירה של סקריפט מקומי.

מגבלות על הזיכרון והמעבד

בסימולטור אין אכיפה של הגבלות זיכרון או מעבד על הפונקציות. עם זאת, האמולטור תומך בפונקציות תזמון באמצעות הארגומנט timeoutSeconds של זמן הריצה.

שימו לב שזמן הביצוע של הפונקציה עשוי להיות שונה מזמן הביצוע של פונקציות שפועלות באמולטור. אחרי שתפתחו ותבדקו את הפונקציות באמצעות המהדר, מומלץ להריץ בדיקות מוגבלות בסביבת הייצור כדי לוודא את זמני הביצוע.

תכנון מראש של הבדלים בין סביבות מקומיות לסביבות ייצור

מאחר שהמכונה הווירטואלית פועלת במחשב המקומי, היא תלויה בסביבה המקומית שלכם לגבי אפליקציות, תוכנות מובנות ותוכנות שירות.

שימו לב שהסביבה המקומית לפיתוח של Cloud Functions עשויה להיות שונה מסביבת הייצור של Google:

  • התנהגות האפליקציות שמתקינים באופן מקומי כדי לדמות את סביבת הייצור (למשל ImageMagick מהמדריך הזה) עשויה להיות שונה מזו בסביבת הייצור, במיוחד אם אתם צריכים גרסאות שונות או מפתחים בסביבה שאינה Linux. כדאי לפרוס עותק בינארי משלכם של התוכנה החסרה לצד פריסת הפונקציה.

  • באופן דומה, ייתכן שתוכנות שירות מובנות (למשל, פקודות מעטפת כמו ls,‏ mkdir) יהיו שונות מהגרסאות הזמינות בסביבת הייצור, במיוחד אם אתם מפתחים בסביבה שאינה Linux (למשל, macOS). כדי לפתור את הבעיה הזו, אפשר להשתמש ב��לופות ל-Node בלבד לפקודות מקוריות, או ליצור תוכניות בינאריות של Linux כדי לצרף אותן לפריסה.

מנסה שוב

בסימולטור של Cloud Functions אין תמיכה בניסיונות חוזרים של פונקציות במקרה של כשל.

מה הלאה?