Initial commit

.eslintignore

@@ -0,0 +1,3 @@
+/node_modules/*
+/coverage/*
+*.md 

.eslintrc.json

@@ -0,0 +1,18 @@
+{
+    "extends": [
+        "airbnb",
+        "prettier"
+    ],
+    "plugins": [
+        "prettier"
+    ],
+    "rules": {
+        "prettier/prettier": [
+            "error"
+        ],
+        "no-console": "off"
+    },
+    "env": {
+        "jest": true
+    }
+}

.gitignore

@@ -0,0 +1,67 @@
+# Logs
+logs
+*.log
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+
+# Runtime data
+pids
+*.pid
+*.seed
+*.pid.lock
+
+# Directory for instrumented libs generated by jscoverage/JSCover
+lib-cov
+
+# Coverage directory used by tools like istanbul
+coverage
+
+# nyc test coverage
+.nyc_output
+
+# Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files)
+.grunt
+
+# Bower dependency directory (https://bower.io/)
+bower_components
+
+# node-waf configuration
+.lock-wscript
+
+# Compiled binary addons (https://nodejs.org/api/addons.html)
+build/Release
+
+# Dependency directories
+node_modules/
+jspm_packages/
+
+# TypeScript v1 declaration files
+typings/
+
+# Optional npm cache directory
+.npm
+
+# Optional eslint cache
+.eslintcache
+
+# Optional REPL history
+.node_repl_history
+
+# Output of 'npm pack'
+*.tgz
+
+# Yarn Integrity file
+.yarn-integrity
+
+# dotenv environment variables file
+.env
+
+# next.js build output
+.next
+
+# serverless framework
+.serverless
+
+# vscode
+.vscode

README.md

@@ -1 +1,85 @@
-# WCF
+# NO ME PUEDO CREER QUE PUEDA HACER UNA APLICACIÓN SERVERLESS EN DOS HORAS
+
+Hola, bienvenido a este workshop sobre Serverless. Antes de empezar necesitaria que configuraras unas cuantas cosas en tu ordenador. Debes hacer esto antes de venir al workshop por dos razones:
+ - No perder el tiempo en los preparativos durante el workshop y así sacar el máximo provecho de él.
+ - Algunas cuentas pueden tardar unas horas en activarse. Si lo haces al principio del workshop puede ser que no tengas la cuenta activa durante el mismo.
+
+## Cuenta en AWS
+Vamos a utilizar AWS Lambda, así que necesitas tener una cuenta en AWS. No te preocupes, puedes crear una cuenta gratuita sin problemas [aquí](https://aws.amazon.com/free/start-your-free-trial/).
+
+Vamos a necesitar un par de usuarios en tu cuenta para el workshop. Uno será el que utilizaremos en local para desplegar y probar la aplicación. El segundo será el que utilizará nuestro sistema de integración contínua para desplegar y probar la aplicación. Vamos a por ello: repite los siguientes pasos dos veces (una por usuario) con diferentes nombres de usuario.
+ - Haz login en tu cuenta de AWS y ve a la página Identity & Access Management (IAM)
+ - Haz click en Users y después en Add User. Introduce serverless-local como nombre para el primer usuario y serverless-agent como nombre para el segundo usuario. Activa Programmatic Access. Haz click en Next para ir a la página de permisos. Haz click en Attach existing policies directly y después en Create policy. Selecciona el tab JSON, y copia allí el contenido de este [gist](https://gist.github.com/ServerlessBot/7618156b8671840a539f405dea2704c8).
+ - Selecciona Review policy. Asígnale el nombre MinimumServerlessPermissions. Puedes asignarle también una descripción. 
+ - Vuelve a la pantalla de creación del usuario, actualiza el listado de policies y selecciona la policy que acabamos de crear. Clica en Next: tags. 
+ - Clica en Next: review. Chequea que todo está bien y clica en Create user. 
+ - Visualiza y copia la API Key y el Secret a un lugar temporal. Lo necesitaremos más tarde.
+
+## Creación de un profile en nuestro ordenador.
+Ahora es la hora de configurar nuestro ordenador para que utilice estas credenciales a la hora de desplegar nuestra aplicación. Hay varias maneras de hacer esto pero la mejor es utilizar un profile y que este no sea el profile por defecto, para evitar posibles desgracias en el futuro.
+
+Para setear este profile hay varias maneras, pero la más cómoda es utilizar el propio [Serverless framework](https://serverless.com). Así que clona o "forkea" este repositorio e instala los paquetes npm utilizando el comando `npm install`. Una vez instalados, ejecuta el siguiente comando: `./node_modules/.bin/serverless config credentials --provider aws --key <tu_key> --secret <tu_secret> --profile serverless-local`
+
+Dónde `tu_key` y `tu_secret` son los datos que nos hemos guardado del paso anterior para el usuario serverless-local. Las claves para el usuario serverless-agent las utilizaremos más tarde, así que guárdalas bien. Con esto ya tendremos el profile creado.
+
+## Cómo deployar
+Para deployar vamos a utilizar el framework Serverless. Este framework nos abstrae de mucha complejidad a la hora de desplegar aplicaciones serverless. Como habrás observado, hemos instalado el framework como una dependencia local en nuestro proyecto. Esto es una buena práctica, ya que así evitamos problemas de incompatibilidad de versiones entre diferentes desarrolladores y también evitamos tener que tener instalado el framework en nuestra agente de build.
+
+El framework basa su funcionamiento en un fichero llamado serverless.yml que tiene que existir en la raiz de nuestro proyecto. Vamos a ver que hay en este fichero de mínimos que tenemos por ahora:
+```
+service: pufouniversity
+```
+
+Esto es el nombre del servicio. Dentro de un servicio podemos tener diferentes Lambdas y otros recursos. Todos estos recursos se tratan como un todo. Por ejemplo, si le digo al framework que elimine el servicio, eliminará todos los recursos que existan en este fichero. Esto en AWS se traduce a un stack de CloudFormation. 
+
+A parte, el framework utilizará este nombre como prefijo a todos los recursos, de manera que serán fáciles de buscar en nuestra subscripción.
+
+```
+custom:
+  defaultRegion: eu-west-1
+  stage: ${opt:stage, self:provider.stage}
+```
+
+Aquí definiremos algunas variables propias que después podremos utilizar en el fichero. Aquí estamos definiendo una variable llamada `defaultRegion` que tiene el valor `eu-west-1` y, lo que es más interesante, una variable llamada `stage` que toma su valor por interpolación. Lo que hace esta interpolación es intentar coger el valor de `opt:stage`. `opt:stage` es el valor del parámetro stage cuando llamamos a `serverless deploy` por línea de comandos: `serverless deploy --stage sit`. En el caso que no le pasemos este parámetro al hacer deploy, la interpolación nos dice que cogerá el valor del campo stage de la sección provider (que ahora veremos).
+
+```
+provider:
+  name: aws
+  runtime: nodejs8.10
+  region: ${opt:region, self:custom.defaultRegion}
+  stage: dev${env:SLSUSER, ""}
+```
+
+En esta sección definiremos cual es nuestro provider (AWS. Azure, Google Cloud, etc). En nuestro caso le decimos que es `aws` y que el runtime que vamos a utilizar es `nodejs8.10`. Para la region utilizamos una interpolación como la que hemos visto antes. Para el stage, utilzamos una interpolación un poco distinta. En este caso le decimos que el nombre del stage (en la sección provider) siempre empezará por dev y después pueden pasar dos cosas: si la variable de entorno SLSUSER está seteada, utilizaremos su valor, sinó no utilizaremos nada. Es decir, si yo tengo `manolete` como valor de la variable de entorno SLSUER, el valor de stage será `devmanolete`. Si no la tengo seteada el valor de stage será `dev`. Esto lo hacemos para que cada usuario pueda tener su propio entorno de pruebas de una manera sencilla.
+
+```
+functions:
+  initialTest:
+    handler: src/functions/initialTest.handler
+    events:
+      - http:
+          path: api/initialTest/{name}
+          method: get
+```
+
+Finalmente tenemos la sección de las funciones. En este caso estamos definiendo una función llamada `initialTest`, cuyo código está en `src/functions/initialTest.js` y dentro de ese fichero en una función llamada `handler`, que se activa por una llamda http GET al path `api/initialTest` y que tiene un path parameter llamado `name`. Es decir, que nuestra función se podrá llamar haciendo un get a una dirección parecida a `https://XXXXXXXX.execute-api.eu-west-1.amazonaws.com/devmanolete/api/initialTest/wecodefest`. Cuando hayamos desplegado la función y la llamemos, recibiremos como respuesta `Hello wecodefest`.
+
+## Primer deploy
+Antes de ver como está escrita la función, vamos a desplegarla para comprobar que lo tenemos todo bien configurado.
+
+Si miras el fichero `package.json`, en la sección de scripts verás que hay un script llamado deploy que ejecuta lo siguiente:
+```
+serverless deploy --aws-profile serverless-local
+```
+
+Este comando lo que hace es decirle al framework que deploye el servicio utilizando el profile `serverless-local` que es el que acabamos de configurar. Si ejecutamos este comando tal cual, nos va a deployar el servicio en el stage dev. Pero nosotros queremos que lo haga en el nuestro propio. Para eso tenemos dos opciones:
+ - Setear la variable de entorno en nuestra máquina y ejecutar el comando: `npm run deploy`.
+ - Setear la variable de entorno solo para la ejecución del comando: `SLSUSER=manolete npm run deploy`.
+
+Puedes utilizar la que te haga más (o menos) rabia.
+
+Venga, dale a ver qué pasa!! Si todo va bien, verás un montón de lineas de log del framework y al final nos mostrará un resumen de la información del servicio. En ella, en la sección de endpoints podremos ver la dirección final de nuestro endpoint. Cópiala, cambia {name} por WeCodeFest y ejecuta la petición utilizando el navegador, postman, curl o lo que quieras.
+
+Algo interesante a observar también es el nombre del stack, que es la concatenación del nombre del servicio con el nombre del stage, y el nombre de la función, que es lo mismo pero con el nombre de la función al final.
+
+Si tienes todo esto funcionando estás donde tienes que estar para empezar el workshop. Si no lo tienes, antes del día del workshop, envíame un correo o contáctame por twitter para arreglarlo.