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

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

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

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

firebase deploy --only functions

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

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

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

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

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

ניקוי פריטי פריסה

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

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

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

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

firebase functions:artifacts:setpolicy

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

אפשר להתאים אישית את תקופת השמירה באמצעות האפשרות --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

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

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

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

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

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

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

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

  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. מוחקים באופן מפורש את הפונקציה הישנה מהייצור באמצעות ה-CLI של Firebase.

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

// 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

ערכת ה-SDK של Firebase ל-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, אתם יכולים להגדיר את סביבת זמן הריצה של ה-SDK של Firebase ל-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

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

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

שליטה בהתנהגות של התאמה לעומס (auto-scaling)

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

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

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

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

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

אישור בקשות מקבילות

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

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

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

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

• כדי להגיע לביצועים אופטימליים, יכול להיות שתצטרכו להגדיל את המעבד (CPU) ואת ה-RAM עד שתגיעו למגבלה מעשית. לדוגמה, לפונקציה שמבצעת עיבוד כבד של תמונות או סרטונים יכול להיות שלא יהיו מספיק משאבים כדי לטפל ב-1, 000 בקשות מקבילות, גם אם הגדרות המעבד (CPU) וה-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) לכל מכונה מעל לסף הזה.
• הפעלה במצב התחלתי משפיעה בצורה הכי חמורה על אפליקציות עם תנועה לא יציבה. אם באפליקציה יש תנועה לא סדירה, ואתם מגדירים ערך גבוה מספיק כדי לצמצם את ההפעלות במצב התחלתי בכל עלייה בתנועה, זמן האחזור יצטמצם באופן משמעותי. באפליקציות עם תנועה קבועה, הפעלות במצב התחלתי לא צפויות להשפיע באופן חמור על הביצועים.

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

  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 default service account)
• פונקציות מהדור הראשון: PROJECT_ID‎@appspot.gserviceaccount.com (נקרא App Engine default service account)

יכול להיות שתרצו לשנות את חשבון השירות שמוגדר כברירת מחדל ולהגביל פונקציה למשאבים המדויקים שנדרשים. כדי לעשות את זה, אתם יכולים ליצור חשבון שירות בהתאמה אישית ולהקצות אותו לפונקציה המתאימה באמצעות ערך ההגדרה 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. בוחרים הקצאת זיכרון מהתפריט הנפתח Memory allocated.
5. לוחצים על More כדי להציג את האפשרויות המתקדמות, ומזינים מספר שניות בתיבת הטקסט Timeout.
6. לוחצים על Save כדי לעדכן את הפונקציה.

שינוי ברירות המחדל של המעבד (CPU)

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

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

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

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

בפונקציות שדורשות שימוש אינטנסיבי במעבד, הדור השני מאפשר להגדיר מעבד נוסף. אפשר להגדיל את המעבד (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