API Privada con Serverless Framework, AWS y VPCs.

Api Gateway Private Endpoint

Generalmente cuando hablamos de APIs pensamos en la forma como otros desarrolladores se pueden conectar a nuestros sistemas, productos, o servicios. Sin embargo, cuando empiezas a desacoplar tus sistemas te das cuenta que el utilizar APIs para el desarrollo interno puede ser igual o más útil para el negocio.

Este ejemplo sencillo muestra como poder crear un API privada usando Serverless Framework y Amazon Web Services. Ojo, pestaña, y ceja, lo que estoy haciendo con este ejemplo no es hacer privada un API a través de autentificación y autorización, eso siempre se puede agregar sobre el API como una capa de seguridad aún mayor, en este caso estamos haciendo privada la conexión para que solo pueda ser accedida desde nuestra VPC a través de un AWS PrivateLink.

Ya han pasado un poco más de dos años desde que AWS lanzó esta  funcionalidad, sin embargo no había tenido la oportunidad y necesidad de utilizarla anteriormente. Pueden leer el Post original de AWS acá : https://aws.amazon.com/blogs/compute/introducing-amazon-api-gateway-private-endpoints/

El código de este ejemplo puede ser encontrado en GitHub : https://github.com/ctala/serverless-private-api-endpoint

Requerimientos

  1. Cuenta en AWS.
  2. Serverless Framework Instalado
  3. AWS CLI Instalado. Esto nos permitirá hacer el deployment de la aplicación de manera directa.
  4. Tener una Red Privada con la cual queramos acceder al servicio (VPC)
  5. Tener una máquina a la que podamos acceder para poder probar el servicio.

Creando el VPC Endpoint

Para generar el endpoint a utilizar, nos dirigimos al menú de VPCs de la consola de AWS, seleccionamos el sub-menú de endpoints en el costado izquierdo, y luego crear uno nuevo. Nos debería aparecer algo como lo que se muestra a continuación.

VPC Endpoint
VPC Endpoint

Si en busqueda escribimos execute-api, nos debería aparecer por defecto la opción que necesitamos para que este endpoint pueda ejecutar la API que crearemos. A continuación seleccionamos el VPC, las subnets, y las security groups correspondientes y damos click en continuar.

El Id de Endpoint resultante lo usaremos en nuestra configuración del Serverless.

Resource Policy

Antes de configurar el serverless, debemos definir quién puede y/o no puede tener acceso a nuestra red privada. En este caso, copiaremos el resource policy de ejemplo de AWS que hace Whitelist de la VPC que puede ejecutarlo (Se puede encontrar bajo Resources Policies en el menú de cualquier API bajo API Gateway.). La idea es que generemos este mismo Resource Policy usando la configuración del Serverless Framework.

Código del Serverless

El siguiente código es el que genera el Resource Policy mostrado anteriormente y levanta un Lamda con su API Gateway respectivo con un endpoint privado, además del endpoint por defecto del Serverless Framework con Hello World.

service: sls-test-private-endpoint
frameworkVersion: '2'

provider:
name: aws
runtime: nodejs12.x
region: us-west-2
stage: dev
endpointType: PRIVATE
vpcEndpointIds:
- vpce-0631ee46a323b75e4

#El Resource Policy que generamos primero bloqueará todo el tráfico que no sea de la/las VPCs listadas a bajo aws:sourceVpc, luego permitimos
# el acceso de todo lo demás.
resourcePolicy:
##Bloqueo de lo que no corresponde al VPC
- Effect: Deny
Principal: "*"
Action: execute-api:Invoke
Resource:
- execute-api:/*/*/*
Condition:
StringNotEquals:
aws:sourceVpc:
- vpc-03602a6783bdefb87
##Permiso a lo demás. Acá también podemos bloquiar por segmento de IP.
- Effect: Allow
Principal: "*"
Action: execute-api:Invoke
Resource:
- execute-api:/*/*/*

functions:
hello:
handler: handler.hello
events:
- http:
path: /
method: get

 

Probando la conexión.

 

Acá queremos hacer dos cosas, la primera es revisar que no podamos acceder a la URL desde nuestros computadores. Ya que el endpoint es un GET simplemente probamos utilizando la URL resultante del deployment, por ejemplo : https://80nyvq2u70.execute-api.us-west-2.amazonaws.com/dev/ . Si bien la URL mostrada es la original, no puede ser accedida debido a que está dentro de una API privada.

Para probar realmente que podemos acceder a esta API desde la VPC, lo que tenemos que hacer es llamarla desde una máquina que esté en esta. En este caso un simple comando Curl nos puede ayudar desde la consola de la máquina virtual.

curl -v https://80nyvq2u70.execute-api.us-west-2.amazonaws.com/dev/

En este caso, si todo salió según lo esperado, obtendremos la respuesta del serverless incluyendo todos los headers agregados desde AWS.

curl -v https://80nyvq2u70.execute-api.us-west-2.amazonaws.com/dev/
* Trying 10.0.16.153:443...
* TCP_NODELAY set
* Connected to 80nyvq2u70.execute-api.us-west-2.amazonaws.com (10.0.16.153) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: CN=*.execute-api.us-west-2.amazonaws.com
* start date: Apr 29 00:00:00 2020 GMT
* expire date: Apr 13 12:00:00 2021 GMT
* subjectAltName: host "80nyvq2u70.execute-api.us-west-2.amazonaws.com" matched cert's "*.execute-api.us-west-2.amazonaws.com"
* issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
* SSL certificate verify ok.
> GET /dev/ HTTP/1.1
> Host: 80nyvq2u70.execute-api.us-west-2.amazonaws.com
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: Server
< Date: Wed, 23 Sep 2020 23:13:15 GMT
< Content-Type: application/json
< Content-Length: 2402
< Connection: keep-alive
< x-amzn-RequestId: e247cbde-523a-4867-89be-9588d3654b70
< x-amz-apigw-id: TV51yHB-PHcF2Mg=
< X-Amzn-Trace-Id: Root=1-5f6bd68b-2ef4b5a7424ef64695dd27cd;Sampled=0
< 
{
"message": "Go Serverless v1.0! Your function executed successfully!",
"input": {
"resource": "/",
"path": "/",
"httpMethod": "GET",
"headers": {
"Accept": "*/*",
"Host": "80nyvq2u70.execute-api.us-west-2.amazonaws.com",
"User-Agent": "curl/7.68.0",
"x-amzn-cipher-suite": "ECDHE-RSA-AES128-GCM-SHA256",
"x-amzn-tls-version": "TLSv1.2",
"x-amzn-vpc-id": "vpc-03602a6783bdefb87",
"x-amzn-vpce-config": "1",
"x-amzn-vpce-id": "vpce-0631ee46a323b75e4",
"X-Forwarded-For": "10.0.3.28"
},
"multiValueHeaders": {
"Accept": [
"*/*"
],
"Host": [
"80nyvq2u70.execute-api.us-west-2.amazonaws.com"
],
"User-Agent": [
"curl/7.68.0"
],
"x-amzn-cipher-suite": [
"ECDHE-RSA-AES128-GCM-SHA256"
],
"x-amzn-tls-version": [
"TLSv1.2"
],
"x-amzn-vpc-id": [
"vpc-03602a6783bdefb87"
],
"x-amzn-vpce-config": [
"1"
],
"x-amzn-vpce-id": [
"vpce-0631ee46a323b75e4"
],
"X-Forwarded-For": [
"10.0.3.28"
]
},
"queryStringParameters": null,
"multiValueQueryStringParameters": null,
"pathParameters": null,
"stageVariables": null,
"requestContext": {
"resourceId": "2qf3us2l93",
"resourcePath": "/",
"httpMethod": "GET",
"extendedRequestId": "TV51yHB-PHcF2Mg=",
"requestTime": "23/Sep/2020:23:13:15 +0000",
"path": "/dev/",
"accountId": "607613765343",
"protocol": "HTTP/1.1",
"stage": "dev",
"domainPrefix": "80nyvq2u70",
"requestTimeEpoch": 1600902795396,
"requestId": "e247cbde-523a-4867-89be-9588d3654b70",
"identity": {
"cognitoIdentityPoolId": null,
"cognitoIdentityId": null,
"vpceId": "vpce-0631ee46a323b75e4",
"principalOrgId": null,
"cognitoAuthenticationType": null,
"userArn": null,
"userAgent": "curl/7.68.0",
"accountId": null,
"caller": null,
"sourceIp": "10.0.3.28",
"accessKey": null,
"vpcId": "vpc-03602a6783bdefb87",
"cognitoAuthenticationProvider": null,
"user": null
},
"domainName": "80nyvq2u70.execute-api.us-west-2.amazonaws.com",
"apiId": "80nyvq2u70"
},
"body": null,
"isBase64Encoded": false
}
* Connection #0 to host 80nyvq2u70.execute-api.us-west-2.amazonaws.com left intact
}

Y eso sería todo. Con estos pasos sencillos podemos tener nuestra API privada funcionando para ser accedida desde los recursos que estén dentro de nuestra VPC.

Mejorando el performance de SQS para millones de escrituras

Solución Procesar SQS Fargate Aurora

Hace ya casi un año que Amazon publicó que estaban desarrollando el soporte de Amazon SQS como «Event Source» para una función Lambda, y desde que la solución estuvo disponible buscaba una escusa para poder encontrar un mini proyecto para probarla.

Para el desarrollo interno de la empresa tengo un «Bot» que obtiene de manera diaria un CSV con alrededor de 1.000.000 de filas. Para todos los que estamos acostumbrados a trabajar con archivos grandes, 1M de datos no suena tan complejo, por lo que a pesar de tener mejores opciones decidí que era el momento de hacer una prueba de fuego parseando este archivo y enviando el resultado directamente a la cola fila por fila para luego ser procesado a través de una función lambda.

Este post es para comentar sobre la estructura final del proyecto, y como se fue modificando para poder funcionar de manera correcta.

Suposiciones

  • El archivo ya existe. Este POST no es sobre como crear un BOT para obtener un archivo.
  • Existe algo de conocimiento previo de lo que significa SQS, Lambda, un Trigger y Aurora.

Los problemas encontrados

A continuación una lista de problemas encontrados en el orden que fueron sucediendo.

  • El parseo inicial fue realizado a través de una función creada en NodeJS. Al parecer hasta el día de hoy el SDK de NodeJS de AWS tiene un bug en el cual el garbage collector no alcanza a borrar suficiente memoria cuando se usan sockets. Esto implica que el enviar cientos de llamados desde NodeJS hacia SQS implicaba que a pesar de tener el máximo de memoria soportado para la ejecusión, el resultado era falla de la ejecución del código. La recomendación de Amazon fue usar otro lenguaje para esta solución.
  • Luego los mensajes a SQS fueron enviados desde el parseador desarrollado en PHP sin problemas de manera secuencial, esperando que cada uno de los mensajes se enviara antes de seguir con el siguiente. Si bien esto funcionó sin problemas, el tiempo necesario para que la solución terminara fue de un poco más de 24 horas. ( Cero opción de que esto sea una solución definitiva ).

La Solución

Solución Procesar SQS Fargate Aurora
Solución Procesar SQS Fargate Aurora

Una de las características que más me gusta del desarrollo en la nube y los microservicios, es la versatilidad de como puedo manejar distintos lenguajes de programación para distintas soluciones y que todos puedan convivir sin problemas entre ellos. El BOT funciona en un contenedor de docker con PHP, y el consumidor de la cola en una función lambda utilizando NodeJS conectado a una base de datos Aurora Serverless.

Envío del mensaje a la cola

Para reducir el tiempo en que el parser del archivo CSV se utilizó una librería que trae promesas y asincronía a los desarrollos en PHP. La verdad hasta hace un par de días no sabía que esto era posible, pero la librería Guzzle Promises funciona de maravilla. Gracias a esto en vez de procesar los mensajes de la cola de manera individual los comencé a procesar por lotes de 500. Solo este cambio hizo que la solución en vez de demorarse un poco más de 24 horas, solo se demorara 86 minutos.

SQS from CSV + PHP

Si bien para la necesidad que tenía ya era un tiempo razonable, en especial por la hora a la que se ejecuta la solución, comencé a ver un par de alternativas que me permitieran reducir el tiempo de ingreso a la cola.

Encontré que en vez de mandar una fila del CSV por mensaje se aprovechaba de mejor manera la inserción en la cola si el mensaje incluía arreglos de 10 filas por mensaje. Solo este cambio significó una mejora desde los 86 minutos a 25 minutos.

PHP + SQS + CSV 25 Min

A esta altura por el momento ya quedo contento con la solución de inserción a la cola. La verdad es que se puede seguir mejorando la inserción, incluso incluyendo más filas por mensaje y comprimir el texto usando alguna librería. Es muy posible que en un futuro lo haga por curiosidad, pero por el momento me quedo contento con el tiempo de ejecución.

Procesando el mensaje.

Ya pasando por el proceso de inserción a la cola, el resto fue bastante sencillo. En la misma función lambda se ingreso como trigger directamente la cola en dónde se estaban ingresando los mensajes, con un máximo de mensajes por función de 10 ( Esto lo podemos hacer mucho más grande ! ).

Por lo que queda como lo siguiente :

  1. Cada mensaje contiene 10 filas con datos.
  2. Cada lambda maneja de manera «simultanea» 10 mensajes de la cola.
  3. Cada función lambda fue configurada con una concurrencia máxima de 100 para no tener que hacer mayores cambios en las conexiones a la BdD Aurora.  Para re-usar las conexiones a la base de datos se usa la librería Aurora Mysql Cluster de NodeJS.

Esto resulta en que en cada unidad de tiempo de procesamiento se pueden estar ingresando a la BdD alrededor de 10000 de lo que en su momento fueron filas con información desde un CSV, por lo tanto,  la velocidad de procesamiento e inserción a la base de datos es mucho mayor que la velocidad de inserción en la cola (Lo que podría traducirse en que quizás la mejor solución era ingresar a la base de datos de manera directa y no pasar por SQS).

Conclusión

Puede que la solución no sea la mejor para el problema dado por lo que deberé cambiarla en un futuro cercano. Sin embargo, estoy contento con el resultado del desempeño de Lambda con SQS como event source, que era lo que se quería probar desde un comienzo.

Espero poder probar el trigger desde SQS a Lambda en un proyecto en producción pronto.

 

Introducción a Serverless, Amazon Lambda, Express, Node.js y DynamoDB

Aprende a realizar un REST API usando Serverless, Amazon Lambda, Express, Node.js y DynamoDB. Además usaremos un par de herramientas que hará mucho más sencilla su desarrollo.

Source: Deploy a REST API using Serverless, Express and Node.js

 

Hace un tiempo que me fasciné con la tecnología Serverless, hasta el punto que gran parte de mis desarrollos y sistemas ya están funcionando con ella. Fue a tal nivel que me vi obligado a aprender lenguajes de programación de los cuales nunca me había hecho el tiempo de aprender, en este caso NodeJS ya que nunca me gustó mucho Javascript. Para mi sorpresa ES6, en lo que está basado actualmente la nueva versión de javascript, se adecua un montón a la forma como estoy acostumbrado a programar por lo que el aprendizaje fue más sencillo.

Aprovecho de escribir este tutorial ya que por un lado un amigo – Marcelo A. –  me dijo que ya no estoy escribiendo tanto en mi blog, por lo cual he perdido tráfico, además de poder ayudar a otro amigo – Ernesto M.-  con una breve introducción de estas tecnologías.

En este ejemplo crearemos una API REST – solo usaremos el create, list, and get como ejemplos- de productos que se conectará a una tabla en DynamoDB. (Pueden ver el código del ejemplo en GitHub)

Si bien a continuación hay una lista de requerimientos que deberías tener para poder entender lo más posible este ejemplo, puedes perfectamente copiar el código desde el repositorio y probarlo directamente. Yo estaré programando directamente en Linux, pero lo que mostraré debería ser transversal.

 

Requerimientos :

  • Tener una cuenta en Amazon Web Services.
  • Tener instalado la herramienta de Serverless.
  • Tener instalado NodeJS y npm.
  • Tener un IDE ( Netbeans, Atom, Sublime, etc ) con el cual poder editar el código de manera adecuada y entendible.

Creando el Proyecto

ExpressJS es un framework de NodeJS que permite el fácil manejo de rutas y endpoints, además de un sin número de funcionalidades en las sesiones y middlewares. En este ejemplo solo lo usaremos de manera sencilla, pero bienvenidos son de poder averiguar todo lo posible, de buscar más ejercicios y ejemplos, y adaptar el conocimiento a sus necesidades.

express --view=pug productos
cd productos && npm install

Con lo anterior creamos un proyecto/carpeta llamado productos, ingresamos a la carpeta e instalamos las dependencias por defecto que trae express. El código generado tiene muchas más de las cosas que necesitamos para este sencillo ejemplo, pero los dejaremos ahí para que puedan jugar en caso de querer probar y ver que hacen. A continuación la estructura que deberíamos tener en este momento sin incluir la subcarpetas de los módulos.

├── app.js
├── bin
│   └── www
├── LICENSE
├── nbproject
│   ├── private
│   ├── project.properties
│   └── project.xml
├── node_modules
├── package.json
├── public
│   ├── images
│   ├── javascripts
│   └── stylesheets
├── README.md
├── routes
│   ├── index.js
│   └── users.js
└── views
    ├── error.pug
    ├── index.pug
    └── layout.pug

Podemos notar que en la carpeta rutas tenemos una para usuarios y una de index, y podemos corroborar que estas son llamadas desde el archivo app.js.

Si en este momento todo sigue bien, podemos probar que el código inicial funcione de la siguiente manera :

DEBUG=productos:* npm start

Ahora podemos acceder a través de un explorador y veremos la pantalla inicial de express.

 

Exemplo de ExpressJS con NodeJS, Amazon Lambda, DynamoDB, y Serverless

 

Agregando Ruta de Productos

En este momento deberíamos ser capaces de entrar al endpoint de usuarios, pero lo que nosotros queremos es una ruta para los productos. Para lograrlo :

  1. Copiaremos el archivo de usuarios (users.js) en la misma carpeta con nombre de productos.js
  2. Agregaremos la variable productos en el archivo app.js de la siguiente manera : var productos = require(‘./routes/productos’);
  3. Le diremos a express que queremos usar la nueva ruta de productos como su mismo nombre : app.use(‘/productos’, productos);

En archivo de productos.js agregaremos dos métodos, un get y un create.

var express = require('express');
var router = express.Router();

/* GET users listing. */
router.get('/', function (req, res, next) {
    res.send('Index Productos');
});

router.get('/:id', function (req, res, next) {
    res.send('Producto ID : ' + req.params.id);
});

router.post('/', function (req, res, next) {
    res.send('CREANDO PRODUCTO');
});

module.exports = router;


Si iniciamos el servidor nuevamente deberíamos ser capaces de acceder a las rutas de index, de producto, y de creación con los verbos respectivos ( get and post ).

 

 

Agregando Serverless

Antes de poder iniciar las conexiones a la BdD con DynamoDB, debemos hacer unos cambios para utilizar la herramienta de serverless. Recuerda que debes de tener el comando serverless instalado.

  1. Agregamos la librería serverless-http
  2. Cargamos la librería de serverless-http

Para agregar la librería, abrimos la carpeta del proyecto y ejecutamos :

npm install --save serverless-http

Ahora en el archivo app.js incluimos al comienzo la librería de la siguiente manera :

const serverless = require('serverless-http');

 

Al final del archivo reemplazamos module.exports = app por module.exports.handler = serverless(app) ya que ahora es serverless quién se encargará de ejecutar el código.

Con estos cambios, solo nos falta decirle a serverless que es lo que debe de hacer, y como se debe de comportar. Esto lo hacemos con un archivo que creamos en el root del directorio llamado serverless.yml con el siguiente contenido.

# serverless.yml

service: api-rest-productos

provider:
 name: aws
 runtime: nodejs6.10
 stage: dev
 region: us-east-1

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

Teniendo ya la configuración de serverless lista, ahora solo nos queda subirlo a Amazon Lambda. Serverless creará a través de CloudFormation todos los recursos que nuestra API pueda llegar a necesitar, para hacer el deploy simplemente ejecutamos el comando sls deploy.

$ sls deploy
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 (2.73 MB)...
Serverless: Validating template...
Serverless: Updating Stack...
Serverless: Checking Stack update progress...
.................................
Serverless: Stack update finished...
Service Information
service: api-rest-productos
stage: dev
region: us-east-1
stack: api-rest-productos-dev
api keys:
 None
endpoints:
 ANY - https://og6f6nu8b9.execute-api.us-east-1.amazonaws.com/dev
 ANY - https://og6f6nu8b9.execute-api.us-east-1.amazonaws.com/dev/{proxy+}
functions:
 app: api-rest-productos-dev-app
Serverless: Publish service to Serverless Platform...

Serverless creó la función lambda y el API Gateway correspondiente para poder acceder a ella. En general yo SOLO creo las funciones de esta manera, ya que me gusta poder modificar los API Endpoints desde la consola de Amazon.

En este caso si accedemos a los endpoints que nos da como resultado serverless, podemos acceder a través de la web a los ejemplos que vimos de manera local anteriormente.

Accediendo a DynamoDB

Ya tenemos nuestra aplicación andando sin problemas en los servidores de amazon ( Ojo, que este ejemplo no tiene un servidor asociado! ), ahora la idea sería hacer algo útil con ella.

  1. Generaremos el nombre de la tabla de manera dinámica.
  2. Crearemos una tabla de DynamoDB de manera automática dependiendo del Stage en que se encuentre nuestro desarrollo.
  3. Generaremos los permisos que nuestra aplicación necesita para poder acceder a estos recursos.

Editaremos entonces el archivo serverless.yml para hacer todo lo anterior.

# serverless.yml

service: api-rest-productos

custom:
  tableName: 'api-rest-productos-${self:provider.stage}'
  dynamodb:
    start:
      migrate: true

provider:
  name: aws
  runtime: nodejs6.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": ["ProductsDynamoDBTable", "Arn" ] }
  environment:
    PRODUCTS_TABLE: ${self:custom.tableName}
    
functions:
  app:
    handler: app.handler
    events:
      - http: ANY /
      - http: 'ANY {proxy+}'

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

Con los cambios, al hacer el deploy se generará la tabla de DynamoDB correspondiente, en este caso terminada con -dev.

Ahora modificaremos nuestra ruta de productos para poder conectar con nuestra nueva tabla.

Primero instalaremos el SDK de Amazon y lo incluiremos en nuestro código.

$ npm install –save aws-sdk

Agregamos la librería de Amazon en nuestro archivo de productos.js después de requerir la librería de express.

const AWS = require('aws-sdk');

Después de las librerías agregamos el siguiente código para poder acceder a las tablas :

const PRODUCTS_TABLE = process.env.PRODUCTS_TABLE;
const dynamoDb = new AWS.DynamoDB.DocumentClient();

Finalmente modificamos nuestro archivo de productos para poder realizar las operaciones con la tabla.

 /* GET products listing. */
 router.get('/', function (req, res, next) {
 var params = {
 TableName: PRODUCTS_TABLE
 };

dynamoDb.scan(params, function (err, data) {
 if (err)
 console.log(err, err.stack); // an error occurred
 else
 console.log(data); // successful response
 res.json(data);
 });
 });

// Get Product endpoint
 router.get('/:productId', function (req, res) {
 const params = {
 TableName: PRODUCTS_TABLE,
 Key: {
 productId: req.params.productId,
 },
 }

dynamoDb.get(params, (error, result) => {
 if (error) {
 console.log(error);
 res.status(400).json({error: 'No se pudo obtener el producto'});
 }
 if (result.Item) {
 const {productId, name} = result.Item;
 res.json({productId, name});
 } else {
 res.status(404).json({error: "Producto no encontrado"});
 }
 });
 })

router.post('/', function (req, res, next) {
 console.log("Creando Producto");
 const {productId, name} = req.body;
 console.log("productId = " + productId);
 console.log("name = " + name);

if (typeof productId !== 'string') {
 res.status(400).json({error: '"productId" must be a string -> ' + productId});
 } else if (typeof name !== 'string') {
 res.status(400).json({error: '"name" must be a string' + name});
 }

const params = {
 TableName: PRODUCTS_TABLE,
 Item: {
 productId: productId,
 name: name,
 },
 };

dynamoDb.put(params, (error) => {
 if (error) {
 console.log(error);
 res.status(400).json({error: 'No se pudo crear producto'});
 }
 console.log("Producto " + productId + " creado exitosamente.");
 res.json({productId, name});
 });
 });

Ingresando Y obteniendo datos.

Para ingresar los datos podemos hacerlo a través de CURL, generar un formulario, o simplemente usar una herramienta como PostMan.

En este caso ingresemos dos datos para probar (Recuerda cambiar la URL por la tuya !):

curl -H "Content-Type: application/json" -X POST https://og6f6nu8b9.execute-api.us-east-1.amazonaws.com/dev/productos -d '{"productId": "mySku", "name": "Mi Producto"}'
curl -H "Content-Type: application/json" -X POST https://og6f6nu8b9.execute-api.us-east-1.amazonaws.com/dev/productos -d '{"productId": "mySku2", "name": "Mi Producto2"}'
curl -H "Content-Type: application/json" -X POST https://og6f6nu8b9.execute-api.us-east-1.amazonaws.com/dev/productos -d '{"productId": "mySku3", "name": "Mi Producto3"}'

Para ver la lista de los productos ingresados simplemente accedemos al endpoint de productos

Y para ver un producto particular agregamos al endpoint el id, por ejemplo :

Mejoras al Ejemplo.

Claramente este es un ejemplo sencillo de lo que se puede lograr, algunos ejemplos de mejoras con los que podrías jugar  :

  1. Agregar seguridad,  o autorización al API. Esto lo puedes hacer directamente en API Gateway o a través de código.
  2. Usar Clases y Herencias. En este ejemplo no aprovechamos el poder de las clases para hacerlo más sencillo.
  3. Instalar plugins para poder desarrollar de manera local. El desarrollo es mucho más expedito si lo puedes de hacer local.
  4. Y lo que se te ocurra!

 

Finalizando

La combinación de herramientas presentada en este artículo puede ayudarte a tener los conocimientos básicos de la tecnología de funciones como servicio. Queda mucho por leer y aprender, pero de verdad espero que sean tan apasionados como ella como yo. Mucho éxito !

BTW, recuerda ver el código del proyecto en el GitHub : https://github.com/ctala/introduccion-serverless