# Cloud Run functions gebruiken voor Workspace-automatisering

[[TOC]]

Niet elke automatisering verdient een eigen server. Voor losse taken die reageren op een gebeurtenis is een serverless functie ideaal: hij draait alleen wanneer nodig, schaalt vanzelf en kost niets als er niks gebeurt. Cloud Run functions zijn de perfecte lijm tussen Workspace-events en je eigen logica.

In dit artikel zie je hoe je ze inzet voor Workspace-automatisering.

:::info title="Cloud Functions heet nu Cloud Run functions"
Sinds 2024 heeft Google "Cloud Functions (2nd gen)" hernoemd naar **Cloud Run functions**, ondergebracht bij Cloud Run. "Cloud Functions (1st gen)" heet nu "Cloud Run functions (1st gen)". Het event-gedreven model uit dit artikel blijft hetzelfde; je krijgt er de extra schaal- en netwerkinstellingen van Cloud Run bij. Kom je de oude naam nog tegen in de console of docs, dan gaat het over dezelfde dienst.
:::

## Waarom serverless

Een Cloud Run function is een stukje code dat draait als reactie op een trigger. Je beheert geen server, geen schaling en geen patches.

- Geen infrastructuur om te onderhouden.
- Automatische schaling van nul naar veel en weer terug.
- Betalen per uitvoering, niet per draaiuur.
- Ingebouwde identiteit, dus geen sleutelbestanden nodig.

:::info title="Keyless authenticatie ingebouwd"
Omdat een functie binnen Google Cloud draait, gebruikt hij de ingebouwde service-identiteit voor authenticatie. Je hoeft geen JSON-sleutel mee te leveren; je kent de functie-identiteit gewoon de juiste rechten toe. Dat is veiliger dan zelf een sleutel beheren, omdat er niets is dat kan uitlekken.
:::

## De drie triggers die ertoe doen

Voor Workspace zijn drie triggertypes het meest relevant. Kies op basis van waar de gebeurtenis vandaan komt.

| Wil je dit? | Gebruik deze trigger |
| --- | --- |
| Reageren op een Workspace-event, zoals een nieuwe e-mail | Pub/Sub-trigger gekoppeld aan een topic |
| Een endpoint voor een webhook, bijvoorbeeld een Chat-app | HTTP-trigger |
| Reageren zodra een bestand of export in Cloud Storage verschijnt | Cloud Storage-trigger |

## Een Pub/Sub-getriggerde functie

Dit is het werkpaard voor event-gedreven automatisering. De functie ontvangt het bericht dat Workspace publiceerde, bijvoorbeeld een Gmail-pushmelding.

:::howto title="Zo zet je een Pub/Sub-functie op"
1. Zet een **Pub/Sub-topic** op en koppel je Workspace-bron eraan met een `watch`-aanvraag (zoals `users.watch` in de Gmail API).
2. Schrijf een functie die de event-payload uit het Pub/Sub-bericht haalt.
3. Verwerk de gebeurtenis, bijvoorbeeld een nieuw mailbericht ophalen en classificeren.
4. Deploy de functie met de Pub/Sub-trigger op dat topic.
5. Ken de functie-identiteit de benodigde **Workspace-scopes** toe.
:::

```python
import base64, json

def verwerk_event(event, context):
    payload = json.loads(base64.b64decode(event['data']).decode())
    history_id = payload.get('historyId')
    # haal gewijzigde berichten op en verwerk ze
```

:::warn title="Gmail-watch verloopt"
Een Gmail `watch` is maximaal zeven dagen geldig. Vernieuw hem periodiek, bijvoorbeeld met een dagelijkse Cloud Scheduler-taak, anders stopt je automatisering stilletjes.
:::

## Een HTTP-getriggerde functie

Voor webhooks of een Chat-app-endpoint gebruik je een HTTP-trigger. De functie ontvangt een request en stuurt een response terug.

:::danger title="Beveilig je endpoint altijd"
Een HTTP-functie is publiek bereikbaar tenzij je hem beveiligt. Valideer altijd de afzender: controleer bij een Chat-app het **bearer-token** van Google, en bij eigen webhooks een gedeeld geheim of een handtekening. Een open endpoint is een uitnodiging voor misbruik.
:::

## Authenticatie naar Workspace

De functie heeft een eigen service-identiteit. Voor toegang tot Workspace-gebruikersdata stel je **domain-wide delegation** in voor die identiteit, net als bij een gewoon service-account, maar zonder dat je ooit een sleutel downloadt.

:::tip title="Hou je aan minste privilege"
Beperk de functie-identiteit tot de minimale rechten en scopes. Een functie die alleen mail leest, hoeft geen schrijfrechten te hebben. Met het principe van minste privilege beperk je de schade als de functie ooit gecompromitteerd raakt.
:::

## Veelgestelde vragen

:::faq
### Welke talen ondersteunen Cloud Run functions?
Onder andere Python, Node.js, Go, Java, .NET, Ruby en PHP, met recente major-versies die in 2026 algemeen beschikbaar zijn. Kies de taal waarin je je Workspace-client het prettigst gebruikt.

### Hoe lang mag een functie draaien?
Dat hangt af van de trigger. Een HTTP-functie kan tot 60 minuten draaien, terwijl event-gedreven functies (zoals Pub/Sub via Eventarc) tot 9 minuten krijgen. Voor langere of zware taken splits je het werk op of gebruik je een Cloud Run-service.

### Wat gebeurt er bij een fout?
Bij een Pub/Sub-trigger wordt het bericht opnieuw aangeboden als je een fout teruggeeft. Maak je verwerking daarom **idempotent**, zodat een herhaalde levering niet dubbel werk doet.

### Kan ik geheimen veilig gebruiken?
Ja. Koppel **Secret Manager** aan je functie zodat geheimen als omgevingsvariabele of gemount bestand beschikbaar zijn, zonder ze in je code te zetten.

### Wat is het verschil met een gewone Cloud Run-service?
Een function is een enkel stukje code rond een trigger; een service is een volledige container die je zelf inricht. Sinds de samenvoeging draaien beide op hetzelfde Cloud Run-platform, dus je kunt later opschalen naar een service zonder van omgeving te wisselen.
:::

Met Cloud Run functions bouw je lichtgewicht, veilige en schaalbare automatisering die naadloos op Workspace-events reageert, zonder ooit een server te beheren.