layout: index

Quinto Hito: Uso de sistemas serverless

Descripción

El principal objetivo de este hito del proyecto es entender los sistemas serverless al mismo. Los tres subobjetivos son aprender cómo describir la versión del lenguaje de programación que se usa en el proyecto y la infraestructura que necesita para funcionar, así como la elección de un sistema y sitio para integración continua y configuración del mismo.

Prerrequisitos

Haber llevado a cabo los ejercicios del tema correspondiente y haber actualizado el fichero de objetivos con un enlace a los mismos.

Explicación

Lo que se pide en este hito es esencialmente que se codifique al menos una función de la aplicación y se despliegue en un servicio serverless tal como Netlify o Vercel.

Eventualmente, el destino de las aplicaciones es estar en la nube, y, de forma invisible o invisible, van a ofrecer un interfaz de aplicación (API) al resto de la aplicación o eventualmente a un front-end. Aunque a base de funciones se pueden crear aplicaciones completas, en el estado actual de la aplicación de la asignatura su mejor uso será crear un prototipo de alguna de las funciones de nuestra aplicación en un sistema serverless.

Con esto se persigue que se entiendan dos conceptos clave:

• El concepto de ruta. Aunque la mayor parte de los sistemas serverless fuerzan una parte de la ruta, el resto puede diseñarse en torno al concepto de URI, es decir, de recurso al que se vaya a acceder. En la práctica, en este caso simplemente significará que el nombre que usemos en la ruta sea el de un recurso (y no una acción como get o lo que sea). Más adelante, sin embargo, el diseño de rutas tendrá su importancia.
• El de petición/respuesta REST, es decir, cómo tomar el contenido de una petición HTTP, extraer los parámetros de la petición, procesar esa petición y devolver el resultado usando el tipo MIME adecuado.

Por supuesto, objetivo terciario es familiarizarse con los procesos de integración/despliegue continuo implícitos y simplificados en estos dos sistemas, que los llevan a la mínima expresión.

Lo principal, de todas formas, sea como un sistema de prototipado rápido como parte, efectivamente, de la aplicación, se trata de levantar un API serverless.

Entrega de la práctica

Se tendrá que haber actualizado el repositorio que se usara en los hitos anteriores y añadir al fichero de este hito el nombre del proyecto, el autor y un enlace al mismo y hacer un pull request.

Para testear si se ha hecho correctamente, el estudiante tendrá que hacer lo siguiente:

• Añadir una clave URL al fichero iv.yaml que indique la dirección a la que se tiene que hacer una petición. Esa URL será de alguno de los dos sistemas serverless anteriores, o si lo desea el estudiante, de AWS Lambda o Firebase Cloud Functions.
• En el directorio principal habrá un fichero 5.json que contendrá el resultado de hacer tal petición. El contenido de ese fichero se comparará a lo que devuelva la petición indicada de la forma anterior.

Valoración

Si se cumplen los requisitos, la puntuación será:

1. 3 puntos: despliegue correcto y funcionando, con documentación de la conexión entre el repo en GitHub y Netlify/Vercel para despliegue continuo.
2. 3 puntos: integración dentro del proyecto general (es decir, como todo el código deberá tener sus issues y/o HU correspondientes). En esta rúbrica se valorará que se haya ido más allá del despliegue de un ejemplo.
3. 2 puntos: uso (e integración) de varias plataformas de despliegue (es decir, no repetir la misma función en todas las plataformas, sino crear funciones nuevas que también se integren en el proyecto). o uso de plataformas tales como Firebase o Azure functions.
4. 2 puntos: en conjunción con la rúbrica 2, se asigna por originalidad, buena integración dentro del proyecto, tener que programarlos en un lenguaje diferente al resto del proyecto (si es que el lenguaje en que está este no está soportado en el sistema serverless), integración con un front-end web/bot de Telegram/webhook de cualquier tipo que funcione en la práctica.

Se recuerda también que este es un hito de un proyecto, y como tal los tests para este hito incluyen los de todos los anteriores; el proyecto tendrá que seguir desarrollándose de acuerdo a lo indicado en el hito anterior y tener como mínimo la estructura que se creó en el hito 0.