Firebase Cloud Functions — wat is het, triggers en hoe functies te schrijven

Wat is Firebase Cloud Functions en hoe is het opgebouwd

Firebase Cloud Functions is een computerplatform dat is gebouwd op basis van Google Cloud Functions (GCF) en is aangepast voor het Firebase-ecosysteem. Functies zijn gewone JavaScript- of TypeScript-code die uit een module worden geëxporteerd en voor een specifiek gebeurtenistype worden geregistreerd. Wanneer de gebeurtenis plaatsvindt (bijvoorbeeld een gebruiker registreert zich of uploadt een bestand), voert Firebase Cloud Functions de bijbehorende code uit en geeft deze de context van de gebeurtenis door.

De architectuur van Cloud Functions volgt het beginsel van enkele verantwoordelijkheid: één functie verwerkt één gebeurtenistype en voert één atomaire bewerking uit. Zo wordt de functie sendWelcomeEmail aangeroepen wanneer een nieuwe gebruiker in Firebase Authentication wordt aangemaakt en stuurt een welkomstmail. Dergelijke isolatie vereenvoudigt het debuggen, testen en hergebruiken van functies in verschillende projecten.

Elke functie draait in een geïsoleerde container met een tijdelijk levenscyclus. De maximale uitvoeringstijd is standaard 60 seconden (HTTPS-functies — 9 minuten). Als een functie niet binnen de time-out valt, eindigt het verzoek met fout 500. Gebruik voor lange bewerkingen Cloud Tasks of Pub/Sub met herhaalde pogingen. Containers kunnen worden hergebruikt voor volgende aanroepen (keep-alive), wat de latentie bij koude starts na de eerste aanroep vermindert.

Uitvoeromgeving en Node.js-versies

Firebase Cloud Functions ondersteunt verschillende Node.js-versies: 18, 20 en 22 (aanbevolen voor nieuwe projecten). De versiekeuze wordt ingesteld in het veld engines van het bestand package.json. Firebase CLI configureert automatisch de uitvoeromgeving op basis van de opgegeven versie. Belangrijk: Firebase Cloud Functions ondersteunt het draaien van willekeurige Docker-containers niet — de omgeving is strikt vastgesteld door Google Cloud Functions.

Voor nieuwe projecten wordt Node.js 22 aanbevolen, omdat het de nieuwste V8-optimalisaties, verbeterde ondersteuning voor ESM-modules en WebSocket-ondersteuning op platformniveau bevat. Als het project afhankelijkheden gebruikt die voor een specifieke Node-versie zijn gecompileerd (bijvoorbeeld native C++-modules), moet de compatibiliteit afzonderlijk worden gecontroleerd — niet alle native modules compileren in de GCF-omgeving.

Verschil tussen Firebase Cloud Functions en Google Cloud Functions

Firebase Cloud Functions is een omhulsel boven Google Cloud Functions met vooraf geïnstalleerde Firebase SDK en integratie met Firebase-services. De ontwikkelaar schrijft code met de firebase-functions SDK, die getypeerde triggers voor alle Firebase-services biedt. Google Cloud Functions — een platform op lager niveau, waar triggers expliciet worden geconfigureerd via Eventarc of Pub/Sub.

Het belangrijkste verschil: in Firebase Cloud Functions wordt de trigger declaratief geregistreerd via de aanroep functions.firestore.document('path').onWrite(), en in Google Cloud Functions — via Eventarc-configuratie met filtering op gebeurteniskenmerken. Firebase Cloud Functions wordt ook automatisch geleverd met Admin SDK, geïnitialiseerd met de rechten van het serviceaccount van het project, wat volledige toegang geeft tot alle Firebase-services zonder extra configuratie.

Soorten triggers: welke gebeurtenissen worden ondersteund

Firebase Cloud Functions ondersteunt 8 categorieën triggers, elk overeenkomend met een specifieke Firebase- of Google Cloud-service. Een trigger is een voorwaarde waarbij de functie automatisch wordt aangeroepen. De ontwikkelaar beheert de levenscyclus van de functie niet rechtstreeks: Firebase CLI registreert de trigger in Google Cloud Eventarc en het cloudplatform start de functie zelf wanneer de gebeurtenis plaatsvindt.

De populairste triggers zijn Firestore-triggers: onWrite, onCreate, onUpdate, onDelete. Ze worden geactiveerd wanneer documenten in Firestore-collecties veranderen. De functie ontvangt snapshots van het document voor en na de wijziging, waardoor waarden kunnen worden vergeleken en er alleen op specifieke wijzigingen kan worden gereageerd. Bijvoorbeeld: wanneer de status van een bestelling verandert van „pending” in „shipped”, kunt u een pushmelding naar de gebruiker sturen.

Authentication-triggers (onCreate, onDelete) worden geactiveerd bij het aanmaken of verwijderen van een account. Ze worden gebruikt voor het initialiseren van gebruikersgegevens: het aanmaken van een gebruikersdocument in Firestore, het verzenden van een welkomstmail, het schrijven naar analytics. Belangrijk: de functie kan het aanmaken van de gebruiker niet annuleren — deze wordt uitgevoerd nadat het account al is aangemaakt. Gebruik voor pre-validatie de blokkerende functies (Blocking Functions), beschikbaar op het platform Identity Platform.

HTTPS-triggers en CORS

HTTPS-functies (onRequest) maken het mogelijk volledige REST API-endpoints te maken die via HTTP toegankelijk zijn. In tegenstelling tot gebeurtenistriggers worden HTTPS-functies aangeroepen via een URL van de vorm https://{region}-{project}.cloudfunctions.net/{functionName}. Het is belangrijk om CORS correct te configureren als het endpoint vanuit een browser of mobiele app wordt aangeroepen. Firebase SDK voegt CORS-headers niet automatisch toe — ze moeten handmatig via middleware worden toegevoegd.

Voor mobiele clients (Android, iOS) is CORS niet nodig, omdat native HTTP-clients niet worden beperkt door het Cross-Origin-beleid. CORS is alleen relevant voor webverzoeken. Als uw HTTPS-functie zowel vanuit de app als vanuit het web wordt aangeroepen, voeg dan universele CORS-afhandeling toe: res.set('Access-Control-Allow-Origin', '*') voor development of een lijst met toegestane domeinen voor production.

Planning met Pub/Sub en Cloud Scheduler

Gebruik voor periodieke uitvoering (cron-taken) de combinatie van Cloud Scheduler en Pub/Sub. Cloud Scheduler stuurt volgens schema een bericht naar het Pub/Sub-topic en de Cloud Functions-trigger onPublish verwerkt dit bericht. Firebase CLI ondersteunt geen directe cron-syntaxis — het schema wordt ingesteld via de Google Cloud-console of Terraform in unix-cron-formaat: 0 3 * * * (dagelijks om 3:00).

Voorbeelden van taken: dagelijkse nieuwsbrief, opschonen van verouderde gegevens, genereren van rapporten, synchronisatie met externe API's. Belangrijk: Cloud Scheduler is een betaalde Google Cloud-service (ongeveer $2 per maand per job). Elke activering telt als een afzonderlijke functie-aanroep en wordt gefactureerd tegen de standaardprijzen van Cloud Functions.

Hoe functies te schrijven en te implementeren

Ontwikkeling van Cloud Functions begint met de initialisatie van het project via Firebase CLI: firebase init functions. Deze opdracht maakt een map functions/ aan met het sjabloon index.js (of index.ts), het bestand package.json en TypeScript-configuratie (indien geselecteerd). Na initialisatie volstaat het om een functie te schrijven, deze uit de module te exporteren en firebase deploy --only functions uit te voeren voor implementatie.

Elke functie wordt geregistreerd via de aanroep van de methode van de bijbehorende trigger. Voorbeeld van een HTTPS-functie: exports.helloWorld = functions.https.onRequest((req, res) => { res.send("Hello!"); }). Firebase-functies gebruiken het asynchrone model: voor gebeurtenistriggers (niet HTTPS) moet de functie een Promise retourneren. Firebase wacht op de voltooiing van de Promise voordat de container wordt gesloten. Als de Promise niet wordt geretourneerd, kan de functie worden afgebroken voordat de asynchrone bewerkingen zijn voltooid.

Lokale ontwikkeling verloopt via Firebase Emulator Suite, dat een Cloud Functions-emulator bevat. De opdracht firebase emulators:start start een lokale server met functies, toegankelijk op http://localhost:5001. De emulator ondersteunt hot reload bij codewijzigingen en is volledig geïsoleerd van de productieomgeving, waardoor functies kunnen worden getest zonder risico voor echte gegevens.

Beheer van afhankelijkheden en configuratie

Afhankelijkheden van Cloud Functions worden beheerd via package.json. Firebase installeert alleen productie-afhankelijkheden (dependencies, niet devDependencies). De omvang van het functiepakket beïnvloedt de koude starttijd: het wordt aanbevolen het aantal afhankelijkheden te minimaliseren. Voor het werken met Firebase Admin SDK is de afhankelijkheid firebase-admin al vooraf geïnstalleerd — deze hoeft niet handmatig te worden toegevoegd.

Vertrouwelijke gegevens (API-sleutels, tokens) mogen niet in de functiecode worden opgeslagen. Gebruik functions.config() voor het opslaan van configuratie: firebase functions:config:set stripe.key="sk_...". Waarden worden versleuteld en zijn in runtime beschikbaar via functions.config().stripe.key. Gebruik voor grote geserialiseerde configuraties Google Cloud Secret Manager.

Foutafhandeling en logging

Logging in Cloud Functions gebeurt via console.log, console.warn en console.error. Alle logs worden automatisch verzameld in Google Cloud Logging en zijn beschikbaar in de Firebase-console (sectie Functions > Logs). Gebruik voor gestructureerde logging de bibliotheek winston of pino, die JSON-formattering en logniveaus ondersteunen.

Foutafhandeling is cruciaal voor betrouwbaarheid: een niet-afgehandelde uitzondering in een Promise beëindigt de functie met een fout, waarna Firebase de aanroep automatisch herhaalt (retry) met exponentiële vertraging. Het aantal retries wordt geconfigureerd: van 0 tot oneindig. Voor gebeurtenistriggers wordt aanbevolen retry in te schakelen om de verwerking van elke gebeurtenis te garanderen, zelfs bij tijdelijke storingen van externe services.

Koude start en schalen

Koude start (cold start) — de vertraging bij de eerste aanroep van een functie na een periode van inactiviteit, wanneer de container met code opnieuw wordt geladen en geïnitialiseerd. Volgens Firebase documentation (2026) duurt een koude start van 200 ms tot 2 seconden, afhankelijk van de pakketgrootte, het aantal afhankelijkheden en de regio. Voor de gebruikersinterface is een vertraging van meer dan 1 seconde merkbaar en kan deze de user experience beïnvloeden.

Manieren om de koude start te minimaliseren: minimaliseer afhankelijkheden, gebruik TypeScript met compilatie naar CommonJS, verklein het functiepakket, stel het minimum aantal actieve instanties in. Firebase Cloud Functions v2 (2nd gen) maakt het mogelijk minInstances in te stellen — het minimum aantal opgewarmde containers dat altijd klaar is om verzoeken te verwerken. Voor het opwarmen van containers wordt een vergoeding voor inactieve tijd in rekening gebracht.

Schalen van Cloud Functions gebeurt automatisch: bij een toename van het aantal verzoeken maakt Firebase nieuwe containers aan. Standaard is het maximum aantal parallelle instanties 3000 (quotum van het Google Cloud-project). Elke instantie verwerkt tegelijkertijd één verzoek. Als een functie snel is (minder dan 100 ms), kan één instantie tot 10 verzoeken per seconde verwerken, wat een piekdoorvoer tot 30 000 verzoeken per seconde per project oplevert.

Configuratie van minInstances en maxInstances

minInstances — een parameter die het opgegeven aantal containers reserveert en ze opgewarmd houdt. Wordt aanbevolen voor kritieke HTTPS-functies waar de koude startvertraging onaanvaardbaar is. Stel bijvoorbeeld minInstances: 1 in voor een authenticatie-endpoint. maxInstances — een limiet op het maximum aantal parallelle instanties, nuttig om oncontroleerbare kostengroei bij een plotselinge verkeerspiek te voorkomen.

De configuratie gebeurt in code: functions.runWith({ minInstances: 1, maxInstances: 10 }). Belangrijk: minInstances verhoogt de kosten, omdat de container continu werkt. Voor testprojecten moet minInstances worden uitgeschakeld. Voor productie wordt minInstances aanbevolen voor alle openbare HTTPS-functies en 0 voor gebeurtenistriggers, waar een vertraging van 1 seconde niet kritiek is.

Implementatieregio's

De implementatieregio beïnvloedt de latentie voor eindgebruikers en de kosten van uitgaand verkeer. Firebase Cloud Functions is beschikbaar in 30+ Google Cloud-regio's. Kies voor mobiele apps de regio die het dichtst bij uw doelgroep ligt: us-central1 voor Amerika, europe-west1 voor Europa, asia-east2 voor Azië. De regio kan na deploy niet worden gewijzigd zonder de functie opnieuw te implementeren.

Het wijzigen van de regio gebeurt via de parameter region in code: functions.region('europe-west1'). Alle functies in één bestand kunnen verschillende regio's hebben. Voor wereldwijde projecten wordt aanbevolen functies in meerdere regio's te implementeren en Cloud Load Balancing te gebruiken voor verkeersverdeling, hoewel voor de meeste mobiele apps één regio voldoende is bij een juiste keuze.

Codevoorbeelden voor Firebase Cloud Functions

Laten we praktische voorbeelden van Cloud Functions in TypeScript bekijken. De code gebruikt Firebase Functions SDK v2 (2nd gen) met ES-modulaire syntaxis. De voorbeelden omvatten het verwerken van het gebruikersaanmaak-gebeurtenis, het genereren van een thumbnail bij het uploaden van een afbeelding en een eenvoudig HTTPS-endpoint voor REST API. Alle functies zijn asynchroon met het retourneren van een Promise voor een correcte afronding van de container.

Zorg er vóór uitvoering voor dat Firebase CLI is bijgewerkt naar versie 13+: npm install -g firebase-tools. v2-functies vereisen het tariefplan Blaze. Initialisatie: firebase init functions met de selectie van TypeScript.

Verwerking van gebruikersregistratie

Het eerste voorbeeld — het aanmaken van een document in Firestore bij de registratie van een nieuwe gebruiker. De functie wordt geactiveerd door de gebeurtenis auth.user().onCreate en schrijft een basisprofiel naar de collectie users/{uid}. Dit maakt het mogelijk te garanderen dat voor elke geregistreerde gebruiker een document met de vereiste velden bestaat.

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}`)
    })

De functie createUserProfile is asynchroon — deze retourneert een Promise die Firebase afwacht vóór voltooiing. Als het schrijven naar Firestore met een fout eindigt (bijvoorbeeld door ontbrekende rechten), wordt de functie automatisch herhaald (als retry is ingeschakeld). Het veld role met de waarde "free" maakt het mogelijk beperkingen van het gratis tarief rechtstreeks in Security Rules van Firestore te implementeren door resource.data.role te vergelijken met het vereiste toegangsniveau.

Genereren van thumbnail bij upload van afbeelding

Het tweede voorbeeld — een Storage-trigger voor het automatisch genereren van een miniatuur (thumbnail) na het uploaden van een afbeelding. De functie maakt een verkleinde kopie van 200x200 pixels en slaat deze op in het pad van het bronbestand met het voorvoegsel thumb_. Voor het verwerken van afbeeldingen wordt de bibliotheek sharp gebruikt, die alle gangbare formaten ondersteunt en werkt in de Node.js-omgeving zonder systeemafhankelijkheden.

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 })
    })

De functie generateThumbnail controleert het Content-Type van het object en negeert niet-afbeeldingen, wat resources bespaart. Voor het werken met sharp moet de afhankelijkheid aan package.json worden toegevoegd. De thumbnail wordt gemaakt met de parameter fit: "cover", die de afbeelding in het midden bijsnijdt tot een vierkant van 200x200 pixels. Na het maken wordt de thumbnail teruggeüpload naar dezelfde bucket met een gewijzigde naam.

HTTPS-endpoint voor publieke API

Het derde voorbeeld — een HTTPS-functie die een REST API-endpoint implementeert voor het controleren van de serverstatus. De functie accepteert een GET-verzoek en retourneert JSON met informatie over de status van de Firebase-services die aan het project zijn gekoppeld. Het endpoint is nuttig voor monitoring en voor externe systemen die de beschikbaarheid van de backend moeten controleren voordat gegevens worden verzonden.

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)

De functie api gebruikt express Router voor routing, wat handig is bij het maken van meerdere endpoints in één functie. De health check wordt in Firestore geschreven naar de collectie _health, waardoor tegelijkertijd de beschikbaarheid van Firestore kan worden gecontroleerd. Voor productie wordt aanbevolen authenticatie van het verzoek toe te voegen via een API-sleutel of Firebase Auth-token om misbruik van het publieke endpoint te voorkomen.

Typische gebruiksscenario's in mobiele apps

Cloud Functions worden het vaakst gebruikt voor taken die niet op de client kunnen of mogen worden uitgevoerd: het verzenden van pushmeldingen, het genereren van voorbeelden van geüploade afbeeldingen, integratie met externe betalingssystemen, inhoudsmoderatie, synchronisatie van gegevens tussen Firebase en services van derden. Het serverless model maakt deze taken economisch: de vergoeding wordt alleen in rekening gebracht voor de werkelijke uitvoeringstijd van de code.

Integratie met betalingssystemen — een typisch scenario voor apps met in-app-aankopen. Cloud Functions ontvangt een webhook van de betalingsprovider (Stripe, PayPal), verifieert de handtekening van het verzoek, werkt de abonnementsstatus in Firestore bij en stuurt de gebruiker een bevestiging. Alle code wordt op de server uitgevoerd zonder risico op datamanipulatie op de client. Volgens Stripe documentation (2026) duurt de verwerking van een webhook minder dan 500 ms.

Slimme inhoudsmoderatie gebruikt een Storage-trigger om geüploade afbeeldingen automatisch te controleren via Google Cloud Vision API. De functie stuurt de afbeelding naar Vision API voor detectie van onveilige inhoud (geweld, inhoud voor volwassenen) en verwijdert het bestand en waarschuwt de beheerder als de drempel wordt overschreden. Dit scenario is cruciaal voor UGC-apps met gebruikersgalerijen.

Gegevensaggregatie — Cloud Functions als vervanging voor Firebase Realtime Database-tellers. In plaats van het lezen en schrijven van een teller op de client (wat leidt tot race conditions), gebruikt u de Firestore-trigger onWrite voor atomair bijwerken van geaggregeerde velden. De functie berekent bijvoorbeeld het aantal likes van een bericht bij elke toevoeging of verwijdering van een document in de subcollectie /posts/{postId}/likes/{userId} en werkt het veld likesCount in het bovenliggende document bij.