חיבור האפליקציה לאמולטור 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 בקוד תוצג מהאמולטור המקומי באמצעות פורמט כתובת ה-URL הבא:

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 הרשומים.

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

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

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

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

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

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

AUDIENCE=Humans

AUDIENCE=Dev Humans AUDIENCE=Local Humans

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

  $ 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 אין תמיכה בניסיונות חוזרים של פונקציות במקרה של כשל.

מה הלאה?