El objetivo de esta guía es introducir a cualquier desarrollador tanto en la pila tecnológica que se usa para el desarrollo de aplicaciones en Mi Campus, como en los procedimientos de configuración, despliegue y gestión de la calidad.

0. ¿Qué es Mi Campus?

Mi campus es una aplicación frontend implementada en VueJS comunicada con una nube de servicios web desarrollados con Spring Boot que la nutren. Para poder desarrollar y gestionar de manera ágil todo este ecosistema, cada aplicación está alojada en un contenedor Docker que incluye tanto a ella misma como un sistema operativo, librerías y configuración necesaria para su ejecución. A su vez también tiene una configuración hardware establecida indicando los requisitos de CPU y RAM que puede llegar a consumir. Llamaremos POD a una instancia en ejecución de una aplicación concreta.

1. Infraestructura bajo Mi campus

Como hemos visto anteriormente, Mi Campus está constituido por un conjunto de PODs que ejecutan aplicaciones independientes que interactúan entre sí. No obstante es necesario disponer de un sistema que orqueste los diferentes PODs y su configuración, para ello disponemos de Kubernetes (también llamado k8s) que es una plataforma para la gestión y control de contenedores. Gracias a esta herramienta podremos tener una orquestación real de cada POD para que, en caso de necesidad, se creen réplicas ( nuevos PODs ) para soportar una carga mayor y se den de baja cuando no sean necesarios de manera automática y desatendida.

Al mismo tiempo gracias al enfoque IaC (Infraestructure as Code) a partir de un fichero de texto, llamado manifiesto, podemos especificar cómo desplegar cada POD, con cuánta memoria mínima o máxima, cuándo escalar el POD en base a límites de recursos, etc. Es decir, todo el trabajo que hay que hacer de manera manual en una infraestructura tradicional los gestionará Kubernetes en base a lo que le indiquemos en los manifiestos. Adicionalmente, todo cluster Kubernetes tiene un punto de entrada, el cual se denomina Ingress, en el cual se pueden establecer reglas de tráfico entre el exterior y los diferentes PODs

2. Desarrollo de servicios

Toda la funcionalidad de Mi Campus se encuentra en la nube de servicios que nutren el frontend. Dichos servicios están desarrollados con el framework FundewebJS basado en SpringBoot y la manera de comunicarse con el frontend es exponiendo una API de servicios, que para Mi Campus será una API de servicios REST. Una API REST se puede resumir como un conjunto de URLs a las que nuestra aplicación es capaz de responder, por tanto, el protocolo de comunicación entre frontend y banckend (nuestros servicios) será mediante HTTP. Es importante conocer bien tanto la pila tecnológica utilizada, como todos los requisitos derivados de una comunicación HTTP.

1. Para trabajar y configurar un proyecto nuevo deberemos leer la guía de FundewebJS
2. Para conocer cómo desarrollar servicios REST correctos, deberemos revisar la Normativa de servicios REST
3. Para saber cómo documentar un servicio REST deberemos seguir las indicaciones de Documentar APIs con OPENAPI  
4. Para desarrollar test en nuestros servicios deberemos leer la guía FundewebJS - Test

3. Arquitectura de proyectos

Los desarrollos de servicios de Mi Campus deben ser totalmente desacoplados para que permitan, si fuera necesario, cambiar el código fuente de un proyecto a otro para reorganizar la arquitectura de los PODs según la demanda de los usuarios. Para ello se ha optado por un enfoque basado en arquitecturas hexagonales (o de cebolla) que dividen el código en tres capas bien definidas de menor a mayor concreción con el dominio del servicio, siendo la capa mas externa la que comunica con cualquier sistema fuera de la aplicación  (base de datos, otros endpoints REST, etc).

Diagrama de flujo de dependencias

Para poder definir esta arquitectura nos apoyaremos en el enfoque de diseño de proyectos Domain Driven Design, donde estableceremos dominios que guiarán desde el diseño del core de nuestra aplicación hasta las rutas donde deberán estar los endpoint REST.

A la hora de empezar un nuevo desarrollo, deberemos identificar su dominio y decidir si la funcionalidad a realizar debería incorporarse a un proyecto ya existente, porque ya modela dicho dominio, o bien a uno nuevo porque no estaba contemplado con anterioridad. Igualmente deberemos analizar las rutas de los endpoints que expongamos para que reflejen el dominio modelado más allá del nombre que se le pueda dar al proyecto.

Junto con este modelado, la comunicación interna entre los diferentes elementos del proyecto se hace en base a eventos bajo el principio CQRS (Command Query Responsibility Segregation) que divide las operaciones de lectura de datos de las operaciones de escritura de datos. De esta manera queda totalmente desacoplada cualquier interacción dentro de la aplicación y nos permitirá, en un futuro, poder emitir esos eventos también fuera de la aplicación para que otros servicios "reaccionen" a determinadas acciones. No obstante, actualmente dichos eventos son sólo internos a la aplicación.

Modelos de escritura y lectura

A nivel técnico, todos los proyectos se crean a partir de una semilla que contiene las librerías necesarias para trabajar, a su vez también se desarrollan librerías internas que pueden incluirse en el proyecto en cualquier momento, tanto en su creación o con posterioridad. Dicha semilla evolucionará junto con la pila tecnológica.

4. Seguridad

Un backend de servicios en Mi Campus, usualmente, expone una API REST con una URL determinada al mundo. Es decir, aunque no haya un frontend mostrando al usuario el resultado de invocar a nuestros endpoints REST, dicha API ya es accesible vía URL por cualquier persona o equipo informático autónomo. Por tanto, desde el momento en el que mi API REST esté desplegada en el entorno de producción es susceptible de ser atacada por cualquiera, por muy extraña o parametrizada que puedan ser las URL de los endpoints REST que se exponen.

Por tanto es crucial que desde el primer momento tengamos presente la seguridad, que va más allá de simplemente validar al usuario/servicio que se conecta ya que un usuario válido del sistema también puede iniciar un ataque, bien de manera intencionada, bien porque en su PC hay código dañino que le ha robado la sesión y/o el token de usuario.

5. Documentación

Todas las APIs del backend deben estar documentadas para que cualquier equipo pueda consultarlas de manera independiente. Dichas APIs se encuentran recogidas en el Catálogo de APIs de ATICA donde cualquiera podrá consultar los métodos que disponen y los resultados. 

Para poder documentar las APIs utilizaremos la iniciativa OpenAPI que establece un lenguaje común para describir los diferentes elementos necesarios para realizar la documentación. Dentro de un proyecto FundewebJS estarán cargadas las librerías necesarias para poder generar esta documentación directamente desde Java, a su vez la guía Documentar APIs con OPENAPI indica cómo podemos configurarlo y utilizarlo.

6. Calidad

La revisión de la calidad de los desarrollos es un paso imprescindible en el desarrollo de los mismos y así se indica en MEDEA P9. Gestión de la calidad del software no obstante, en Mi Campus, al estar dividido entre APIs de servicios distribuidas y un frontend único hay ciertas peculiaridades que debemos tener en cuenta:

• Pruebas de código fuente: Se realizarán tal y como se indica en MEDEA
• Pruebas de accesibilidad web: Sólo se tienen que realizar cuando se realicen cambios en el frontend del proyecto. Deberán ajustarse a los plazos que indica en OAW y se recogen dentro de la metodología.
  • ¿Si hago un pequeño cambio en el frontend de algún servicio tengo que hacer el análisis de la pantalla y actualizar la declaración de accesibilidad?
    • Si el cambio es pequeño y no incorpora elementos nuevos no es necesario porque ya estarán contemplados en la declaración existente. En caso contrario se deberá analizar y, si incorpora nuevos incumplimientos, modificar la declaración de accesibilidad existente.
  • ¿Si hago un cambio sustancial o introduzco un servicio nuevo tengo que hacer el análisis de la pantalla y actualizar la declaración de accesibilidad?
    • En este caso sí que es obligatorio hacer el análisis de la pantalla para detectar nuevos incumplimientos posibles. La declaración de accesibilidad sólo se deberá actualizar si se detectan incumplimientos nuevos.
  • ¿Cuándo debo hacer el informe de accesibilidad que se presenta al Observatorio de Accesibilidad Web?
    • Este informe se hace una vez cada 3 años, salvo que MNCS pida que se haga expresamente, independientemente que durante ese periodo se hayan puesto en marcha nuevos servicios o no.
    • Cuando venzan los 3 años se deberá hacer el informe basándose en todos los análisis de las pantallas ya realizados y ampliando con los servicios nuevos que todavía no tengan el análisis hecho.
• Pruebas de seguridad: Se realizarán tal y como se indica en MEDEA
• Pruebas funcionales: En el caso de mi campus todas las pruebas funcionales de las APIs se deben hacer con Cucumber. De esta manera tenemos, a la vez, test funcionales en el código y pruebas funcionales actualizadas en todo momento. Esto supone un gran beneficio ya que, gracias a cómo se describen los test con Cucumber podemos alinearlos directamente con los requisitos dados por el responsable de la API y utilizar el propio lenguaje usado para describirlos, lo cual facilita el asentamiento del dominio y un punto común entre responsable del producto y API desarrollada.
• Pruebas de carga: Se realizarán tal y como se indica en MEDEA. Se deberán realizar en local para asegurar que la aplicación tiene un buen rendimiento antes de lanzarlos en los servidores con el departamento de sistemas. Desde MNCS se recomienda usar JMeter y VisualVM (en local) para lanzar el test y medir la memoria RAM utilizada. No obstante se puede utilizar cualquier herramienta que permita obtener, al menos, los siguientes resultados:
  • Por cada petición diferente que haga nuestro test
    • Tiempo medio de respuesta
    • Porcentaje de error
    • Bytes transmitidos
    • Número de peticiones realizadas
  • A nivel global:
    • Memoria RAM máxima
    • Memoria RAM mínima
    • Evolución de la memoria RAM durante la ejecución del test
• Pruebas de usabilidad: Se realizarán tal y como se indica en MEDEA
• Pruebas de aceptación: Se realizarán tal y como se indica en MEDEA. En este caso también pueden servir de apoyo los test Cucumber realizados en las pruebas funcionales ya que deberían cubrir todos los requisitos del proyecto.

7. Rendimiento