ניהול פונקציות

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

פריסת פונקציות

כדי לפרוס פונקציות, מריצים את הפקודה הבאה ב-CLI‏ Firebase:

firebase deploy --only functions

כברירת מחדל, כלי Firebase CLI פורס את כל הפונקציות במקור בו-זמנית. אם הפרויקט מכיל יותר מ-5 פונקציות, מומלץ להשתמש בדגל --only עם שמות ספציפיים של פונקציות כדי לפרוס רק את הפונקציות שערכתם. פריסת פונקציות ספציפיות בדרך הזו מזרזת את תהליך הפריסה ועוזרת לכם להימנע מחריגה ממכסות הפריסה. לדוגמה:

firebase deploy --only functions:addMessage,functions:makeUppercase

כשפורסים מספר גדול של פונקציות, יכול להיות שתחרגו מהמכסה הרגילה ותקבלו הודעות שגיאה HTTP 429 או 500. כדי לפתור את הבעיה, כדאי לפרוס פונקציות בקבוצות של 10 או פחות.

רשימה מלאה של הפקודות הזמינות מופיעה במאמרי העזרה של Firebase CLI.

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

ניקוי של ארטיפקטים של פריסה

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

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

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

אפשר להגדיר או לערוך מדיניות ניקוי באופן ידני באמצעות הפקודה functions:artifacts:setpolicy:

firebase functions:artifacts:setpolicy

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

אפשר להתאים אישית את תקופת השמירה באמצעות האפשרות --days:

firebase functions:artifacts:setpolicy --days 7  # Delete images older than 7 days

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

$ firebase functions:artifacts:setpolicy --location europe-west1

ביטול ההסכמה לניקוי פריטי מידע שנוצרו בתהליך פיתוח (Artifact)

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

$ firebase functions:artifacts:setpolicy --none

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

מחיקת פונקציות

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

• באופן מפורש ב-CLI של Firebase באמצעות functions:delete
• באופן מפורש במסוף Google Cloud.
• באופן משתמע על ידי הסרת הפונקציה מהמקור לפני הפריסה.

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

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

• מחיקת כל הפונקציות שתואמות לשם שצוין בכל האזורים:

  firebase functions:delete FUNCTION-1_NAME

• מחיקת פונקציה ספציפית שפועלת באזור שאינו ברירת המחדל:

  firebase functions:delete FUNCTION-1_NAME --region REGION_NAME

• מחיקה של יותר מפונקציה אחת:

  firebase functions:delete FUNCTION-1_NAME FUNCTION-2_NAME

• מחיקת קבוצת פונקציות שצוינה:

  firebase functions:delete GROUP_NAME

• מדלג על בקשת האישור:

  firebase functions:delete FUNCTION-1_NAME --force

במחיקה מרומזת של פונקציות, firebase deploy מנתח את המקור ומסיר מהייצור את כל הפונקציות שהוסרו מהקובץ.

שינוי השם, האזור או הטריגר של פונקציה

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

שינוי שם של פונקציה

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

// before
const {onRequest}  = require('firebase-functions/v2/https');

exports.webhook = onRequest((req, res) => {
    res.send("Hello");
});

// after
const {onRequest}  = require('firebase-functions/v2/https');

exports.webhookNew = onRequest((req, res) => {
    res.send("Hello");
});

# before
from firebase_functions import https_fn

@https_fn.on_request()
def webhook(req: https_fn.Request) -> https_fn.Response:
    return https_fn.Response("Hello world!")

# after
from firebase_functions import https_fn

@https_fn.on_request()
def webhook_new(req: https_fn.Request) -> https_fn.Response:
    return https_fn.Response("Hello world!")

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

# Deploy new function
firebase deploy --only functions:webhookNew

# Wait until deployment is done; now both functions are running

# Delete webhook
firebase functions:delete webhook

שינוי האזור או האזורים של פונקציה

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

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

לדוגמה, אם יש לכם פונקציה שמופעלת על ידי Cloud Firestore ומוצבת כרגע ב-us-central1, ואתם רוצים להעביר אותה ל-asia-northeast1, אתם צריכים קודם לשנות את קוד המקור כדי לשנות את השם של הפונקציה ולשנות את האזור.

// before
exports.firestoreTrigger = onDocumentCreated(
  "my-collection/{docId}",
  (event) => {},
);

// after
exports.firestoreTriggerAsia = onDocumentCreated(
  {
    document: "my-collection/{docId}",
    region: "asia-northeast1",
  },
  (event) => {},
);

# Before
@firestore_fn.on_document_created("my-collection/{docId}")
def firestore_trigger(event):
    pass

# After
@firestore_fn.on_document_created("my-collection/{docId}",
                                  region="asia-northeast1")
def firestore_trigger_asia(event):
    pass

לאחר מכן פורסים את האפליקציה באמצעות הפקודה:

firebase deploy --only functions:firestoreTriggerAsia

עכשיו פועלות שתי פונקציות זהות: firestoreTrigger פועלת ב-us-central1, ו-firestoreTriggerAsia פועלת ב-asia-northeast1.

אחר כך מוחקים את firestoreTrigger:

firebase functions:delete firestoreTrigger

עכשיו יש רק פונקציה אחת – firestoreTriggerAsia, שפועלת ב-asia-northeast1.

שינוי סוג הטריגר של פונקציה

במהלך הפיתוח של פריסת Cloud Functions for Firebase, יכול להיות שתצטרכו לשנות את סוג הטריגר של פונקציה מסיבות שונות. לדוגמה, יכול להיות שתרצו לשנות מסוג אחד של אירוע Firebase Realtime Database או Cloud Firestore לסוג אחר.

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

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

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

// before
const {onObjectDeleted} = require("firebase-functions/v2/storage");

exports.objectDeleted = onObjectDeleted((event) => {
    // ...
});

// after
const {onObjectArchived} = require("firebase-functions/v2/storage");

exports.objectArchived = onObjectArchived((event) => {
    // ...
});

# before
from firebase_functions import storage_fn

@storage_fn.on_object_deleted()
def object_deleted(event):
  # ...

# after 
from firebase_functions import storage_fn

@storage_fn.on_object_archived()
def object_archived(event):
  # ...

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

# Create new function objectArchived
firebase deploy --only functions:objectArchived

# Wait until deployment is done; now both objectDeleted and objectArchived are running

# Delete objectDeleted
firebase functions:delete objectDeleted

הגדרת אפשרויות זמן ריצה

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

מומלץ להגדיר את האפשרויות האלה (למעט גרסת Node.js) באובייקט הגדרה בתוך קוד הפונקציה. האובייקט RuntimeOptions הזה הוא מקור האמת לאפשרויות זמן הריצה של הפונקציה, והוא יבטל את האפשרויות שהוגדרו בשיטה אחרת (כמו מסוף Google Cloud או gcloud CLI).

אם תהליך העבודה שלכם בפיתוח כולל הגדרה ידנית של אפשרויות זמן ריצה באמצעות המסוף Google Cloud או gcloud CLI, ואתם לא רוצים שהערכים האלה ישונו בכל פריסה, צריך להגדיר את האפשרות preserveExternalChanges לערך true. אם האפשרות הזו מוגדרת לערך true, מערכת Firebase ממזגת את אפשרויות זמן הריצה שמוגדרות בקוד עם ההגדרות של הגרסה הנוכחית של הפונקציה שפריסה, לפי סדר העדיפות הבא:

1. האפשרות מוגדרת בקוד הפונקציות: ביטול שינויים חיצוניים.
2. האפשרות מוגדרת ל-RESET_VALUE בקוד הפונקציות: שינויים חיצוניים מוחלפים בערך ברירת המחדל.
3. האפשרות לא מוגדרת בקוד הפונקציות, אבל היא מוגדרת בפונקציה שכרגע בפריסה: נעשה שימוש באפשרות שצוינה בפונקציה שפריסה.

לא מומלץ להשתמש באפשרות preserveExternalChanges: true ברוב התרחישים, כי הקוד לא יהיה יותר המקור המלא של האפשרויות בזמן הריצה של הפונקציות. אם בכל זאת משתמשים בה, צריך לבדוק את מסוף Google Cloud או להשתמש ב-gcloud CLI כדי לראות את ההגדרה המלאה של הפונקציה.

הגדרת גרסת Node.js

‫Firebase SDK ל-Cloud Functions מאפשר לבחור סביבת זמן ריצה של Node.js. אפשר לבחור להפעיל את כל הפונקציות בפרויקט באופן בלעדי בסביבת זמן הריצה שמתאימה לאחת מגרסאות Node.js הנתמכות הבאות:

• ‫Node.js 22
• ‫Node.js 20
• ‫Node.js 18 (הוצא משימוש)

הוצאנו משימוש את גרסאות 14 ו-16 של Node.js בתחילת 2025. הפריסה עם הגרסאות האלה מושבתת. בלוח הזמנים לתמיכה מופיע מידע חשוב לגבי התמיכה השוטפת בגרסאות האלה של Node.js.

כדי להגדיר את גרסת Node.js:

אתם יכולים להגדיר את הגרסה בשדה engines בקובץ package.json שנוצר בספרייה functions/ במהלך האתחול. לדוגמה, כדי להשתמש רק בגרסה 20, עורכים את השורה הזו בקובץ package.json:

  "engines": {"node": "20"}

אם אתם משתמשים במנהל החבילות Yarn או שיש לכם דרישות ספציפיות אחרות לגבי השדה engines, אתם יכולים להגדיר את זמן הריצה של Firebase SDK עבור Cloud Functions ב-firebase.json במקום זאת:

  {
    "functions": {
      "runtime": "nodejs20" // or nodejs22
    }
  }

ממשק ה-CLI משתמש בערך שהוגדר ב-firebase.json במקום בכל ערך או טווח שהגדרתם בנפרד ב-package.json.

שדרוג סביבת זמן הריצה של Node.js

כדי לשדרג את סביבת זמן הריצה של Node.js:

1. מוודאים שהפרויקט שלכם מוגדר למינוי Blaze בתשלום לפי שימוש.
2. חשוב לוודא שאתם משתמשים ב-Firebase CLI בגרסה 11.18.0 ואילך.
3. משנים את הערך engines בקובץ package.json שנוצר בספרייה functions/ במהלך האתחול. לדוגמה, אם משדרגים מגרסה 18 לגרסה 20, הרשומה צריכה להיראות כך: "engines": {"node": "20"}
4. אפשר גם לבדוק את השינויים באמצעות Firebase Local Emulator Suite.
5. פריסה מחדש של כל הפונקציות.

בחירת מערכת מודולים של Node.js

מערכת המודולים שמוגדרת כברירת מחדל ב-Node.js היא CommonJS‏ (CJS), אבל גרסאות עדכניות של Node.js תומכות גם במודולי ECMAScript‏ (ESM). ‫Cloud Functions תומך בשניהם.

כברירת מחדל, הפונקציות משתמשות ב-CommonJS. כלומר, ייבוא וייצוא נראים כך:

const {onRequest} = require("firebase-functions/https");

exports.helloWorld = onRequest(async (req, res) => res.send("Hello from Firebase!"));

כדי להשתמש ב-ESM במקום זאת, מגדירים את השדה "type": "module" בקובץ package.json:

  {
   ...
   "type": "module",
   ...
  }

אחרי שמגדירים את זה, משתמשים בתחביר ESM import ו-export:

import {onRequest} from "firebase-functions/https";

export const helloWorld = onRequest(async (req, res) => res.send("Hello from Firebase!"));

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

הגדרת גרסת Python

‫Firebase SDK לגרסאות Cloud Functions 12.0.0 ואילך מאפשר בחירה של זמן הריצה של Python. מגדירים את גרסת זמן הריצה ב-firebase.json כמו שמוצג:

  {
    "functions": {
      "runtime": "python310" // or python311
    }
  }

שליטה בהתנהגות של שינוי גודל

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

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

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

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

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

אפשר לבצע בקשות מקבילות

ב-Cloud Functions for Firebase (דור ראשון), כל מופע יכול לטפל בבקשה אחת בכל פעם, ולכן התנהגות ההתאמה לגודל נקבעה רק באמצעות הגדרות של מופעים מינימליים ומקסימליים. בנוסף לשליטה במספר המופעים, ב-Cloud Functions for Firebase (דור שני) אפשר לשלוט במספר הבקשות שכל מופע יכול לטפל בהן בו-זמנית באמצעות האפשרות concurrency. ערך ברירת המחדל של מקביליות הוא 80, אבל אפשר להגדיר אותו לכל מספר שלם בין 1 ל-1,000.

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

התרחיש הפשוט הזה ממחיש את פוטנציאל השיפור ביעילות באמצעות שימוש בבו-זמניות (concurrency). בפועל, התנהגות ההתאמה לעומס (scaling) כדי לייעל את היעילות ולהפחית את ההפעלה במצב התחלתי (cold start) באמצעות בו-זמניות (concurrency) היא מורכבת יותר. בו-זמניות (concurrency) ב-Cloud Functions for Firebase דור שני מבוססת על Cloud Run, ופועלת לפי הכללים של Cloud Run בנושא התאמה אוטומטית לעומס (automatic scaling) של מכונה מאגר.

כשעורכים ניסויים בהגדרות של יותר פעולות בו-זמניות ב-Cloud Functions for Firebase (דור שני), חשוב לזכור את הנקודות הבאות:

• יכול להיות שהגדרות גבוהות יותר של מספר בקשות בו-זמניות ידרשו מעבד וזיכרון RAM חזקים יותר כדי להשיג ביצועים אופטימליים, עד שמגיעים למגבלה מעשית. לדוגמה, יכול להיות שלפונקציה שמבצעת עיבוד כבד של תמונות או סרטונים לא יהיו מספיק משאבים כדי לטפל ב-1,000 בקשות בו-זמניות, גם אם הגדרות המעבד וזיכרון ה-RAM שלה מוגדרות למקסימום.
• מכיוון ש-Cloud Functions for Firebase (דור שני) מבוסס על Cloud Run, אפשר לעיין גם בהנחיות של Google Cloud בנושא אופטימיזציה של פעולות בו-זמניות.
• חשוב לבדוק היטב את התכונה 'ריבוי משימות בו-זמנית' בסביבת בדיקה לפני שמשתמשים בה בסביבת הייצור.

שמירה על מספר מינימלי של מופעים במצב פעיל

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

const { onCall } = require("firebase-functions/v2/https");

exports.getAutocompleteResponse = onCall(
  {
    // Keep 5 instances warm for this latency-critical function
    minInstances: 5,
  },
  (event) => {
    // Autocomplete user’s search term
  }
);

@https_fn.on_call(min_instances=5)
def get_autocomplete_response(event: https_fn.CallableRequest) -> https_fn.Response:

כמה דברים שכדאי לזכור כשמגדירים ערך מינימלי של מופעים:

• אם Cloud Functions for Firebase יגדיל את קנה המידה של האפליקציה מעבר להגדרה שלכם, תהיה הפעלה במצב התחלתי (cold start) לכל מופע מעל הסף הזה.
• ההשפעה של הפעלות במצב התחלתי (cold start) היא הכי חמורה באפליקציות עם תנועה לא יציבה. אם לאפליקציה שלכם יש תנועה עם עליות חדות ואתם מגדירים ערך גבוה מספיק כדי לצמצם את ההתחלות הקרות בכל עלייה בתנועה, תבחינו בצמצום משמעותי של זמן האחזור. באפליקציות עם תנועת גולשים קבועה, סביר להניח שהפעלות במצב התחלתי לא ישפיעו באופן משמעותי על הביצועים.

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

  Node.js

  const { onRequest } = require('firebase-functions/https');
  const { defineInt, defineString } = require('firebase-functions/params');
  
  // Define some parameters
  const minInstancesConfig = defineInt('HELLO_WORLD_MININSTANCES');
  const welcomeMessage = defineString('WELCOME_MESSAGE');
  
  // To use configured parameters inside the config for a function, provide them 
  // directly. To use them at runtime, call .value() on them.
  export const helloWorld = onRequest(
    { minInstances: minInstancesConfig },
  (req, res) => {
      res.send(`${welcomeMessage.value()}! I am a function.`);
    }
  );
  

  Python

  MIN_INSTANCES = params.IntParam("HELLO_WORLD_MININSTANCES")
  WELCOME_MESSAGE = params.StringParam("WELCOME_MESSAGE")
  
  @https_fn.on_request(min_instances=MIN_INSTANCES.value())
  def get_autocomplete_response(event: https_fn.Request) -> https_fn.Response:
      return https_fn.Response(f"{WELCOME_MESSAGE.value()} I'm a function.")
  

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

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

const { onMessagePublished } = require("firebase-functions/v2/pubsub");

exports.mirrorevents = onMessagePublished(
  { topic: "topic-name", maxInstances: 100 },
  (event) => {
    // Connect to legacy database
  }
);

@pubsub_fn.on_message_published(topic="topic-name", max_instances=100)
def mirrorevents(event: pubsub_fn.CloudEvent):
#  Connect to legacy database

אם פונקציית HTTP מורחבת עד למגבלת המופעים המקסימלית, בקשות חדשות מוכנסות לתור למשך 30 שניות ואז נדחות עם קוד תגובה 429 Too Many Requests אם לא זמין מופע עד אז.

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

הגדרת חשבון שירות

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

• פונקציות מהדור השני: PROJECT_NUMBER-compute@developer.gserviceaccount.com (נקרא חשבון השירות של Compute Engine שמוגדר כברירת מחדל)
• פונקציות מהדור הראשון: PROJECT_ID@appspot.gserviceaccount.com (נקרא חשבון השירות של App Engine שמוגדר כברירת מחדל)

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

const { onRequest } = require("firebase-functions/https");

exports.helloWorld = onRequest(
    {
        // This function doesn't access other Firebase project resources, so it uses a limited service account.
        serviceAccount:
            "my-limited-access-sa@", // or prefer the full form: "my-limited-access-sa@my-project.iam.gserviceaccount.com"
    },
    (request, response) => {
        response.send("Hello from Firebase!");
    },
);

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

הגדרת פסק זמן והקצאת זיכרון

במקרים מסוימים, יכול להיות שלפונקציות שלכם יהיו דרישות מיוחדות לערך ארוך של פסק זמן או להקצאה גדולה של זיכרון. אתם יכולים להגדיר את הערכים האלה במסוף Google Cloud או בקוד המקור של הפונקציה (רק ב-Firebase), באמצעות ערכי פסק זמן במסגרת מגבלות משך הזמן המקסימליות האלה:

• פונקציות HTTP ופונקציות שאפשר להפעיל: 3,600 שניות (60 דקות)
• פונקציות של תור משימות או פונקציות מתוזמנות: 1,800 שניות (30 דקות)
• פונקציות אחרות מבוססות-אירועים: 540 שניות (9 דקות)

כדי להגדיר הקצאת זיכרון ופסק זמן בקוד המקור של הפונקציות, משתמשים באפשרויות הגלובליות של זיכרון ושניות של פסק זמן כדי להתאים אישית את המכונה הווירטואלית שמריצה את הפונקציות. לדוגמה, הפונקציה Cloud Storage הזו משתמשת בזיכרון של 1GiB ומגיעה לפסק זמן אחרי 300 שניות:

exports.convertLargeFile = onObjectFinalized({
  timeoutSeconds: 300,
  memory: "1GiB",
}, (event) => {
  // Do some complicated things that take a lot of memory and time
});

@storage_fn.on_object_finalized(timeout_sec=300, memory=options.MemoryOption.GB_1)
def convert_large_file(event: storage_fn.CloudEvent):
# Do some complicated things that take a lot of memory and time.

כדי להגדיר הקצאת זיכרון וזמן קצוב לתפוגה במסוף Google Cloud:

1. במסוף Google Cloud, בוחרים באפשרות Cloud Functions for Firebase בתפריט הימני.
2. בוחרים פונקציה על ידי לחיצה על השם שלה ברשימת הפונקציות.
3. לוחצים על סמל העריכה בתפריט העליון.
4. בוחרים הקצאת זיכרון מהתפריט הנפתח עם התווית הזיכרון שהוקצה.
5. לוחצים על עוד כדי להציג את האפשרויות המתקדמות, ומזינים מספר שניות בתיבת הטקסט זמן קצוב לתפוגה.
6. לוחצים על שמירה כדי לעדכן את הפונקציה.

שינוי ברירות המחדל של ה-CPU

עד 2GB של זיכרון מוקצה, כל פונקציה ב-Cloud Functions for Firebase (דור שני) מוגדרת כברירת מחדל לליבת CPU אחת, ואז עולה ל-2 ליבות CPU ל-4GB ו-8GB. שימו לב שההתנהגות הזו שונה באופן משמעותי מההתנהגות שמוגדרת כברירת מחדל בדור הראשון, ויכולה להוביל לעלויות גבוהות יותר מעט עבור פונקציות עם זיכרון נמוך, כפי שמפורט בטבלה הבאה:

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

// Turn off Firebase defaults
setGlobalOptions({ cpu: 'gcf_gen1' });

# Use 1st gen behavior
set_global_options(cpu="gcf_gen1")

בפונקציות שדורשות הרבה משאבי CPU, דור שני מאפשר להגדיר CPU נוסף. אפשר להגדיל את ה-CPU לפי פונקציה, כמו שמוצג כאן:

// Boost CPU in a function:
export const analyzeImage = onObjectFinalized({ cpu: 2 }, (event) => {
  // computer vision goes here
});

# Boost CPU in a function:
@storage_fn.on_object_finalized(cpu=2)
def analyze_image(event: storage_fn.CloudEvent):
# computer vision goes here