Proyecto 2 – Backend serverless para app de notas en AWS

← Volver a Proyectos Cloud

Diseño y despliegue de un backend completamente serverless para una app de notas personales, utilizando API Gateway, AWS Lambda, DynamoDB y autenticación basada en JWT.

Servicios: API Gateway, Lambda, DynamoDB, Cognito (o proveedor externo de identidad), IAM, CloudWatch.

1. Descripción general

En este proyecto he construido el backend de una aplicación de notas personales sin servidores (serverless) en AWS. Cada usuario puede registrarse, iniciar sesión y crear, listar y borrar sus propias notas.

El objetivo principal ha sido entender cómo encajan las piezas de una arquitectura serverless: API Gateway para exponer endpoints HTTP, AWS Lambda para ejecutar la lógica de negocio bajo demanda, DynamoDB como base de datos NoSQL, y un sistema de autenticación con JWT para asegurar que cada usuario solo accede a sus datos.

2. Objetivo del proyecto

• Definir una API REST sencilla para gestionar notas (POST /notes, GET /notes, DELETE /notes/{id}).
• Implementar la lógica de negocio con funciones AWS Lambda.
• Diseñar una tabla DynamoDB para almacenar notas por usuario.
• Proteger la API con autenticación basada en tokens JWT.
• Configurar logs y monitorización con CloudWatch.

Con este proyecto demuestro que sé trabajar con patrones serverless, separación de responsabilidades y control de acceso a recursos en AWS.

3. Arquitectura implementada

La arquitectura se basa en servicios gestionados de AWS, donde no administro servidores directamente, sino configuración y permisos.

3.1 Región de despliegue

• Región de trabajo: por ejemplo eu-west-1 (Irlanda), por cercanía y baja latencia.

Todos los recursos serverless (API Gateway, Lambda, DynamoDB) se han creado en la misma región para minimizar latencia y simplificar la configuración.

3.2 API REST con Amazon API Gateway

Definí una API REST en Amazon API Gateway con los siguientes endpoints:

• POST /notes – Crea una nueva nota.
• GET /notes – Lista todas las notas del usuario autenticado.
• DELETE /notes/{noteId} – Elimina una nota concreta del usuario.

Cada endpoint está integrado con una función Lambda y protegido mediante un authorizer basado en JWT, que valida el token enviado en el header Authorization: Bearer <JWT>.

3.3 Lógica de negocio con AWS Lambda

Para la lógica de la API implementé varias funciones Lambda, por ejemplo:

• CreateNoteFunction – Maneja las peticiones POST /notes.
• ListNotesFunction – Maneja las peticiones GET /notes.
• DeleteNoteFunction – Maneja las peticiones DELETE /notes/{noteId}.

Cada función:

• Recibe el evento de API Gateway (ruta, parámetros, cuerpo, cabeceras).
• Extrae el identificador de usuario (por ejemplo, sub) del token JWT.
• Lee o escribe en la tabla de DynamoDB usando el SDK de AWS.
• Devuelve una respuesta en formato JSON con el código HTTP adecuado.

3.4 Almacenamiento de datos con DynamoDB

Para el almacenamiento de notas utilicé Amazon DynamoDB, una base de datos NoSQL totalmente gestionada.

• Nombre de tabla: por ejemplo, notes.
• Partition key: userId.
• Sort key: noteId.

Cada ítem de la tabla representa una nota:

{
  "userId": "sub-del-usuario",
  "noteId": "uuid-generado",
  "title": "Comprar comida",
  "content": "Leche, huevos, pan",
  "createdAt": "2025-11-18T19:30:00Z"
}

De esta forma, las operaciones de lectura/escritura están optimizadas para el patrón “todas las notas de un usuario” o “una nota concreta de un usuario”.

3.5 Autenticación y autorización (JWT)

Para la autenticación he utilizado tokens JWT. La arquitectura asume un proveedor de identidad (por ejemplo, Amazon Cognito o un IdP externo) que emite el token cuando el usuario inicia sesión.

En API Gateway configuré un JWT Authorizer que:

• Valida la firma del token.
• Comprueba el emisor y el público (issuer, audience).
• Expone los claims del token a la función Lambda (por ejemplo, el sub como userId).

Gracias a esto, cada petición está asociada a un usuario concreto y la función Lambda usa ese userId para leer o escribir solo sus notas en DynamoDB.

3.6 Permisos con IAM

Cada función Lambda tiene asociado un rol de ejecución IAM con permisos mínimos:

• Permiso para leer y escribir únicamente en la tabla notes.
• Permiso para escribir logs en CloudWatch Logs.

De esta forma se aplica el principio de mínimo privilegio: las funciones solo pueden acceder a los recursos que realmente necesitan.

3.7 Logging y monitorización

API Gateway y Lambda envían logs a Amazon CloudWatch. Esto me permite:

• Ver las peticiones que llegan a la API.
• Inspeccionar errores en la ejecución de las funciones.
• Revisar tiempos de respuesta y comportamiento general del sistema.

4. Flujo de una petición típica (POST /notes)

Este es el recorrido de una petición para crear una nota:

1. El cliente (por ejemplo, una SPA o app móvil) envía una petición POST /notes a la URL de API Gateway, con el header Authorization: Bearer <JWT> y un cuerpo JSON:

   {
     "title": "Comprar comida",
     "content": "Leche, huevos, pan"
   }

2. API Gateway recibe la petición y pasa el token al JWT Authorizer.
3. El authorizer valida el token. Si es correcto, extrae el userId (claim sub) y permite la invocación de la función Lambda asociada a POST /notes.
4. La función Lambda:
   • Lee el cuerpo JSON de la petición.
   • Genera un noteId (por ejemplo, un UUID).
   • Construye el ítem y lo guarda en la tabla notes de DynamoDB.
5. Lambda devuelve una respuesta JSON a API Gateway, algo como:

   {
     "noteId": "uuid-generado",
     "userId": "sub-del-usuario",
     "title": "Comprar comida",
     "content": "Leche, huevos, pan",
     "createdAt": "2025-11-18T19:30:00Z"
   }

6. API Gateway devuelve esta respuesta al cliente con código HTTP 201 Created.

5. Buenas prácticas aplicadas y lecciones aprendidas

Con este proyecto he consolidado varios conceptos clave de arquitecturas serverless en la nube:

• Diseño de APIs REST: definición de recursos, métodos HTTP y modelos de datos claros para una app de notas.
• Serverless compute: uso de AWS Lambda para ejecutar lógica bajo demanda sin gestionar servidores ni escalado manual.
• Almacenamiento NoSQL: modelado de datos en DynamoDB orientado a patrones de acceso (notas por usuario, nota concreta).
• Autenticación y autorización: protección de la API con JWT y control de acceso a nivel de usuario.
• Seguridad y permisos: configuración de roles IAM con mínimo privilegio para Lambda y acceso a DynamoDB.
• Observabilidad: uso de CloudWatch para logs y monitorización de la API y las funciones.

Este backend serverless es una base sólida para futuras mejoras, como añadir paginación, etiquetas en las notas, tests automatizados, integración con un frontend o despliegue mediante Infrastructure as Code (por ejemplo, con SAM o Terraform).

← Volver a Proyectos Cloud