Firebase Cloud Functions — vad det är, utlösare och hur man skriver funktioner

Vad är Firebase Cloud Functions och hur är det uppbyggt

Firebase Cloud Functions är en beräkningsplattform byggd på Google Cloud Functions (GCF), anpassad för Firebase-ekosystemet. Funktioner är vanlig JavaScript- eller TypeScript-kod som exporteras från en modul och registreras för en specifik händelsetyp. När händelsen inträffar (till exempel registrerar sig en användare eller laddar upp en fil) kör Firebase Cloud Functions motsvarande kod och överför händelsens kontext till den.

Arkitekturen för Cloud Functions följer principen om ensamt ansvar: en funktion hanterar en händelsetyp och utför en atomär operation. Till exempel anropas funktionen sendWelcomeEmail när en ny användare skapas i Firebase Authentication och skickar ett välkomstmejl. Sådan isolering förenklar felsökning, testning och återanvändning av funktioner i olika projekt.

Varje funktion körs i en isolerad behållare med en tillfällig livscykel. Maximal körtid är som standard 60 sekunder (HTTPS-funktioner — 9 minuter). Om funktionen inte ryms inom tidsgränsen avslutas förfrågan med fel 500. För långa operationer, använd Cloud Tasks eller Pub/Sub med försök igen. Behållare kan återanvändas för efterföljande anrop (keep-alive), vilket minskar fördröjningen vid kallstarter efter det första anropet.

Körtidsmiljö och Node.js-versioner

Firebase Cloud Functions stöder flera Node.js-versioner: 18, 20 och 22 (rekommenderad för nya projekt). Versionen väljs i fältet engines i filen package.json. Firebase CLI konfigurerar automatiskt körtidsmiljön baserat på den angivna versionen. Viktigt: Firebase Cloud Functions stöder inte körning av godtyckliga Docker-behållare — miljön är strikt fastställd av Google Cloud Functions.

För nya projekt rekommenderas Node.js 22, eftersom den innehåller de senaste V8-optimeringarna, förbättrad hantering av ESM-moduler och WebSocket-stöd på plattformsnivå. Om projektet använder beroenden kompilerade för en specifik Node-version (till exempel C++-moduler), måste kompatibiliteten kontrolleras separat — inte alla native-moduler kompileras i GCF-miljön.

Skillnaden mellan Firebase Cloud Functions och Google Cloud Functions

Firebase Cloud Functions är ett omslag kring Google Cloud Functions med förinstallerat Firebase SDK och integration med Firebase-tjänster. Utvecklaren skriver kod med SDK:n firebase-functions, som tillhandahåller typerade utlösare för alla Firebase-tjänster. Google Cloud Functions är en plattform på lägre nivå, där utlösare konfigureras explicit via Eventarc eller Pub/Sub.

Den viktigaste skillnaden: i Firebase Cloud Functions registreras utlösaren deklarativt via anropet functions.firestore.document('path').onWrite(), och i Google Cloud Functions — via Eventarc-konfiguration med filtrering på händelseattribut. Firebase Cloud Functions levereras också automatiskt med Admin SDK, initierad med projektets tjänstekonto-rättigheter, vilket ger fullständig åtkomst till alla Firebase-tjänster utan ytterligare konfiguration.

Typer av utlösare: vilka händelser stöds

Firebase Cloud Functions stöder 8 kategorier av utlösare, där var och en motsvarar en specifik Firebase- eller Google Cloud-tjänst. En utlösare är ett villkor som när det inträffar automatiskt anropar funktionen. Utvecklaren hanterar inte funktionens livscykel direkt: Firebase CLI registrerar utlösaren i Google Cloud Eventarc, och molnplattformen startar själv funktionen när händelsen inträffar.

De populäraste utlösarna — Firestore-utlösare: onWrite, onCreate, onUpdate, onDelete. De aktiveras när dokument i Firestore-samlingar ändras. Funktionen får ögonblicksbilder av dokumentet före och efter ändringen, vilket gör det möjligt att jämföra värden och reagera bara på specifika ändringar. Till exempel, när orderstatus ändras från "pending" till "shipped" kan du skicka ett push-meddelande till användaren.

Authentication-utlösare (onCreate, onDelete) aktiveras när ett konto skapas eller tas bort. De används för att initiera användardata: skapa användardokument i Firestore, skicka välkomstmejl, skriva till analys. Viktigt: funktionen kan inte avbryta skapandet av en användare — den körs efter att kontot redan har skapats. För förvalidering, använd blockerande funktioner (Blocking Functions), tillgängliga på plattformen Identity Platform.

HTTPS-utlösare och CORS

HTTPS-funktioner (onRequest) gör det möjligt att skapa fullvärdiga REST API-slutpunkter som är tillgängliga via HTTP. Till skillnad från händelseutlösare anropas HTTPS-funktioner via en URL av formen https://{region}-{project}.cloudfunctions.net/{functionName}. Det är viktigt att konfigurera CORS korrekt om slutpunkten anropas från en webbläsare eller mobilapp. Firebase SDK inkluderar inte automatiskt CORS-huvuden — de måste läggas till manuellt via middleware.

För mobilklienter (Android, iOS) krävs inte CORS, eftersom inbyggda HTTP-klienter inte begränsas av Cross-Origin-policyn. CORS är endast relevant för webbförfrågningar. Om din HTTPS-funktion anropas både från appen och från webben, lägg till universell CORS-hantering: res.set('Access-Control-Allow-Origin', '*') för development eller en lista över tillåtna domäner för production.

Schemaläggning med Pub/Sub och Cloud Scheduler

För periodisk körning (cron-jobb) använd kombinationen av Cloud Scheduler och Pub/Sub. Cloud Scheduler skickar ett meddelande till Pub/Sub-ämnet enligt schema, och Cloud Functions-utlösaren onPublish bearbetar meddelandet. Firebase CLI stöder inte direkt cron-syntax — schemat ställs in via Google Cloud-konsolen eller Terraform i formatet unix-cron: 0 3 * * * (dagligen kl. 3:00).

Exempel på uppgifter: daglig utskick, rensning av föråldrade data, generering av rapporter, synkronisering med externa API:er. Viktigt: Cloud Scheduler är en betald Google Cloud-tjänst (ungefär 2 $ i månaden för ett jobb). Varje utlösning räknas som ett separat funktionsanrop och debiteras enligt standardpriserna för Cloud Functions.

Hur man skriver och distribuerar funktioner

Utveckling av Cloud Functions börjar med att initiera projektet via Firebase CLI: firebase init functions. Detta kommando skapar katalogen functions/ med mallen index.js (eller index.ts), filen package.json och TypeScript-konfiguration (om vald). Efter initieringen räcker det att skriva en funktion, exportera den från modulen och köra firebase deploy --only functions för distribution.

Varje funktion registreras via anropet av metoden för motsvarande utlösare. Exempel på HTTPS-funktion: exports.helloWorld = functions.https.onRequest((req, res) => { res.send("Hello!"); }). Firebase-funktioner använder asynkron modell: för händelseutlösare (inte HTTPS) måste funktionen returnera ett Promise. Firebase väntar på att Promise slutförs innan behållaren stängs. Om Promise inte returneras kan funktionen avbrytas innan de asynkrona operationerna är klara.

Lokal utveckling sker via Firebase Emulator Suite, som innehåller en emulator för Cloud Functions. Kommandot firebase emulators:start startar en lokal server med funktioner, tillgänglig på http://localhost:5001. Emulatorn stöder hot reload vid kodändring och är helt isolerad från produktionsmiljön, vilket gör att funktioner kan testas utan risk att påverka riktiga data.

Hantering av beroenden och konfiguration

Beroenden för Cloud Functions hanteras via package.json. Firebase installerar bara produktionsberoenden (dependencies, inte devDependencies). Storleken på funktionspaketet påverkar kallstartstiden: det rekommenderas att minimera antalet beroenden. För arbete med Firebase Admin SDK är beroendet firebase-admin redan förinstallerat — det behöver inte läggas till manuellt.

Konfidentiella data (API-nycklar, token) bör inte lagras i funktionskoden. Använd functions.config() för att lagra konfiguration: firebase functions:config:set stripe.key="sk_...". Värdena är krypterade och tillgängliga vid körning via functions.config().stripe.key. För stora serialiserade konfigurationer, använd Google Cloud Secret Manager.

Felhantering och loggning

Loggning i Cloud Functions sker via console.log, console.warn och console.error. Alla loggar samlas automatiskt i Google Cloud Logging och är tillgängliga i Firebase-konsolen (avsnittet Functions > Logs). För strukturerad loggning, använd biblioteket winston eller pino, som stöder JSON-formatering och loggningsnivåer.

Felhantering är avgörande för tillförlitlighet: ett ohanterat undantag i ett Promise avslutar funktionen med fel, varefter Firebase automatiskt upprepar anropet (retry) med exponentiell fördröjning. Antalet retry-försök konfigureras: från 0 till oändlighet. För händelseutlösare rekommenderas att aktivera retry för att garantera bearbetning av varje händelse även vid tillfälliga fel i externa tjänster.

Kallstart och skalning

Kallstart (cold start) är fördröjningen vid det första anropet av en funktion efter en period av inaktivitet, när behållaren med koden laddas om och initieras igen. Enligt Firebase documentation (2026) tar en kallstart från 200 ms till 2 sekunder beroende på paketets storlek, antalet beroenden och regionen. För användargränssnittet är en fördröjning över 1 sekund märkbar och kan påverka user experience.

Sätt att minimera kallstart: minimera beroenden, använda TypeScript med kompilering till CommonJS, minska funktionspaketets storlek, ställa in ett minsta antal aktiva instanser. Firebase Cloud Functions v2 (2nd gen) gör det möjligt att ange minInstances — minsta antal uppvärmda behållare som alltid är redo att hantera förfrågningar. För uppvärmning av behållare debiteras en avgift för inaktiv tid.

Skalning av Cloud Functions sker automatiskt: när antalet förfrågningar ökar skapar Firebase nya behållare. Som standard är det maximala antalet parallella instanser 3000 (kvot för Google Cloud-projektet). Varje instans bearbetar en förfrågan åt gången. Om funktionen är snabb (mindre än 100 ms) kan en instans bearbeta upp till 10 förfrågningar per sekund, vilket ger en toppkapacitet på upp till 30 000 förfrågningar per sekund per projekt.

Konfiguration av minInstances och maxInstances

minInstances är en parameter som reserverar det angivna antalet behållare och håller dem uppvärmda. Det rekommenderas för kritiska HTTPS-funktioner där kallstartsfördröjningen är oacceptabel. Till exempel, för en autentiseringsslutpunkt ställ in minInstances: 1. maxInstances är en gräns för det maximala antalet parallella instanser, användbar för att förhindra okontrollerad kostnadsökning vid plötslig trafiktopp.

Konfigurationen görs i koden: functions.runWith({ minInstances: 1, maxInstances: 10 }). Viktigt: minInstances ökar kostnaden, eftersom behållaren arbetar kontinuerligt. För testprojekt bör minInstances inaktiveras. För produktion rekommenderas minInstances för alla offentliga HTTPS-funktioner och 0 för händelseutlösare, där en fördröjning på 1 sekund inte är kritisk.

Distributionsregioner

Distributionsregionen påverkar fördröjningen till slutanvändare och kostnaden för utgående trafik. Firebase Cloud Functions är tillgängligt i 30+ Google Cloud-regioner. För mobilappar väljer du den region som ligger närmast din målgrupp: us-central1 för Amerika, europe-west1 för Europa, asia-east2 för Asien. Regionen kan inte ändras efter distribution utan att funktionen distribueras på nytt.

Byte av region sker via parametern region i koden: functions.region('europe-west1'). Alla funktioner i en fil kan ha olika regioner. För globala projekt rekommenderas att distribuera funktioner i flera regioner och använda Cloud Load Balancing för att fördela trafiken, även om en region räcker för de flesta mobilappar vid rätt val.

Kodexempel för Firebase Cloud Functions

Låt oss titta på praktiska exempel på Cloud Functions i TypeScript. Koden använder Firebase Functions SDK v2 (2nd gen) med modulär ES-syntax. Exemplen inkluderar bearbetning av händelsen att skapa användare, generering av miniatyr vid bilduppladdning och en enkel HTTPS-slutpunkt för REST API. Alla funktioner är asynkrona och returnerar ett Promise för korrekt avslut av behållaren.

Innan du kör, se till att Firebase CLI är uppdaterat till version 13+: npm install -g firebase-tools. v2-funktioner kräver prisplanen Blaze. Initiering: firebase init functions med val av TypeScript.

Bearbetning av användarregistrering

Det första exemplet — skapa dokument i Firestore vid registrering av en ny användare. Funktionen utlöses av händelsen auth.user().onCreate och skriver en grundprofil till samlingen users/{uid}. Detta gör det möjligt att garantera att det för varje registrerad användare finns ett dokument med nödvändiga fält.

import * as functions from "firebase-functions"
import * as admin from "firebase-admin"

admin.initializeApp()

export const createUserProfile = functions.auth
    .user()
    .onCreate(async (user) => {
        const profile = {
            email: user.email,
            displayName: user.displayName ?? "User",
            createdAt: admin.firestore.Timestamp.now(),
            role: "free",
            avatarUrl: null,
        }

        await admin.firestore()
            .collection("users")
            .doc(user.uid)
            .set(profile)

        console.log(`Profile created for ${user.uid}`)
    })

Funktionen createUserProfile är asynkron — den returnerar ett Promise som Firebase väntar på innan den slutförs. Om skrivningen till Firestore slutar med fel (till exempel på grund av brist på rättigheter), upprepas funktionen automatiskt (om retry är aktiverat). Fältet role med värdet "free" gör det möjligt att implementera begränsningarna för den kostnadsfria planen direkt i Firestore Security Rules genom att jämföra resource.data.role med den krävda åtkomstnivån.

Generera miniatyr vid bilduppladdning

Det andra exemplet — Storage-utlösare för automatisk generering av en miniatyr (thumbnail) efter bilduppladdning. Funktionen skapar en förminskad kopia på 200x200 pixlar och sparar den på källfilens sökväg med prefixet thumb_. För bildbearbetning används biblioteket sharp, som stöder alla vanliga format och fungerar i Node.js-miljön utan systemberoenden.

import * as path from "path"
import * as os from "os"
import * as sharp from "sharp"

export const generateThumbnail = functions.storage
    .object()
    .onFinalize(async (object) => {
        if (!object.contentType?.startsWith("image/")) return

        const filePath = object.name!
        const thumbPath = filePath.replace(
            /(\.\w+)$/, "_thumb$1"
        )

        const bucket = admin.storage().bucket()
        const tempDir = os.tmpdir()
        const tempFile = path.join(tempDir, path.basename(filePath))

        await bucket.file(filePath).download({ destination: tempFile })
        await sharp(tempFile)
            .resize(200, 200, { fit: "cover" })
            .toFile(tempFile.replace(/(\.\w+)$/, "_thumb$1"))

        await bucket.upload(tempFile.replace(
            /(\.\w+)$/, "_thumb$1"
        ), { destination: thumbPath })
    })

Funktionen generateThumbnail kontrollerar objektets Content-Type och ignorerar icke-bilder, vilket sparar resurser. För arbete med sharp måste beroendet läggas till i package.json. Miniatyren skapas med parametern fit: "cover", som beskär bilden i mitten till en kvadrat på 200x200 pixlar. Efter skapandet laddas miniatyren upp igen till samma bucket med ett modifierat namn.

HTTPS-slutpunkt för offentligt API

Det tredje exemplet — HTTPS-funktion som implementerar en REST API-slutpunkt för att kontrollera serverstatus. Funktionen tar emot en GET-förfrågan och returnerar JSON med information om statusen för de Firebase-tjänster som är anslutna till projektet. Slutpunkten är användbar för övervakning och för externa system som behöver kontrollera backend-tillgängligheten innan de skickar data.

import * as express from "express"

const app = express.Router()

app.get("/status", async (req, res) => {
    try {
        const db = admin.firestore()
        await db.collection("_health").doc("check").get()
        res.json({ status: "ok", timestamp: Date.now() })
    } catch (error) {
        res.status(503).json({ status: "error", message: error })
    }
})

export const api = functions.https.onRequest(app)

Funktionen api använder express Router för routing, vilket är bekvämt när man skapar flera slutpunkter i en funktion. Health check skrivs till Firestore i samlingen _health, vilket gör det möjligt att samtidigt kontrollera Firestore-tillgängligheten. För produktion rekommenderas att lägga till autentisering av förfrågan via API-nyckel eller Firebase Auth-token för att förhindra missbruk av den offentliga slutpunkten.

Typiska användningsscenarier i mobilappar

Cloud Functions används oftast för uppgifter som är omöjliga eller inte önskvärda att utföra på klienten: skicka push-meddelanden, generera förhandsvisningar av uppladdade bilder, integrera med externa betalningssystem, moderera innehåll, synkronisera data mellan Firebase och tredjepartstjänster. Den serverlösa modellen gör dessa uppgifter ekonomiska: avgiften debiteras bara för den faktiska körtiden för koden.

Integration med betalningssystem är ett typiskt scenario för appar med in-app-köp. Cloud Functions tar emot en webhook från betalningsleverantören (Stripe, PayPal), verifierar förfrågans signatur, uppdaterar prenumerationsstatusen i Firestore och skickar en bekräftelse till användaren. Hela koden körs på servern utan risk för datamanipulation på klienten. Enligt Stripe documentation (2026) tar webhook-bearbetning mindre än 500 ms.

Smart innehållsmoderering använder Storage-utlösaren för automatisk kontroll av uppladdade bilder via Google Cloud Vision API. Funktionen skickar bilden till Vision API för att upptäcka osäkert innehåll (våld, vuxeninnehåll) och om tröskeln överskrids tar den bort filen och meddelar administratören. Detta scenario är kritiskt för UGC-appar med användargalleri.

Dataaggregering — Cloud Functions som ersättning för Firebase Realtime Database-räknare. Istället för att läsa och skriva räknaren på klienten (vilket leder till race conditions), använd Firestore-utlösaren onWrite för atomär uppdatering av aggregerade fält. Funktionen beräknar till exempel antalet gillningar för ett inlägg vid varje tillägg eller borttagning av ett dokument i undersamlingen /posts/{postId}/likes/{userId} och uppdaterar fältet likesCount i det överordnade dokumentet.