Ja saps que una funció Lambda s’executa quan ocorre un esdeveniment (subcapítol 14.1). Però quins esdeveniments? Qui «crida» la funció? Això ho defineixen els triggers (desencadenants): les fonts que invoquen la teva Lambda. En aquest subcapítol veurem els més importants i com obren la porta a un munt d’arquitectures.

Què és un trigger

Un trigger (desencadenant) és el que fa que la teva funció s’executi. Tu connectes una font d’esdeveniments a la teva Lambda, i cada vegada que aquesta font genera un esdeveniment, AWS invoca la teva funció automàticament, passant-li les dades de l’esdeveniment.

   Font d’esdeveniments   ──(esdeveniment)──►   Lambda s’executa
   (API, S3, cua...)

Una mateixa funció pot tenir un o diversos triggers. Vegem els quatre més comuns.

  1. API Gateway: convertir la teva Lambda en una API web

API Gateway permet que la teva Lambda respongui a peticions HTTP, igual que una API web normal. És la manera de crear backends i APIs serverless.

Usuari / app mòbil
      │ HTTP (GET /productes)
      ▼
  API Gateway  ──invoca──►  Lambda  ──► consulta dades ──► respon JSON

Exemple del món real: una app mòbil necessita un backend que retorni la llista de productes. En comptes de muntar un servidor sempre encès (EC2), poses API Gateway + Lambda: quan l’app fa GET /productes, API Gateway invoca la teva Lambda, que retorna les dades. Si ningú fa servir l’app a la nit, no pagues res. Si de dia la fan servir milers, escala sol.

Aquest és un dels patrons serverless més populars, i la base del projecte del blog serverless que veurem al Capítol 33.

  1. S3: reaccionar a fitxers pujats

Recorda S3, l’emmagatzematge d’objectes (Capítol 5). Pots configurar un bucket perquè cada vegada que es puja (o esborra) un fitxer, dispari una Lambda.

Usuari puja una foto a S3
      │
      ▼
  S3 dispara ──► Lambda ──► genera una miniatura / l’analitza / la processa

Exemple clàssic: una web on els usuaris pugen fotos. Quan una imatge arriba al bucket de S3, es dispara una Lambda que crea automàticament una miniatura (versió petita) i la desa. L’usuari no espera: la foto es processa «sola» en segon pla. Altres usos: convertir formats, extreure text, escanejar per buscar virus, etc.

  1. DynamoDB Streams: reaccionar a canvis a la base de dades

Recorda DynamoDB (subcapítol 8.3). Un DynamoDB Stream és un «registre de canvis» de la taula: cada vegada que es crea, modifica o esborra un element, pot disparar una Lambda amb el detall del canvi.

S’insereix una comanda a la taula DynamoDB
      │
      ▼
  DynamoDB Stream dispara ──► Lambda ──► envia email de confirmació,
                                          actualitza estadístiques...

Exemple: en una botiga, quan s’insereix una nova comanda a la taula Comandes, el stream dispara una Lambda que envia un email de confirmació al client i actualitza un panell de vendes. La base de dades «avisa» dels seus propis canvis, i la lògica reacciona automàticament.

  1. SQS: processar missatges d’una cua

Recorda les cues (les veurem a fons al Capítol 15). Una cua SQS acumula missatges (tasques pendents), i una Lambda pot anar processant-los un a un o en lots.

Tasques s’acumulen a la cua SQS
   [tasca] [tasca] [tasca] [tasca]
      │
      ▼
  SQS dispara ──► Lambda ──► processa cada tasca (al seu ritme)

Exemple: una botiga rep milers de comandes en una allau (Black Friday). En comptes de processar-les totes de cop i saturar-se, les posa en una cua SQS. Una Lambda les va traient i processant a un ritme sostenible. La cua actua d’«amortidor» (ho veurem com a desacoblament al Capítol 15).

Taula resum de triggers

Trigger Es dispara quan... Cas d’ús típic
API Gateway Arriba una petició HTTP APIs i backends serverless
S3 Es puja/esborra un fitxer Processar imatges, fitxers
DynamoDB Streams Canvia una dada a la taula Reaccionar a canvis (emails, stats)
SQS Hi ha missatges a la cua Processar tasques en segon pla

I n’hi ha molts més: CloudWatch (tasques programades tipus «cada nit a les 2:00»), SNS (notificacions), EventBridge (esdeveniments del sistema, Capítol 15), Kinesis (streaming de dades, Capítol 29), etc.

La idea poderosa: arquitectures dirigides per esdeveniments

El més important dels triggers és el patró que habiliten: les arquitectures dirigides per esdeveniments (event-driven). En comptes d’un gran programa monolític que ho fa tot, tens petites funcions que reaccionen a esdeveniments:

Puja foto → Lambda crea miniatura
Nova comanda → Lambda envia email
Missatge a la cua → Lambda processa la tasca
Arriba petició HTTP → Lambda respon

Cada peça és petita, independent i s’executa només quan cal. Això fa els sistemes més flexibles, desacoblats i barats. Aprofundirem en aquests patrons als Capítols 15 i 28.

El que has de recordar

  • Un trigger (desencadenant) és la font que invoca la teva Lambda quan ocorre un esdeveniment; connectes la font i AWS crida la teva funció automàticament.
  • API Gateway: peticions HTTP → la teva Lambda actua com a API/backend serverless.
  • S3: un fitxer pujat → processar imatges, convertir formats, escanejar...
  • DynamoDB Streams: un canvi a la base de dades → reaccionar (emails, estadístiques).
  • SQS: missatges en una cua → processar tasques en segon pla a un ritme sostenible.
  • Els triggers habiliten les arquitectures dirigides per esdeveniments: petites funcions que reaccionen a esdeveniments, més flexibles i barates que un monòlit.

Al següent subcapítol veurem un aspecte pràctic clau: com gestionar les dependències (llibreries) de la teva funció i reutilitzar codi amb les capes (Layers).

Cloud, AWS & Terraform — De zero a expert

Capítol 1 · Què és el cloud computing

Capítol 2 · El mercat cloud i els grans proveïdors

Capítol 3 · Regions, zones de disponibilitat i edge

Capítol 4 · Càlcul: EC2

Capítol 5 · Emmagatzematge: S3

Capítol 6 · Xarxes: VPC

Capítol 7 · Identitat i accés: IAM

Capítol 8 · Bases de dades gestionades

Capítol 9 · Per què Infraestructura com a Codi

Capítol 10 · HCL: el llenguatge de Terraform

Capítol 11 · Providers i estat

Capítol 12 · La teva primera infraestructura real amb Terraform

Capítol 13 · Balanceig de càrrega i autoescalat

Capítol 14 · Serverless amb Lambda

Capítol 15 · Missatgeria i esdeveniments

Capítol 16 · Lliurament de contingut i DNS

Capítol 17 · Contenidors a AWS

Capítol 18 · Mòduls: reutilització i composició

Capítol 19 · Workspaces i gestió d'entorns

Capítol 20 · Backends remots i locking

Capítol 21 · Testing d'infraestructura

Capítol 22 · Terraform en CI/CD

Capítol 23 · Seguretat en profunditat

Capítol 24 · Observabilitat: logs, mètriques i traces

Capítol 25 · Optimització de costos

Capítol 26 · Alta disponibilitat i disaster recovery

Capítol 27 · Well-Architected Framework d'AWS

Capítol 28 · Arquitectures serverless a escala

Capítol 29 · Plataformes de dades a AWS

Capítol 30 · Multi-compte i landing zones

Capítol 31 · Platform Engineering i Internal Developer Platform

Capítol 32 · Certificacions AWS rellevants

Capítol 33 · Projectes per consolidar el que s'ha après

Capítol 34 · Recursos i comunitat

© Copyright 2024. Tots els drets reservats