חיבור האפליקציה לאמולטור 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 ואין משאבים פעילים. בדרך כלל אפשר לגשת לפרויקטים האלה דרך Codelabs או מדריכים אחרים.

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

מה הלאה?