Crear un microservicio sobre la base de la funcionalidad del hito anterior y cumpliendo los requisitos de las historias de usuario.
Haber pasado los tests del hito anterior.
Sobre la base de la clase o funcionalidad hecha en la práctica anterior, en este hito lo esencial es diseñar una API consistente en una serie de rutas (en el caso de un API REST) y testearlo exhaustivamente usando una biblioteca específica que te provea el microservicio, o bien una biblioteca genérica, y crear la infraestructura necesaria para comenzar a ejecutarlo.
En cuanto a este último, se debe de usar el mismo fichero de construcción que se haya usado en el hito anterior, añadiendo las tareas que se indican más adelante en la entrega. Esto también permite, por ejemplo, usar uno de los sistemas de integración continua que se hayan creado para hacer una ejecución de prueba, en vez de ejecutar los tests. En general, todas las tareas que se ejecuten desde el sistema de integración continua deberán lanzar órdenes de esta herramienta que ejecute tareas.
En general, el significado de estas tareas es el siguiente:
buildgenera los ficheros que se vayan a desplegar a partir de los fuentes y, en general, llevan a cabo todas las tareas necesarias para el mismo. No todos los lenguajes o frameworks lo usan o necesitan, pero es conveniente saber que esta fase casi siempre ocurre, y no sólo en los lenguajes que compilan a un ejecutable.installa diferencia de lo que ocurre connpm(y una de las razones por las quenpmno es un ejecutor de tareas adecuado), install toma los ficheros generados anteriormente y los pasa al lugar donde el intérprete suele localizar las bibliotecas, de forma que a continuación, los tests o los ejecutables sean capaces de encontrarlo. Por ejemplo, Go copia los ficheros compilados a un directorio específico, Perl y Raku también, y C o C++ lo copiarán, por ejemplo, a/usr/lib/o/usr/local/lib. No todos los lenguajes lo necesitan, sin embargo, pero en general sí será necesario.testse comportará igual que se ha comportado desde el hito 2.
El objetivo secundario es poner en práctica las principales técnicas
usadas hoy en día para diseño de aplicaciones web u otro tipo de
aplicaciones, basadas principalmente en interfaces REST con clientes
basados en JS y, sobre todo, en marcos de aplicaciones tales
como
Dancer2,
Sinatra, Nest.js
o Sanic, dejando de lado
servidores web específicos y de propósito general como Apache o
nginx (que se pueden usar, en todo caso, en el primer caso para
aplicaciones que incluyan múltiples lenguajes o marcos y en segundo,
sobre todo, para contenido estático). Un tercer objetivo secundario
es aprender a usar en producción GitHub y otras herramientas de
desarrollo colaborativo y liberar el resultado del proyecto.
Como ya el proyecto ha llegado a un estado en el cual se puede desplegar como un servicio web, habrá que documentar cómo las rutas se ajustan a las historias de usuario que se hayan planteado desde el principio. No hace falta que en este punto todos los tests e historias estén implementadas, pero sí las suficientes para que se puedan llevar a cabo estos tests de integración.
Se recuerda que en este caso, la integración de la que se habla es la de otras bibliotecas que dependan de la clase o clases que sean la base del servicio web, y el propio servicio web. No es necesario ningún otro tipo de servicio, y especialmente desaconsejamos, en esta fase, integrar almacenes de datos de cualquier tipo.
En este hito es cuando el MVP del backend del proyecto es cuando empieza a tomar forma. En este momento, todos los HUs que se vayan a poner en práctica tienen que tener la estructura correcta indicada en el hito 1. Es esencial también que el API esté separado de la lógica de negocio, y que incluya únicamente aquellas peticiones que se prevé que efectivamente se vayan a hacer desde un cliente; en caso contrario, simplemente no se deben de exponer mediante un API.
Conviene también que en este punto la aplicación tenga una lógica de negocio real más allá de almacenar y recuperar información. Toda la lógica de negocio, al menos que se vaya a implementar, debería estar prácticamente completa.
En este punto, el código que se haya entregado tiene que estar en el siguiente estado:
- Debe incluir, al menos, un servicio de configuración que considere las diferentes posibilidades.
- Debe tener la estructura general de las clases que se vayan a servir con el API correcta, incluyendo en su caso diseño de excepciones que puedan ocurrir en el curso normal de ejecución de la aplicación.
- No deben incluir ningún tipo de acceso a datos, pero si lo hacen debe hacerse a través de una single source of truth usando inyección de dependencias. El test de la misma se debe hacer de la misma forma.
- No es necesario, ni se solicita, que haya una "aplicación" lanzable y se prefiere que no la haya. El código debe ser única y exclusivametne el necesario para testear las rutas, y es conveniente que, en el diseño por capas, se separe la lógica de negocio de la lógica del API y esta, a su vez, del programa o aplicación desde las que se van a usar ambos.
- En este punto la aplicación puede estar potencialmente en Internet. La comprobación de tipos debe ser exhaustiva, tanto la que provea el sistema de tipos del lenguaje como la que se haga por parte del usuario en caso de que no sea así.
- Si no se incluye un test de prestaciones, al menos se debe de tener en cuenta que un hito posterior puede incluirlo, por lo que el diseño se tendrá que haber hecho teniendo en cuenta esta posibilidad.
La entrega se hará, como siempre, con un pull request, al documento correspondiente a este hito.
Para la evaluación habrá que añadir una clave make al fichero
cc.yaml. En esa clave se podrá el comando (o secuencia de comandos)
que se usan para el gestor de tareas, que en cualquier caso será una
cadena. En el caso de make será,
efectivamente, make, en otros casos será una o igual dos cosas (como
poetry run). Para los tests, se descargará el repositorio y se
ejecutará ese comando con tres targets en secuencia, por ejemplo:
make build
make install
make testEn ninguno de ellos tendrá que dar error. También se comprobará que pasen los tests en Travis, que se usará para ejecutar los tests de integración (o cualquier otro, si se desea).
La valoración se distribuirá en las siguientes rúbricas:
- 2 puntos: Justificación técnica del framework elegido para el microservicio.
- 2 puntos: Diseño en general del API, las rutas (o tareas), tests y documentación de todo, justificando como se ajustan a las historias de usuario, de forma que reflejen correctamente un diseño por capas que desacopla la lógica de negocio del API.
- 2 puntos: uso de buenas prácticas: configuración distribuida
- 2 puntos: uso de logs, incluyendo justificación del framework y herramienta elegida.
- 2 puntos: tests correctos y de acuerdo con las historias de usuario.
Si la aplicación no funciona o hay plagio o trabajo en común, la práctica estará suspensa.
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 1 (de la asignatura).
Si ya se ha entregado y suspendido esta práctica, se podrá reenviar siguiendo estas instrucciones.