לפני שמחברים את האפליקציה לאמולטור של 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 או מדריכים אחרים. מזהי הפרויקטים של פרויקטים לדוגמה מתחילים בקידומת |
כשעובדים עם פרויקטים לדוגמה ב-Firebase, האפליקציות והקוד שלכם מקיימים אינטראקציה עם אמולטורים בלבד. אם האפליקציה תנסה לקיים אינטראקציה עם משאב שלא פועל בו אמולטור, הקוד ייכשל. |
מומלץ להשתמש בפרויקטים לדוגמה בכל מקום שבו זה אפשרי. היתרונות כוללים:
- הגדרה קלה יותר, כי אפשר להפעיל את האמולטורים בלי ליצור פרויקט ב-Firebase.
- בטיחות משופרת, כי אם הקוד שלכם מפעיל בטעות משאבים שלא עברו אמולציה (ייצור), אין סיכוי לשינוי נתונים, לשימוש ולחיוב.
- תמיכה טובה יותר במצב אופליין, כי אין צורך לגשת לאינטרנט כדי להוריד את הגדרות ה-SDK.
הגדרת האפליקציה כך שתתקשר עם האמולטורים
הוספת פונקציות שניתנות לקריאה לאפליקציה
אם פעילויות האב טיפוס והבדיקה כוללות פונקציות קצה עורפי שניתן להפעיל, מגדירים את האינטראקציה עם האמולטור של Cloud Functions for Firebase באופן הבא:
Kotlin
// 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().useEmulator(withHost: "localhost", port: 5001)
Unity
FirebaseFunctions functions = FirebaseFunctions.DefaultInstance; // Connects to the Functions Emulator running on port 5001 functions.UseFunctionsEmulator("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);
הוספת כלים לאפליקציה כדי לדמות פונקציות HTTPS
כל פונקציית HTTPS בקוד תוגש מהאמולטור המקומי באמצעות הפורמט הבא של כתובת URL:
http://$HOST:$PORT/$PROJECT/$REGION/$NAME
לדוגמה, פונקציית helloWorld פשוטה עם יציאת המארח והאזור שמוגדרים כברירת מחדל תוגש בכתובת:
https://localhost:5001/$PROJECT/us-central1/helloWorld
הוספת כלים לאפליקציה כדי לדמות פונקציות של תור משימות
האמולטור מגדיר באופן אוטומטי תורי משימות באמולטור על סמך הגדרות הטריגר, וה-SDK לאדמינים מנתב מחדש בקשות בתור לאמולטור אם הוא מזהה שהוא פועל באמצעות משתנה הסביבה CLOUD_TASKS_EMULATOR_HOST.
שימו לב שמערכת השליחה שמשמשת בסביבת הייצור מורכבת יותר מזו שמוטמעת באמולטור, ולכן לא בטוח שההתנהגות באמולטור תשקף במדויק את סביבות הייצור. הפרמטרים באמולטור מספקים גבולות עליונים לקצב שבו המשימות נשלחות ומבוצעות מחדש.
הוספת כלים לאפליקציה כדי לדמות פונקציות שמופעלות ברקע
האמולטור של Cloud Functions תומך בפונקציות שמופעלות ברקע מהמקורות הבאים:
- אמולטור Realtime Database
- אמולטור Cloud Firestore
- אמולטור Authentication
- אמולטור Pub/Sub
- אמולטור ההתראות של Firebase
כדי להפעיל אירועים ברקע, משנים את המשאבים בקצה העורפי באמצעות Emulator Suite UI, או מחברים את האפליקציה או את קוד הבדיקה לאמולטורים באמצעות ה-SDK של הפלטפורמה.
בדיקת handlers לאירועים בהתאמה אישית שנוצרו על ידי תוספים
בפונקציות שאתם מטמיעים כדי לטפל באירועים בהתאמה אישית של Firebase Extensions באמצעות Cloud Functions v2, האמולטור של Cloud Functions משתלב עם האמולטור של Eventarc כדי לתמוך בטריגרים של Eventarc.
כדי לבדוק גורמים מטפלים באירועים בהתאמה אישית לתוספים ששולחים אירועים, צריך להתקין את האמולטורים של Cloud Functions ו-Eventarc.
אם האמולטור של Eventarc פועל, סביבת זמן הריצה של Cloud Functions מגדירה את משתנה הסביבה EVENTARC_EMULATOR ל-localhost:9299 בתהליך הנוכחי. ה-Firebase Admin SDKs מתחברים באופן אוטומטי לאמולטור של 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=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 תומך בשימוש בסודות כדי לאחסן מידע רגיש של הגדרות אישיות ולגשת אליו. כברירת מחדל, האמולטור ינסה לגשת לסודות בסביבת הייצור באמצעות פרטי כניסה שמוגדרים כברירת מחדל לאפליקציה. במצבים מסוימים, כמו סביבות CI, יכול להיות שהאמולטור לא יוכל לגשת לערכי סודות בגלל הגבלות על הרשאות.
בדומה לתמיכה של האמולטור Cloud Functions במשתני סביבה, אתם יכולים לשנות את ערכי הסודות על ידי הגדרת קובץ .secret.local. כך קל לבדוק את הפונקציות באופן מקומי, במיוחד אם אין לכם גישה לערך הסודי.
אילו כלים נוספים קיימים לבדיקת Cloud Functions?
האמולטור של Cloud Functions משלים כלים אחרים ליצירת אב טיפוס ולבדיקה:
- מעטפת Cloud Functions, שמאפשרת ליצור אב טיפוס ולפתח פונקציות אינטראקטיביות ואיטרטיביות. המעטפת משתמשת באמולטור של Cloud Functions עם ממשק בסגנון REPL לפיתוח. אין שילוב עם האמולטורים של Cloud Firestore או Realtime Database. באמצעות המעטפת, אתם יכולים לדמות נתונים ולבצע קריאות להפעלת פונקציות כדי לדמות אינטראקציה עם מוצרים ש-Local Emulator Suite לא תומך בהם כרגע: Analytics, הגדרת תצורה מרחוק ו-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 לא תומך בניסיון חוזר של פונקציות במקרה של כשל.
מה הלאה?
- בפלייליסט ההדרכה של אמולטורים של Firebase יש אוסף של סרטונים ודוגמאות מפורטות.
- מידע נוסף על האמולטור של Cloud Functions for Firebase זמין במאמר הרצת פונקציות באופן מקומי.