Crear una función Lambda DELETE en Python con Serverless Framework permite eliminar registros de DynamoDB de forma programática y demuestra que el framework es agnóstico al lenguaje. Esta guía es para quienes ya trabajan con Node.js y quieren expandir su stack serverless a Python sin reescribir su arquitectura.

A lo largo del proyecto trabajamos con create, update e insert, pero faltaba cerrar el ciclo CRUD con el delete. Y aquí viene lo interesante: lo vamos a hacer en otro lenguaje para mostrar que la lógica del framework no cambia, solo la sintaxis.

¿Por qué usar Python para una Lambda en Serverless Framework?

Serverless Framework no obliga a casarte con un lenguaje. Si vienes de JavaScript, Python te va a sentir familiar en estructura, pero con sus propias reglas.

La función delete arranca importando tres dependencias clave en la primera línea del archivo: Boto3 para conectarte con AWS, JSON para serializar respuestas y OS para leer variables de entorno del sistema operativo. Con eso ya puedes alternar entre DynamoDB local y DynamoDB en la nube sin tocar el código de negocio [01:54].

¿Qué es Boto3? Es la librería oficial de AWS para Python. Te permite consumir servicios como DynamoDB, S3 o Lambda usando objetos y métodos nativos del lenguaje.

¿Cómo defino el handler de la función delete en Python?

Cada Lambda nueva exige una entrada propia en el archivo serverless.yaml. Copia el bloque de uploadUser, renómbralo a deleteUsers y cambia el método HTTP de patch a delete para seguir buenas prácticas REST [03:40].

Luego crea la carpeta deleteUsers con un archivo handler.py dentro. La firma del método en Python recibe dos argumentos obligatorios: event y context. A diferencia de JavaScript, aquí no son opcionales.

Para acceder al ID del usuario que vas a borrar, lee los path parameters desde el evento:

python user_id = event['pathParameters']['id']

Esto replica exactamente lo que hacías en Node.js, solo cambia la forma de acceder a las propiedades del diccionario [05:20].

¿Cómo ejecuto el delete contra DynamoDB con Boto3?

El cliente de Boto3 expone el método delete_item sobre el recurso de tabla. Le pasas un objeto Key indicando cuál es la primary key y el valor a eliminar.

python result = table.delete_item( Key={'pk': user_id} )

Después construyes un body amigable usando un f-string que confirme al usuario qué registro se borró, y lo envuelves en json.dumps antes de retornarlo. La respuesta final mantiene la misma estructura que en JavaScript: un objeto con statusCode y body [07:12].

El statusCode lo extraes del JSON que devuelve Boto3, navegando por las llaves ResponseMetadata y luego HTTPStatusCode.

¿Cómo retorno una respuesta válida desde una Lambda en Python? Devuelve un diccionario con statusCode y body, donde el body siempre debe estar serializado con json.dumps para que API Gateway lo procese.

¿Por qué falla mi Lambda con un error 502 Bad Gateway?

Después del primer despliegue con sls deploy, la petición desde Postman responde con 502 Bad Gateway. Aquí entra en escena CloudWatch, el aliado para debugging en producción.

Entrando al grupo de logs de deleteUsers aparece el error real: el runtime estaba buscando un archivo JavaScript. ¿La razón? El bloque provider del serverless.yaml define un runtime global, pero esa función específica está en Python [11:30].

La solución es declarar el runtime a nivel de función:

yaml deleteUsers: handler: deleteUsers/handler.handler runtime: python3.8

Después del segundo despliegue aparece otro error distinto: DynamoDB Service Resource has no attribute table. Es un typo: table con minúscula debe ser Table con mayúscula porque Boto3 distingue mayúsculas en los métodos del recurso [13:10].

¿Qué aprendí del proceso de troubleshooting serverless?

La cadena de errores no es un fracaso, es el flujo real de trabajo en la nube. Cada deploy fallido enseña algo concreto sobre la configuración.

• Especificar runtimes distintos por función cuando mezclas lenguajes en el mismo proyecto.
• Respetar la sensibilidad de mayúsculas en los métodos de Boto3 como Table.
• Usar CloudWatch Logs como primer punto de diagnóstico antes de tocar código.
• Validar que los path parameters estén correctamente mapeados en el evento.

Después del tercer despliegue, la petición DELETE devuelve un status code 200 OK y DynamoDB confirma un usuario menos en la tabla. El proyecto serverless queda completo con las cuatro operaciones CRUD funcionando.

Un detalle curioso del despliegue: las cuatro Lambdas pesan exactamente 18.76 MB cada una. ¿Sabes por qué? Tiene que ver con cómo Serverless Framework empaqueta dependencias por defecto, y existen estrategias para reducir ese tamaño con plugins de empaquetado individual.

¿Qué lenguaje usarías tú para programar tus Lambdas: Python, Java, Rust o te quedas con Node.js? Déjanoslo en los comentarios.