
Una de las ultimas tecnologías que se ha introducido a nuestra cartera de posibilidades es la metodología serverless, en mi opinión una de las mas convenientes, con un muy buen balance de costo y beneficio. Utilizando este se reduce mucho el tiempo de despliegue de una aplicación y dedicarle más tiempo a la programación de funciones que aporten valor.

En este articulo, te mostrarte como implementar un `CRUD` con el Framework de Serverless.

## ¿Que es Serverless?

¿Serverless? Si mi aplicación no corre sobre un servidor entonces ¿Donde corre? Es lo primero que podemos preguntarnos, pero en realidad la palabra se refiere a que esta metodología abstrae el proceso de configuración y mantenimiento de un servidor, sí adiós a configurar un servidor nginx para poder exponer tu aplicación.

También nos facilita la configuraciones de escaladas automáticas o balanceo de carga, por lo que nos deja mucho más tiempo disponible para dedicarnos al código.

Otra gran victoria, no menor, es el costo. Cuando ejecutas tu código en una maquina virtual o servidor local, este servicio tiene que tener alta disponibilidad y estar constantemente consumiendo recursos, en cambió, con serverless solo genera costos al momento de realizar una solicitud y la cantidad de tiempo que se ejecuta tu código. Esto implica una reducción de los costos significativa.

#### Pros

Los beneficios son:

- **Costo** - solo pagas por lo que usas.
- **Sencillez** - evita la necesidad de configurar infraestructura
- **Soportado en múltiples lenguajes de programación**
- **Utilizado por cualquier proveedor de cloud**
- **Varias alternativas para utilizar tus funciones (Endpoint de una api, colas de mensajes, ejecuciones programadas...)**

#### Cons

Los contras que debes tener en cuenta:

- **Manejar u Organizar el código puede ser complejo, efecto de caja negra en AWS**
- **El proceso de debug en local es un desafió**
- **La aplicación no tendrá acceso al sistema de archivos**
- **Cambiar tu proveedor de cloud puede significar cambiar el código**
- **Cold starts (segundos extra que demora en ejecutarse una función por primera vez)**
- **Tiempo de ejecución de una función (máximo 15 minutos)**

Puedes ver algunas otras limitaciones de AWS Lambda [aquí](https://docs.aws.amazon.com/lambda/latest/dg/limits.html).

Para manejar los archivos de la aplicación debes utilizar otro servicio de tu proveedor de cloud, en nuestro caso AWS, puedes ocupar un S3.

En mi ultima implementación de esta métodología pude comprobar que el _Cold Start_ para funciones escribas en JavaScript no llega a ser un problema, por otro lado si tu aplicación corre sobré JAVA la historia cambia, pero no queda todo allí como seguramente ya lo pensaste existen formas de mantener las funciones "tibias" y esperando a que llegue una petición esta ténica se llama [Lambda Warm Start](https://blog.octo.com/en/cold-start-warm-start-with-aws-lambda/).

## Serverless el Framework

Si, el Framework comparte su nombré con la métodología de desarrollo, este es una herramienta que nos permite desplegar una aplicación en Node.js fácilmente. Serverless es la navaja suiza Open Source en forma de CLI que nos facilita la integración con múltiples proveedores de cloud.

También cuenta con plugins que nos pueden facilitar la vía del desarrollo local, más adelante en este articulo utilizaras el plugin de _DynamoDB Local_.

Como si esto fuera poco también cuenta con una comunidad activa y buena documentación que te pueden ayudar a la hora de cualquier duda [Serverless.com](https://serverless.com/).

## Manos a la masa

Algunos de los problemas que puedes tener durante el desarrollo de este articulo:

- La version del Serverless Framework o algún plugin.
- Tener las credenciales de Amazon AWS correctamente configuradas. [_¿Como lo haces?_](https://serverless.com/framework/docs/providers/aws/guide/credentials/)

Habiendo dejado en claro eso podemos comenzar, instalando el CLI de Serverless:

```bash
npm i -g serverless
serverless login
```

Ahora prepararemos el directorio donde construiremos la aplicación:

```bash
mkdir serverless-api && cd $_
npm init -y
npm i --save aws-sdk body-parser express node-uuid serverless-http
```

Ahora dentro del este directorio que acabamos de crear debemos agregar el archivo `serverless.yml` y llenarlo con lo siguiente:

```yml
service: lambda-rest-api

custom:
  tableName: 'todos-${self:provider.stage}'

provider:
  name: aws
  runtime: nodejs8.10
  stage: dev
  region: us-east-1
  iamRoleStatements:
    - Effect: Allow
      Action:
        - dynamodb:Query
        - dynamodb:Scan
        - dynamodb:GetItem
        - dynamodb:PutItem
        - dynamodb:UpdateItem
        - dynamodb:DeleteItem
      Resource:
        - { 'Fn::GetAtt': ['TodosDynamoDBTable', 'Arn'] }
  environment:
    TODOS_TABLE: ${self:custom.tableName}

functions:
  todo-app:
    handler: index.handler
    events:
      - http: ANY /
      - http: 'ANY {proxy+}'

resources:
  Resources:
    TodosDynamoDBTable:
      Type: 'AWS::DynamoDB::Table'
      Properties:
        AttributeDefinitions:
          - AttributeName: todoId
            AttributeType: S
        KeySchema:
          - AttributeName: todoId
            KeyType: HASH
        ProvisionedThroughput:
          ReadCapacityUnits: 1
          WriteCapacityUnits: 1
        TableName: ${self:custom.tableName}
```

Hay algunas cosas que resaltar en este archivo: el campo `service` será el nombre de nuestra aplicación, dentro de `custom` vamos a recibir un parámetro que será el nombre de la tabla en DynamoDB, que luego se guarda en una variable llamada `TODOS_TABLE`. Luego podremos acceder al valor de esta variable por el `process.env` en el código.

El resto de este archivo configura los permisos, campos, esquemas... con los que vamos a trabajar en DynamoDB, ahora vamos a agregar algunos plugins que son necesarios para el desarrollo local o también llamado `offline`.

```bash
npm i --save serverless-dynamodb-local@0.2.30 serverless-offline
```

Ahora debes incluir en el archivo `serverless.yml` las siguientes lineas, justo debajo del campo `service`:

```yml
plugins:
  - serverless-dynamodb-local
  - serverless-offline
```

El orden es importante, primero debe de estar el `serverless-dynamodb-local` y luego el `serverless-offline`.

Hasta aquí ya tenemos configurado todo el entorno que necesita nuestra aplicación para ejecutarse, ahora podemos comenzar a trabajar en el código.

Creas el archivo `index.js` y lo llenas con lo siguiente:

```javascript
const serverless = require('serverless-http')
const bodyParser = require('body-parser')
const express = require('express')
const app = express()
const AWS = require('aws-sdk')
const uuid = require('node-uuid')

const { TODOS_TABLE, IS_OFFLINE } = process.env

const dynamoDb =
  IS_OFFLINE === 'true'
    ? new AWS.DynamoDB.DocumentClient({
        region: 'localhost',
        endpoint: 'http://localhost:8000',
      })
    : new AWS.DynamoDB.DocumentClient()

app.use(bodyParser.json({ strict: false }))

app.get('/todos', (req, res) => {
  const params = {
    TableName: TODOS_TABLE,
  }

  dynamoDb.scan(params, (error, result) => {
    if (error) {
      res.status(400).json({ error: 'Error retrieving Todos' })
    }

    const { Items: todos } = result

    res.json({ todos })
  })
})

module.exports.handler = serverless(app)
```

Si has tenido experiencia con alguna otra aplicación construida con `Express` el contenido de este archivo te será bastante familiar, así le estamos dando a nuestra aplicación un único endpoint para leer todas las notas guardados.

Ahora a ejecutar nuestra api:

```bash
sls offline start --migrate
```

Luego de que termine de iniciar la aplicación podrás acceder a la ruta http://localhost:3000/todos y deberías de tener como respuesta un objeto con un array de "notas" vació: `{"todos":[]}`.

---

En caso de ver un error similar a este:

```bash
Error: spawn java ENOENT
at exports._errnoException (util.js:1022:11)
at Process.ChildProcess._handle.onexit (internal/child_process.js:193:32)
at onErrorNT (internal/child_process.js:359:16)
at _combinedTickCallback (internal/process/next_tick.js:74:11)
at process._tickDomainCallback (internal/process/next_tick.js:122:9)
```

Debes ejecutar el siguiente comando:

```bash
sls dynamodb install
```

---

Para agregar algunas notas necesitamos agregar un endpoint que lo permita, agrega este bloque de código a tu archivo `index.js` justo encima del `module.exports`:

```javascript
app.post('/todos', (req, res) => {
  const { title, done = false } = req.body

  const todoId = uuid.v4()

  const params = {
    TableName: TODOS_TABLE,
    Item: {
      todoId,
      title,
      done,
    },
  }

  dynamoDb.put(params, error => {
    if (error) {
      console.log('Error creating Todo: ', error)
      res.status(400).json({ error: 'Could not create Todo' })
    }

    res.json({ todoId, title, done })
  })
})
```

Luego de detener y volver a ejecutar la api podremos probarla con `CURL`:

```bash
curl -H "Content-Type: application/json" -X POST http://localhost:3000/todos -d '{"title": "Finish bug tickets"}'
```

Esto debe de devolvernos el objeto creado en la base de datos, por ejemplo:

```bash
{"todoId":"5c30e169-26e3-44de-9564-d23a403ddf1b","title":"Finish bug tickets","done":false}
```

Si la respuesta es como esta y no tienes ningún error, acabas de crear una nota en tu aplicación, si vas al endpoint podrás ver las notas creadas http://localhost:3000/todos.

Continuando con la API, agregamos un endpoint que nos permita ver solo una nota especificada por el ID.

```javascript
app.get('/todos/:todoId', (req, res) => {
  const { todoId } = req.params

  const params = {
    TableName: TODOS_TABLE,
    Key: {
      todoId,
    },
  }

  dynamoDb.get(params, (error, result) => {
    if (error) {
      res.status(400).json({ error: 'Error retrieving Todo' })
    }

    if (result.Item) {
      const { todoId, title, done } = result.Item
      res.json({ todoId, title, done })
    } else {
      res.status(404).json({ error: `Todo with id: ${todoId} not found` })
    }
  })
})
```

Una ves agregado este endpoint puedes probarlo con el id de alguna nota creado con anterioridad (`http://localhost:3000/todos/5c30e169-26e3-44de-9564-d23a403ddf1b`), la respuesta debe de ser solo la nota a la que corresponde el ID

```bash
{"todoId":"5c30e169-26e3-44de-9564-d23a403ddf1b","title":"Finish bug tickets","done":false}
```

Agregamos el método `PUT` de nuestra API:

```javascript
app.put('/todos', (req, res) => {
  const { todoId, title, done } = req.body

  var params = {
    TableName: TODOS_TABLE,
    Key: { todoId },
    UpdateExpression: 'set #a = :title, #b = :done',
    ExpressionAttributeNames: { '#a': 'title', '#b': 'done' },
    ExpressionAttributeValues: { ':title': title, ':done': done },
  }

  dynamoDb.update(params, error => {
    if (error) {
      console.log(`Error updating Todo with id ${todoId}: `, error)
      res.status(400).json({ error: 'Could not update Todo' })
    }

    res.json({ todoId, title, done })
  })
})
```

Lo puedes probar cambiando el campo `done` de una nota de `false` a `true` para indicar que esta lista

```bash
curl -H "Content-Type: application/json" -X PUT http://localhost:3000/todos -d '{"todoId": "5c30e169-26e3-44de-9564-d23a403ddf1b", "title": "Finish bug tickets", "done": done}'
```

Y por ultimo el método `DELETE` para nuestra api de notas

```javascript
app.delete('/todos/:todoId', (req, res) => {
  const { todoId } = req.params

  const params = {
    TableName: TODOS_TABLE,
    Key: {
      todoId,
    },
  }

  dynamoDb.delete(params, error => {
    if (error) {
      console.log(`Error updating Todo with id ${todoId}`, error)
      res.status(400).json({ error: 'Could not delete Todo' })
    }

    res.json({ success: true })
  })
})
```

Para probarlo

```bash
curl -H "Content-Type: application/json" -X DELETE http://localhost:3000/todos/5c30e169-26e3-44de-9564-d23a403ddf1b
```

Debe de eliminar la nota a la cual corresponde el ID seleccionado.

Con esto tendremos la API REST lista y funcionando en local, ahora es donde el Framework Serverless hace su magia.

Solo ejecuta `sls deploy` se tomará unos minutos y al final tendrás desplegada tu API en AWS y en caso de que todo sea un éxito podrás ver un mensaje como el siguiente:

```bash
Serverless: WARNING: Missing "tenant" and "app" properties in serverless.yml. Without these properties, you can not publish the service to the Serverless Platform.
Serverless: Packaging service...
Serverless: Excluding development dependencies...
Serverless: Creating Stack...
Serverless: Checking Stack create progress...
.....
Serverless: Stack create finished...
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading artifacts...
Serverless: Uploading service .zip file to S3 (26.16 MB)...
Serverless: Validating template...
Serverless: Updating Stack...
Serverless: Checking Stack update progress...
....................................
Serverless: Stack update finished...
Service Information
service: lambda-rest-api
stage: dev
region: us-east-1
stack: lambda-rest-api-dev
api keys:
  None
endpoints:
  ANY - https://gqrbje0go5.execute-api.us-east-1.amazonaws.com/dev
  ANY - https://gqrbje0go5.execute-api.us-east-1.amazonaws.com/dev/{proxy+}
functions:
  todo-app: lambda-rest-api-dev-todo-app
layers:
  None
```

Ahora puedes probar los mismos comandos `CURD` con este nuevo endpoint que generá AWS y validar que tu API este funcionando correctamente.

### Extras

- Puedes usar este comando para ver algunos logs `serverless logs -f todo-app -t`
- Para borrar todos los servicios que levanto esta aplicación al desplegarse en AWS `serverless remove`. _**Cuidado** no solicita confirmación_.
- Agregar a la sección de `scripts` en el archivo `package.json` la linea `"develop": "sls offline start --migrate"`.

Pueden ver el código relacionado a este articulo como guía en [GitHub](https://github.com/enBonnet/api-express-serverless).

### Creditos

Este articulo fue publicado originalmente por [Matthew Brown](https://keyholesoftware.com/author/mbrown/) en [keyholesoftware.com](https://keyholesoftware.com/2018/11/05/building-a-node-js-service-with-aws-lambda-dynamodb-and-serverless-framework/).

Me tomé la libertad de traducirlo y compartirlo, agregando algunos comentarios según mi experiencia con la finalidad de compartir conocimientos.


Una forma sencilla de construir una API Node.js utilizando el framework de Serverless y Express

acoustic-amplifier-artist-audio-114820.jpg

Construir API Node.js Serverless con AWS Lambda y DyanmoDB

Cuando tu aplicación comienza a crecer o tenemos varias aplicaciones funcionando en paralelo te puedes ver en la necesidad de compartir lógica o ciertas funciones entre ellas, en el caso de Nodejs cuando creas un paquete sin Typescript y lo quieres usar en un proyecto con este, deberías instalar los types de forma independiente o agregarle un mítico `// @ts-ignore` y nadie quiere eso **guiño guiño**.
 
La idea de este artículo es poder dejar las bases para poder crear un paquete con Typescript que genere los types que necesita el mismo de forma automática. De esta forma lo puedes usar en tus proyectos con Typescript o Javascript plano.
 
El resultado de esta guía la puedes encontrar en este [repositorio](https://github.com/enbonnet/ts-package).
 
### Armando las bases
 
```sh
mkdir ts-package
cd ts-packages
npm init -y
```
 
Ahora ya tienes el `package.json`, debes agregar las siguientes dependencias:
 
```sh
npm install @types/node --save-dev
npm install typescript ts-node --save-dev
```
 
`@types/nodes` agrega los types a node para poder trabajar con Typescript, agregamos `typescript` y `ts-node` para poder transpilar el código TS a JS, en este ejemplo será con el módulo `commonjs`.
 
Creas el archivo `tsconfig.json` en la raíz del proyecto y le agregas los siguiente:
 
```js
{
   "compilerOptions": {
       "lib": [ "es5", "es6", "es7",
                "es2015", "es2016",
                "es2017", "es2018",
                "esnext" ],
       "target": "es2017",
       "module": "commonjs",
       "moduleResolution": "Node",
       "outDir": "./dist",
       "rootDir": "./lib",
       "declaration": true,
       "declarationMap": true,
       "inlineSourceMap": true,
       "inlineSources": true
   }
}
```
 
Este archivo especifica con qué características esperamos que se transpile el código TS a JS:
 
- `target` para transpilar a ES2017, porque ya soporta async/await.
- `module` describe el tipo de módulo en este caso será `CommonJS`.
- `moduleResolution` para indicarle que busque los paquetes en el `node_modules`.
- `outDir` el directorio donde quedará el código transpilado.
- `rootDir` el directorio donde está el código en Typescript.
- `declaration` y `declarationMap` para generar los types y el map de declaración.
- `inlineSourceMap` y `inlineSources` genera el mapa de los archivos fuente.
 
### Scripts en `package.json`
 
En el `package.json` debes tener las siguientes propiedades:
 
```js
{
   ...
   "main": "dist/index.js",
   "type": "commonjs",
   "types": "./dist/index.d.ts",
   "scripts": {
       "build": "tsc",
       "watch": "tsc --watch",
       "test": "cd test && npm run test"
   },
   ...
}
```
 
Crear los directorio `lib` y `dist` en el directorio raíz:
 
```sh
mkdir lib
mkdir dist
```
 
¡Y listo!
 
Ahora solo te falta escribir dentro del directorio `lib` tu código fuente, un archivo `index.ts` en donde ocurra toda la magia que quieres hacer.
 
Al ejecutar `npm run build` podrás ver tanspilado el código de TS a JS en el directorio `dist`.
 
Si quieres tener más integraciones puedes mirar en el repositorio que usamos de template en [eclass.com](https://eclass.com), te lo dejo [aquí](https://github.com/eclass/ts-template-npm-libs) si quieres echarle un ojo o usarlo como template.


Siempre llegaras al punto en que necesitas compartir lógica de tu aplicación y aquí te quiero mostrar como hacerlo con un paquete de Nodejs con Typescript

grayscale-photo-of-wet-leaf-1425529.jpg

Como crear un modulo de Nodejs con Typscript

Siempre le estaré agradecido a [@xabadu](https://twitter.com/xabadu) quien me enseño a utilizar y configurar estas herramientas en mis proyectos, desde ese momento los necesito casi en cualquier proyecto, como lo dije en un tweet, "Me ayudan a proteger el código de mí mismo", en esos días de flojera cuando piensas "total si así funciona...", quieres subirlo pero el linter te advierte que eso será un problema para tú yo del futuro y si estás trabajando en equipo ya no son opcionales, son obligatorios. Todos escribimos código de forma diferente y si no tienes un estándar mínimo de lo que se espera de tu código llegara el momento en que será imposible de leer sin dedicarle más tiempo del que queremos.
 
Para el caso de Typescript tienes dos opciones [TSLint](https://palantir.github.io/tslint/) y [ESLint](https://eslint.org/), el primero funciona solo con Typescript, el segundo es compatible con Typescript y Javascript, lo que te da la flexibilidad de usarlo en proyectos de migración en caso de que estes pasando de JS a TS, funciona perfecto. Adicional a esto el equipo de Typescript reconoce que [ESLint tiene mejor rendimiento](https://github.com/Microsoft/TypeScript/issues/29288#developer-productivity-tools-and-integration) que TSLint.
 
### Configurando ESLint
 
Instalar las dependencias
 
```bash
yarn add -D eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin
```
 
- `eslint` el core de la librería.
- `@typescript-eslint/parser` el parser que permite a ESLint interpretar código Typescript.
- `@typescript-eslint/eslint-plugin` un plugins de reglas recomendadas para Typescript.
 
Ahora creamos el archivo `.eslintrc` en la raíz del proyecto y le agregas el siguiente contenido:
 
```js
{
 "parser": "@typescript-eslint/parser",
 "extends": [
   "plugin:@typescript-eslint/recommended"
 ],
 "parserOptions": {
   "ecmaVersion": 2018,
   "sourceType": "module"
 },
 "rules": {
   // Aca puedes modificar alguna regla específica, por ejemplo:
   // "@typescript-eslint/explicit-function-return-type": "off",
 }
}
```
 
> Es opcional agregar un archivo `.eslintignore` con la carpeta donde se guardará tu código transpilado de TS a JS.
 
### Configurando Prettier
 
Necesitas instalar las dependencias que ayudan a la comunicación entre las reglas de ESLint con el formato del código que vas a definir en Prettier.
 
```bash
yarn add -D prettier eslint-config-prettier eslint-plugin-prettier
```
 
- `prettier` la librería.
- `eslint-config-prettier` desactiva las reglas de ESLint que generan conflicto.
- `eslint-plugin-prettier` ejecuta prettier como una regla de ESLint.
 
Crear el archivo de configuración para prettier `.prettierrc` en la raíz del proyecto, con el siguiente contenido:
 
```js
{
 "semi": false, // punto y coma al final de cada declaración
 "tabWidth": 2, // tamaño de los tabs
 "printWidth": 100, // largo máximo de una línea de código
 "singleQuote": true,  // comillas simples
 "trailingComma": "none" // comas en objetos o arrays multi líneas
}
 
```
 
Puedes ver más opciones en la [documentación](https://prettier.io/docs/en/options.html)
 
### Integrando ESLint con Prettier
 
Actualizando la configuración de eslint en el archivo `.eslintrc`
 
```js
{
 "parser": "@typescript-eslint/parser",
 "extends": [
   "plugin:@typescript-eslint/recommended",
   "prettier/@typescript-eslint",  // agrega las reglas de prettier a eslint
   "plugin:prettier/recommended" // agregar el plugin que integra eslint con prettier
 ],
 "parserOptions": {
   "ecmaVersion": 2018,
   "sourceType": "module"
 },
 "rules": {
   // Aca puedes modificar alguna regla específica, por ejemplo:
   // "@typescript-eslint/explicit-function-return-type": "off",
 }
}
```
 
### Ejecutar ESLint con el CLI
 
Para ejecutar el Linter sobre todo el código debes agregar el `script` que ejecuta tu código:
 
```js
{
 "scripts": {
  ...
   "lint": "tsc --noEmit && eslint '*/**/*.{js,ts}' --quiet --fix"
  ...
 }
}
```
 
Este comando transpila el código de TS a JS en caso de que no de errores entonces ejecuta el linter sobre todos los archivos .js o .ts. De esa forma tienes dos validaciones.
 
### Para un proyecto de Reactjs
 
Para poder usar esta configuración con un proyecto de Reactjs necesitas agregar un par de dependencias y configuraciones, primero instalar el plugin de ESLint para interpretar código JSX, TSX:
 
```bash
yarn add -D eslint-plugin-react
```
 
Luego actualizar el archivo de `.eslintrc`:
 
```js
{
 "parser": "@typescript-eslint/parser",
 "extends": [
   "plugin:react/recommended", // agregar el plugin de reactjs para eslint
   "plugin:@typescript-eslint/recommended",
   "prettier/@typescript-eslint",
   "plugin:prettier/recommended"
 ],
 "parserOptions": {
   "ecmaVersion": 2018,
   "sourceType": "module",
   "ecmaFeatures": {
     "jsx": true // permite a eslint analizar los archivos jsx o tsx
   }
 },
 "rules": {
   // Aca puedes modificar alguna regla específica, por ejemplo:
   // "@typescript-eslint/explicit-function-return-type": "off",
 },
 "settings": {
   "react": {
     "version": "detect" // para detectar la versión de reactjs
   }
 }
};
```
 
¡Listo! De esa forma podras utilizar ESLint y prettier integrados en Reactjs.
 
Puedes ver un ejemplo de esta configuración en el proyecto base de una [API apollo con Postgres](https://github.com/enBonnet/apollo-postgres) que es un template que puedes usar para alguno de tus proyectos.


Configurar ESLint en tu proyecto de Nodejs o React con Typescript.

basketball-black-and-white-court-dark-350771.jpg

Usar ESLint y Prettier en proyectos TypeScript

Esta es la segunda guía para construir una API Serverless con AWS, la primera la puedes encontrar [acá](https://enbonnet.me/article/2/construir-api-nodejs-serverless-con-aws-lambda-y-dyanmodb) la diferencía son las bases de datos, si quieres saber un poco más sobre que opino al respecto de Serverless pros y contras en ese árticulo explico un poco más, en este vamos a ir directo a donde las papas queman.

## Objetivo

Terminar la guía con una API desplegada de AWS y conectada con Aurora Serverless SQL.

## Resultado

Puedes encontrar el resultado de esta guía [aquí](https://github.com/enBonnet/serverless-mysql)

## Requisitos previos

- Tener nodejs 10 o superior
- Cuenta en AWS
- CLI Tool de Serverless

## Primeros pasos

### La base

Con las herramientas que nos ofrece el [CLI de Serverless](https://serverless.com/framework/docs/getting-started/) podemos iniciar el proyecto muy rápidamente usando el comando:

```bash
sls create -t aws-nodejs -p note-api && cd note-api
```

En un par de minutos ya tendrás la base del proyecto lista para comenzar.

### Las dependencias

Serverless tiene un gran sistema de plugins que podemos utilizar, uno de las más utilizadas es `serverless-offline` que vamos a instalar en conjunto con los módulos que necesitamos para conectarnos con la base de datos, para ello ejecutamos los siguientes comandos en la raíz del proyecto:

```bash
npm init -y 
npm i --save-dev serverless-offline 
npm i --save mysql2 sequelize
```

## Comenzamos a escribir código

En la base de nuestro proyecto `/note-api` tendrás un archivo `serverless.yml` con configuraciones previas por defecto, ese archivo lo vamos a sustituir complementa con el siguiente contenido:

### serverless.yml

```yml
service: note-api

custom:
  secrets: ${file(secrets.json)}

provider:
  name: aws
  runtime: nodejs12.x
  timeout: 30
  stage: ${self:custom.secrets.NODE_ENV}
  environment: 
    NODE_ENV: ${self:custom.secrets.NODE_ENV}
    DB_NAME: ${self:custom.secrets.DB_NAME}
    DB_USER: ${self:custom.secrets.DB_USER}
    DB_PASSWORD: ${self:custom.secrets.DB_PASSWORD}
    DB_HOST: ${self:custom.secrets.DB_HOST}
    DB_PORT: ${self:custom.secrets.DB_PORT}
  vpc:
    securityGroupIds:
      - ${self:custom.secrets.SECURITY_GROUP_ID}
    subnetIds:
      - ${self:custom.secrets.SUBNET1_ID}
      - ${self:custom.secrets.SUBNET2_ID}
      - ${self:custom.secrets.SUBNET3_ID}
      - ${self:custom.secrets.SUBNET4_ID}
      - ${self:custom.secrets.SUBNET5_ID}
      - ${self:custom.secrets.SUBNET6_ID} 

functions:
  healthCheck:
    handler: handler.healthCheck
    events:
      - http:
          path: /
          method: get
          cors: true
  create:
    handler: handler.create
    events:
      - http:
          path: notes
          method: post
          cors: true
  getOne:
    handler: handler.getOne
    events:
      - http:
          path: notes/{id}
          method: get
          cors: true
  getAll:
    handler: handler.getAll
    events:
     - http:
         path: notes
         method: get
         cors: true
  update:
    handler: handler.update
    events:
     - http:
         path: notes/{id}
         method: put
         cors: true
  destroy:
    handler: handler.destroy
    events:
     - http:
         path: notes/{id}
         method: delete
         cors: true

plugins:
  - serverless-offline
```

En este archivo estan pasando varias cosas, primero declaramos el nombre del servicio o de la app que contendrá las funciones lambda, luego cargamos un archivo de configuración `secrets: ${file(secrets.json)}` personalizado que nos ayudará más adelante para definir variables de entorno, en el `provider.environment` definimos las variables de entorno para el proyecto, en `functions` todas las funciones y los endpoints de las mismas, al final pero no menos importante `plugins` donde cargamos los plugins que vamos a utilizar en este proyecto.

### secrets.json

En la raíz del proyecto al lado de nuestro archivo `serverless.yml` crearemos un nuevo archivo llamado `secrests.json` que deberá verse así:

```json
{
  "DB_NAME": "test",
  "DB_USER": "root",
  "DB_PASSWORD": "root",
  "DB_HOST": "127.0.0.1",
  "DB_PORT": 3306,
  "NODE_ENV": "dev",
  "SECURITY_GROUP_ID": "sg-xx",
  "SUBNET1_ID": "subnet-xx",
  "SUBNET2_ID": "subnet-xx",
  "SUBNET3_ID": "subnet-xx",
  "SUBNET4_ID": "subnet-xx",
  "SUBNET5_ID": "subnet-xx",
  "SUBNET6_ID": "subnet-xx"
}
```

En este archivo vamos a sustituir las variables cuando creemos la base de datos en la consola de AWS, recuerda agregarlo a tu archivo `.gitignore

### Las funciones

En nuestro archivo `serverless.yml` ya definimos las funciones, nombres y el endpoint correspondiente e indicamos que esas funciones estarían en el archivo `handlers.js` pero en este momento aún no están, para agregarlas debemos sustituir el código por defecto que tiene este archivo por este:

```js
module.exports.healthCheck = async () => {
  await connectToDatabase()
  console.log('Connection successful.')
  return {
    statusCode: 200,
    body: JSON.stringify({ message: 'Connection successful.' })
  }
}

module.exports.create = async (event) => {
  try {
    const { Note } = await connectToDatabase()
    const note = await Note.create(JSON.parse(event.body))
    return {
      statusCode: 200,
      body: JSON.stringify(note)
    }
  } catch (err) {
    return {
      statusCode: err.statusCode || 500,
      headers: { 'Content-Type': 'text/plain' },
      body: 'Could not create the note.'
    }
  }
}

module.exports.getOne = async (event) => {
  try {
    const { Note } = await connectToDatabase()
    const note = await Note.findByPk(event.pathParameters.id)
    if (!note) throw new HTTPError(404, `Note with id: ${event.pathParameters.id} was not found`)
    return {
      statusCode: 200,
      body: JSON.stringify(note)
    }
  } catch (err) {
    return {
      statusCode: err.statusCode || 500,
      headers: { 'Content-Type': 'text/plain' },
      body: err.message || 'Could not fetch the Note.'
    }
  }
}

module.exports.getAll = async () => {
  try {
    const { Note } = await connectToDatabase()
    const notes = await Note.findAll()
    return {
      statusCode: 200,
      body: JSON.stringify(notes)
    }
  } catch (err) {
    return {
      statusCode: err.statusCode || 500,
      headers: { 'Content-Type': 'text/plain' },
      body: 'Could not fetch the notes.'
    }
  }
}

module.exports.update = async (event) => {
  try {
    const input = JSON.parse(event.body)
    const { Note } = await connectToDatabase()
    const note = await Note.findByPk(event.pathParameters.id)
    if (!note) throw new HTTPError(404, `Note with id: ${event.pathParameters.id} was not found`)
    if (input.title) note.title = input.title
    if (input.description) note.description = input.description
    await note.save()
    return {
      statusCode: 200,
      body: JSON.stringify(note)
    }
  } catch (err) {
    return {
      statusCode: err.statusCode || 500,
      headers: { 'Content-Type': 'text/plain' },
      body: err.message || 'Could not update the Note.'
    }
  }
}

module.exports.destroy = async (event) => {
  try {
    const { Note } = await connectToDatabase()
    const note = await Note.findByPk(event.pathParameters.id)
    if (!note) throw new HTTPError(404, `Note with id: ${event.pathParameters.id} was not found`)
    await note.destroy()
    return {
      statusCode: 200,
      body: JSON.stringify(note)
    }
  } catch (err) {
    return {
      statusCode: err.statusCode || 500,
      headers: { 'Content-Type': 'text/plain' },
      body: err.message || 'Could destroy fetch the Note.'
    }
  }
}
```

Con esto tendremos definidas las funciones, puede parecer confuso todo lo que está pasando en este gran trozo de código pero básicamente es un controlador que trabajar en conjunto con nuestro Modelo de Note (o notas), para crear un CRUD.

### Conexión a la base de datos

Ahora que ya tenemos los endpoint en el `serverless.yml` y el controlador en el `handler.js` nos hace falta la conexión con la base de datos y el modelo, para esto vamos a crear un archivo `db.js` en la raíz del proyecto que tenga el siguiente contenido:

```js
const Sequelize = require('sequelize')
const NoteModel = require('./models/Note')

const sequelize = new Sequelize(
  process.env.DB_NAME,
  process.env.DB_USER,
  process.env.DB_PASSWORD,
  {
    dialect: 'mysql',
    host: process.env.DB_HOST,
    port: process.env.DB_PORT
  }
)

const Note = NoteModel(sequelize, Sequelize)
const Models = { Note }
const connection = {}

module.exports = async () => {
  if (connection.isConnected) {
    console.log('=> Using existing connection.')
    return Models
  }

  await sequelize.sync()
  await sequelize.authenticate()
  connection.isConnected = true
  console.log('=> Created a new connection.')
  return Models
}
```

Lo más importante de este archivo es cómo se administran las conexiones a la base de datos, si no existe alguna conexión se crear y en caso de que aún esté viva una conexión de reutiliza.
 
### Modelo de datos
 
Para nuestro modelo creamos una carpeta llamada `models` y dentro un archivo `Note.js` este archivo lo llenamos con el siguiente código:

```js
module.exports = (sequelize, type) => {
  return sequelize.define('note', {
    id: {
      type: type.INTEGER,
      primaryKey: true,
      autoIncrement: true
    },
    title: type.STRING,
    description: type.STRING
  })
}
``` 

En este modelo estamos definiendo la table note y los campos que tendrá esta tabla en la base de datos, gracias a `sequelize` es bastante sencillo.

### Volvemos al `handler.js`

Ahora agregamos al comienzo del `handler.js` la función para iniciar la conexión con la base de datos y una función para manejar los errores de HTTP de forma sencilla

```js
const connectToDatabase = require('./db')

function HTTPError (statusCode, message) {
  const error = new Error(message)
  error.statusCode = statusCode
  return error
}
```

¿Ya y estamos listos para probar? Aun no, nos falta un gran detalle, para poder probar nuestra aplicación offline tenemos que tener una base de datos local, recuerdas el archivo `secrets.json` si ya tienes instalado mysql en tu computador puedes sustituir allí las variables de tu base de datos por otro lado si no te gusta tener bases de datos instaladas en tu sistema siempre te puedes ayudar con el amigo docker, para eso te dejo este otro articulo: [No instales Mysql o Mariadb, utiliza docker](https://enbonnet.me/article/50/no-instales-mysql-o-mariadb-utiliza-docker).

## Pruebas

Una vez que tengas las variables de tu base de datos local o en docker agregadas en el archivo `secrets.json` ya puedes ejecutar la aplicación, con el comando:

```bash
sls offline start --skipCacheInvalidation
```

La propiedad `--skipCacheInvalidation` nos ayuda a que se recarguen los módulos más rápidamente. Se lo podemos sacar en caso de tengamos algún error.
 
Si todo está correcto como debería ya podemos probar con nuestro Cliente de API favorita, [Postman](https://www.postman.com/), [Insomnia](https://insomnia.rest/)...

```bash
# Las rutas que tenemos definidas son:
GET - http://localhost:3000/                           # Raíz - healthCheck
POST - http://localhost:3000/notes               # Crear una nota - create
GET - http://localhost:3000/notes/{id}          # Leer una nota - getOne
GET - http://localhost:3000/notes                  # Leer todas la snotas - getAll
PUT - http://localhost:3000/notes/{id}           # Actualizar una nota - update
DELETE - http://localhost:3000/notes/{id}    # Borrar una nota - destroy
```

Si revisamos la terminal podrás ver cuando se crear una nueva conexión a la base de datos `using new database connection` o cuando se utiliza `using existing database connection`. Hasta este punto todo funciona en local pero el objetivo de esta guía es terminar con una API desplegada en AWS y conectada con Aurora Serverless SQL.
 
# Crear la base de datos Aurora Serverless
 
Accedemos a la [consola de AWS](https://console.aws.amazon.com/) buscamos el servicio `RDS` y `Create database`las opciones van casi por defecto, las elegimos en el siguiente orden:

### Choose a database creation method
- Standard Create

### Engine options
- Amazon Aurora 
- Amazon Aurora with MySQL compatibilit
- Versión (la última disponible)
- Regional

### Database features
- Serverless

### Templates
- Dev/Test

### Settings
- DB cluster identifier: El nombre de nuestro cluster o servidor de bases de datos.
- Credentials Settings: username y password de tu preferencia pero recuerda que las necesitarás más adelante.

### DB instance size
-  Memory Optimized classes
- db.r5.large

### Availability & durability
- Create an Aurora Replica/Reader node in a different AZ (recommended for scaled availability).

### Connectivity
- Virtual Private Cloud (VPC): Por defecto creará una nueva.

### Database authentication
- Password authentication

### Additional configuration
- Initial database name: *importantes* necesitamos agregar el nombre a tu base de datos ya que `sequelize` no es capaz de crear la base de datos.

... los campos no mencionados quedan con el valor por defecto.

Luego confirmamos que queremos crear la base de datos en `Create database` y esto comienza el proceso que demora un par de minutos (15 ~ 20) luego de que esté creada nuestra base de datos en AWS, tendremos los valores que necesitamos sustituir en el archivo `secrets.json`.
 
## Deploy
Una vez sustituido las variables en el archivo `secrets.json` podemos hacer el deploy de nuestra api, con el comando:
 
```bash
sls deploy
````
 
Luego de un par de minutos tendremos una url en la que podemos probar como funciona nuestra aplicación desplegada sustituyendo.

Recuerda que puedes ver el resultado de esta guía implementado [aquí](https://github.com/enBonnet/serverless-mysql)
 
### Comandos útiles
 
- `sls config` nos ayuda a validar la configuración del archivo `serverless.yml`.
- `sls print` nos imprime el archivo `serverless.yml` tal y como lo vería el intérprete.
- `sls remove` si quieres eliminar todos los servicios creados por tu aplicación en AWS.

Gracias por llegar hasta acá, recuerda si tienes algún comentario o duda me lo puedes hacer llegar por twitter: [@enBonnet](https://twitter.com/enbonnet) o directamente por telegram [@enBonnet](https://t.me/enbonnet).


Crear una api REST con nodejs sobre AWS Lambda y Aurora Serverless SQL

Posts

Construir API Node.js Serverless con AWS Lambda y DyanmoDB

Como crear un modulo de Nodejs con Typscript

Usar ESLint y Prettier en proyectos TypeScript

Construir API Rest Nodejs Serverless con AWS Lambda y Aurora Serverless