Bienvenida

1

Desarrollo y Despliegue con Serverless Framework en AWS

2

Implementación de Serverless en AWS: API Gateway, Lambda y DynamoDB

Conceptos Claves

3

Ecosistema Serverless y Serverless Framework en AWS

4

Ventajas y desventajas de servicios y framework serverless

Explicación de Serverless Framework

5

Integración de Serverless Framework en AWS

6

Configuración de Entorno de Desarrollo Serverless en Windows

7

Preparación de entorno local con Serverless Framework en macOS

8

Serverless YAML: Estructura y Uso en Frameworks Cloud

Ecosistema Serverless en AWS

9

Creación y despliegue de una aplicación serverless básica

10

Creación y Gestión de Aplicaciones con Serverless Framework

11

Pruebas de Funciones Lambda en Local con Serverless Framework

Desarrollando con Serverless Framework

12

Creación y Configuración de CRUD Serverless con DynamoDB

13

Configuración y uso de DynamoDB Local con Serverless

14

Despliegue de Aplicaciones Serverless con DynamoDB en AWS

15

Inserción de Usuarios en DynamoDB con Funciones Lambda

16

Actualización de Usuarios en DynamoDB con Serverless Framework

17

Función Lambda Delete en Python para DynamoDB Serverless

18

Integración de AWS Free Tier con Serverless Framework

Bonus

19

Configuración de AWS Budgets para Control de Costos

20

Integración de GitHub Actions con AWS para CI/CD Serverless

21

Despliegue Automático con GitHub Actions y Serverless Framework

22

Optimización de Despliegue y Tamaño en AWS Lambda

Cierre del curso

23

Eliminación de Recursos y Claves en AWS con Serverless Framework

24

Proyecto Serverless Avanzado en AWS

Crea tus API’s con Serverless Framework y ChatGPT

25

Creación de APIs con Serverless Framework y ChatGPT

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Despliegue de Aplicaciones Serverless con DynamoDB en AWS

14/25
Recursos

¿Cómo podemos manejar el ambiente al desplegar a la nube?

¡Desplegar aplicaciones a la nube puede ser un desafío! Aunque ya probamos nuestra aplicación GET y parece lista para ir a la nube, hay diferencias sutiles entre el entorno local y la nube que deben ser consideradas. Estos detalles son esenciales para evitar errores y asegurar un desarrollo uniforme entre ambientes.

Uso de variables de entorno

Las variables de entorno son claves cuando trabajamos en múltiples ambientes. En la aplicación local, nuestro cliente de DynamoDB se conecta a una base de datos local, sin embargo, para el despliegue en la nube, eso podría ocasionar un error al intentar llegar al localhost.

La solución es usar process.env para determinar si estamos trabajando en local o en la nube. Si la variable IS_OFFLINE está definida, estamos en local; de lo contrario, en la nube. Así:

let dynamoDBClientParams = {};
if (process.env.IS_OFFLINE) {
    dynamoDBClientParams = {
        // Parámetros locales aquí
    };
}

Ajuste del endpoint de la función Lambda

Al desplegar en la nube, un problema frecuente es que la Lambda intenta conectarse a un recurso que no está disponible. Por defecto, cuando no se especifica un endpoint, esta se conecta a la base de datos adecuada en la nube, resolviendo el problema automáticamente.

¿Cómo manejar IDs dinámicos en las solicitudes?

El manejo de IDs fijos no es factible. Por lo tanto, necesitamos extraer dinámicamente los IDs de la URL. Esto se logra mediante el uso del objeto event que proporciona información sobre el evento HTTP que desencadena la función Lambda.

const userId = event.pathParameters.id;

Configuración del path parameter en Serverless

En el archivo serverless.yml, debemos indicar que esperamos un parámetro en la ruta. Esto se configura simplemente así:

functions:
  getUser:
    handler: handler.getUser
    events:
      - http:
          path: users/{id}
          method: get

¿Cómo podemos resolver errores comunes?

Es común encontrar errores al desplegar en la nube, como el de "Access Denied". Esto suele ser causado por permisos insuficientes del rol de AWS asociado. AWS presta especial atención a la seguridad, por lo que debemos otorgar permisos explícitamente.

Solucionar errores de permisos con IAM

A través de IAM, se deben conceder permisos específicos a las funciones Lambda, especialmente cuando interactúan con servicios como DynamoDB. Configuramos estos permisos editando el archivo serverless.yml.

provider:
  iamRoleStatements:
    - Effect: "Allow"
      Action:
        - "dynamodb:*"
      Resource: 
        - "arn:aws:dynamodb:REGION:ACCOUNT_ID:table/UsersTable"

Con esto, permitimos todas las acciones de DynamoDB, pero limitadas a una tabla específica.

¿Qué estrategia podemos seguir para verificar y corregir errores?

Al detectar errores, CloudWatch en AWS es una herramienta esencial. Lambda inyecta automáticamente sus logs en CloudWatch, lo que nos permite revisar las causas de cualquiera de los errores que surjan.

Usar CloudWatch para depuración

Para verificar logs en CloudWatch:

  1. Navega a la consola de CloudWatch.
  2. Dirígete a Log Groups y selecciona el grupo de logs de la Lambda.
  3. Examina los logs para determinar la causa de cualquier error.

¿Cómo mejorar la lógica para obtener datos específicos?

Actualmente, obtenemos una lista de usuarios coincidiendo con un ID, aunque solo el ID es único. Propongo realizar una mejora para regresar únicamente la información del usuario en lugar de una lista.

Tarea práctica

Te invito a intentar refactorizar la lógica de nuestra aplicación para que regrese solo la información específica de un usuario. Esto ayudará a optimizar la consulta y asegurar que nuestra aplicación sea más precisa.

La mejora y personalización de nuestras aplicaciones no solo resuelven problemas inmediatos, sino que también preparan el terreno para un desarrollo más robusto a largo plazo. ¡Sigue experimentando y ajustando!

Aportes 10

Preguntas 3

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

una forma “dinámica” de lograr darle permisos a la lambda function es : Resource: !GetAtt usersTable.Arn siendo usersTable, el nombre del recurso en:

Resources:
    usersTable:
      Type: AWS::DynamoDB::Table
      Properties:

ya que sino primero tendríamos que deployar, verificar el ARN de la tabla y luego volver a deployar con el nombre correcto

En mi caso agregué un sencillo archivo JSON como seed a la Local DynamoDB (aquí la documantación) para trabajar todo en mi PC (por ahora). Mi configuración está acá:

Para poder hacer el reto que nos pide el profesor, solamente tenemos que modificar el return, quedando de la siguiente manera, y eliminando la metadata:

return {
        statusCode: 200,
        body: JSON.stringify(res.Items),
      };

Como quedaria completo el ejercicio:

Evita el hardcode del ARN de esta manera ```js iam: role: statements: - Effect: Allow Action: "dynamodb:*" Resource: { "Fn::GetAtt": ["usersTable", "Arn"] } ```

Para poder hacer el reto que nos pide el profesor, solamente tenemos que modificar el return, quedando de la siguiente manera, y eliminando la metadata: return { statusCode: 200, body: JSON.stringify(res.Items), };

Hola alguien me puede proporcionar documentación del tema de event para los diferentes tipos de parámetros cuando uno usa python
Tengo el siguiente error: CREATE\_FAILED: S3Bucket (AWS::S3::Bucket) Resource handler returned message: "Bucket cannot have ACLs set with ObjectOwnership's BucketOwnerEnforced setting (Service: S3, Status Code: 400, Request ID: HMMWWRY9TCJ371Q2, Extended Request ID: IJDSNJRtEwxhWp8+mePQb6aV9oH8FuGbUuWdZZAZvibhiP6pLp28DWxLsNnf7pQUtKs4qzpDc5TR1db2uo6SyDNLgEEOM+l59KrNF5n8msI=)" (RequestToken: 8bd3c680-fd8b-a0e1-a432-52f9de3b646c, HandlerErrorCode: GeneralServiceException)
Para los errores ```js 2024-08-07T18:47:09.255Z undefined ERROR Uncaught Exception { "errorType": "Runtime.ImportModuleError", "errorMessage": "Error: Cannot find module 'aws-sdk'\nRequire stack:\n- /var/task/handler.js\n- /var/runtime/index.mjs", "stack": [ "Runtime.ImportModuleError: Error: Cannot find module 'aws-sdk'", "Require stack:", "- /var/task/handler.js", "- /var/runtime/index.mjs", " at _loadUserApp (file:///var/runtime/index.mjs:1087:17)", " at async UserFunction.js.module.exports.load (file:///var/runtime/index.mjs:1119:21)", " at async start (file:///var/runtime/index.mjs:1282:23)", " at async file:///var/runtime/index.mjs:1288:1" ] } ```2024-08-07T18:47:09.255Z undefined **ERROR** Uncaught **Exception** { "errorType": "Runtime.ImportModuleError", "errorMessage": "**Error**: Cannot find module 'aws-sdk'\nRequire stack:\n- /var/task/handler.js\n- /var/runtime/index.mjs", "stack": \[ "Runtime.ImportModuleError: **Error**: Cannot find module 'aws-sdk'", "Require stack:", "- /var/task/handler.js", "- /var/runtime/index.mjs", " at \_loadUserApp (file:///var/runtime/index.mjs:1087:17)", " at async UserFunction.js.module.exports.load (file:///var/runtime/index.mjs:1119:21)", " at async start (file:///var/runtime/index.mjs:1282:23)", " at async file:///var/runtime/index.mjs:1288:1" ] } Se actualizo en el yml ```js provider: name: aws runtime: nodejs16.x # Actualiza esta línea a la versión soportada ```provider:  name: aws  runtime: nodejs16.x  # Actualiza esta línea a la versión soportada
Si les sale el error : **CREATE\_FAILED: CustomApiGatewayAccountCloudWatchRole** ![](https://static.platzi.com/media/user_upload/image-7d5bfca2-a160-4600-9ac2-4bda21f4419e.jpg) pareciese que anteriormente este recurso lo creaba serverless manualmente pero ya no. Solo deben ir a iam y crear el rol con el nombre: **serverlessApiGatewayCloudWatchRole** configurarlo de esta manera: ![](https://static.platzi.com/media/user_upload/image-a9302f60-234f-454e-a6cc-1e7ae279b8f3.jpg) y presionar crear. luego intente hacer el deploy nuevamente.
también podemos manejar el tema del despliegue en dev con alguna variable como is offline?