Overview

Arquitectura a 5.000m

Para el diploma de vértices permanente vamos a usar una aproximación moderna, en concreto un JamStack lo más estático posible; debido a que no hay urgencia en la consulta de los vertices ya completados.

La web JamStack tendrá un aspecto sobrio, partiendo de una plantilla, ya sea una gratuita o comprada, con las mínimas modificaciones. Cualquiera de las que hay en estos sitios nos valdría:

Por otro lado estos sitios se renderizarán con hugo. Lo que nos asegura la mayor “estaticidad” posible. Al ser un framwerk que solo puede generar sitios estáticos: https://gohugo.io/.

Hosting

Para el hosting elegiremos cludflare, ya que actualmente tiene un coste 0 el publicar alli una página web estática, por lo que para optimizar costes hay que tener una aproximación radical en cuanto a la generación de contenido.

Esto significa que todo lo que se pueda será un sitio estático aunque esto parezca una locura. Todos los datos están guardados como json en las carpetas de datos, y todas las páginas estarán renderizadas de antemano.

Para evitar que el sitio web tenga un tamaño inmanejable la renderización final de los sitios que requieren algo más de dinamismo se hará con javascript. Por ejemplo, cuando un usuario quiera ver la página de los ranquinks esta se cargará sin contenido y luego el código javascript de la página accederá a la los ficheros de datos json para mostrar el contenido concreto que se pida.
De otra forma la combinatoria de generación pagina x consulta puede dar lugar a millones de ficheros.

Para el login vamos a usar los web workers de cloudflare, y esta debería ser una de las dos únicas partes dinámicas de la web.

Estos workers permiten un gran número de llamadas gratuitas mensuales. Y si es necesario aumentar el número de llamadas que se pueden hacer su precio es casi ridículo. Ya que 1.000.000 de peticiones cuestan $0.65.

Nuestro login será muy sencillo, basado en OAuth para capitalizar al máximo la gestión ya hecha por otra plataforma, en un primer momento recomiendo usar Gmail/Google como mecanismo de login; debido principalmente a que cualquier persona con un movil Android tiene, le guste o no, una cuenta de Google.

En el proceso además nos quitaremos un montón de problemas de posibles ataques al login, ya que se los comerá, y descartará, en primera instancia Google.

Una vez que tengamos el login mediante Google, si es el primer registro del usuario, entonces tendremos que llevar a cabo el proceso de on-boarding. Donde le pediremos más información y le obligaremos a firmar nuestras condiciones de uso.

On-Boarding

Para guardar la información del login, y el resto de pasos requeridos tras el proceso de login, necesitaremos una base de datos serverless. Auque cloudflare tiene una su precio es desmedido (al igual que el precio de su login serverless) por lo que usaremos para un primera fase, y mientras cloudflare lo permita, la plataforma de PlanetScale. Que ofrece gratis la friolera de 1.000.000.000 de lecturas gratuitas al mes y 10.000.000 de escrituras al mes; ojalá tengamos tanto éxito como para tener que pagar la base de datos.

Por otro lado los datos extra que se le pedirán al usuario serán:

Indicativos: debería poder poner fechas de inicio de uso (siendo el fin el siguiente inicio)
Aceptación de las condiciones del concurso (necesario para subir logs)

Area privada

Los socios del Radio Club Henares tendrán alguna información extra sobre su rendimiento en el diploma. Podrán ver:

Un mapa con todos los vértices que han hecho
Un listado de todas sus activaciones
- De cada activación que contactos se han cruzado ya o no
Un listado de todos los vértices que tiene y en que modos
- De cada vertice que activador se lo proporcionó por banda

Proyectos propuestos

Debido la naturaleza de la arquitectura, orientada al dato y al resultado estático, su mantenimiento y creación depende de varios repositorios de código (programas) que tienen como objetivo generar los datos que se usarán en el sitio web.

Teniendo en cuenta la naturaleza competitiva de la radioafición, y la tendencia natural de los técnicos a la optimización y explotación de los fallos de forma. Es necesario que todos los programas implicados tengan una robustez máxima.
Por lo que todos los programas deben tener un diseño previo y además estar desarrollados usando tecnicas de implementación orientadas al test como: TDD, ATDD, DDD, etc…

La estrategía puede cambiar, pero en este momento las piezas implicadas son:

Importadores: de momento no hay ninguno, su responsabilidad será obtener los datos de sus fuentes de origen para que sean usados en la generación del sitio web. Si su formato no es web compatible es posible que usen los conversores para llevar a cabo su tarea.
Conversores: estos programas se encargarán de convertir los formatos que no sean complatibles con el sitio web en json, en el caso de los datos, o en formatos web, como jpeg o similar.
Validadores: sobre todo en el caso de los datos que se van usar en el diploma, deben pasar la mejor validación posible.
Calculadores: todos los cálculos necesarios deben de estar ya pregenerados puesto que no tendremos un backend en producción que pueda calcularlos bajo petición.
Compositor web: este debe ser único. En el estará el programa que compondrá el sitio web. Como ya hemos comentado, y como restricción artificial para mantener los requisitos del hosting al mínimo se usará Hugo.io. También estarán incluidos los workers de Cloudflare.

Actualmente tenemos algunos programas hechos:

Adif2json: Es un conversor del formato ADIF.org a json.
QSOVeritas: consiste en un validador de las actividades, es posible que en el futuro evoluciones a un sitio completo de administración del diploma. Un completo backend con el máximo número de automatizaciones posibles para facilitar el trabajo de los voluntarios.
AirwaveAchiever: Este será el calculador del diploma. Debe poder calcular los hitos del diploma moderno y del clásico, de forma que se pueda decomisionar totalmente el sitio web antiguo.

Last updated on 13 Jun 2023
Published on 13 Jun 2023