Imagen que contiene dibujo Descripción generada automáticamente                               

Reto edición NASA Space Apps Challenge

Universidad Católica del Uruguay

Tutores:

Sebastián Feirres

Mateo Machado

Integrantes del grupo:

Agustin Negreira

Rodrigo Doldán

Enzo Barreto

Brian Morat

Felipe Seré

Montevideo, Uruguay

23 de octubre

Introducción

El presente documento técnico constituye la descripción del trabajo realizado posterior a la finalización del evento NASA Space Apps Challenge 2025, única y exclusivamente para el reto informático académico propuesto por la Universidad Católica del Uruguay, basándonos en la continuación y mejora de lo realizado en dicho evento.

En este se detallan los principales aspectos técnicos del sistema, su arquitectura, el alcance del prototipo, las decisiones de diseño adoptadas y los pasos previstos para su evolución. El objetivo es dejar registro claro del trabajo realizado y servir como guía base para futuras iteraciones del proyecto.

Proyecto seleccionado

El proyecto se desarrolló en el marco del desafío “Will it Rain on My Parade?” del NASA Space Apps Challenge 2025, cuyo objetivo consistía en diseñar una herramienta para ayudar a las personas y organizaciones a planificar actividades al aire libre considerando la probabilidad de condiciones climáticas adversas. El reto planteaba la utilización de datos satelitales y registros históricos de la NASA para estimar patrones climáticos y proporcionar información útil para la toma de decisiones.

Como respuesta a este desafío, se propuso el desarrollo de una aplicación web que permitiera a los usuarios conocer la probabilidad de experimentar distintas condiciones meteorológicas (temperatura, precipitación, nubosidad, viento, entre otras) en una fecha y lugar determinados, incluso con meses de anticipación.

Para ello se utilizó la NASA POWER API como fuente de datos climáticos históricos y se implementó una arquitectura compuesta por un frontend en Vite + React y un backend en Node.js + Express. El backend consumió la API de la NASA y procesó los datos para luego servirlos al frontend. Además, se investigaron distintas metodologías de forecasting probabilístico basadas en climatología e inferencia estadística, desarrollando una versión preliminar del algoritmo con el objetivo de optimizarlo en futuras iteraciones.

Alcance del prototipo

El prototipo desarrollado constituye una primera versión funcional de la solución propuesta para el desafío “Will it Rain on My Parade?”. Su propósito fue validar la factibilidad técnica de integrar datos climáticos oficiales de la NASA, procesarlos estadísticamente y presentarlos de manera clara al usuario final a través de una interfaz web.

El sistema implementado consta de cuatro componentes principales:

  • Frontend en Vite + React, que permite la interacción con el usuario mediante una interfaz gráfica. Desde allí, el usuario puede seleccionar una ubicación (por mapa), una fecha específica y las variables meteorológicas de interés.
  • Backend en Node.js + Express, encargado de consumir la NASA POWER API para generar pronósticos a largo plazo basados en datos históricos, así como una API de pronóstico meteorológico en tiempo real (Open-Meteo API) para fechas próximas (hasta 10 días).
  • Base de datos SQLite, utilizada para almacenar la información de usuarios registrados y sus locaciones favoritas.
  • Sistema de caché con Redis, implementado para optimizar la performance del backend. Redis permite almacenar temporalmente los resultados de los pronósticos generados (tanto los calculados a partir de los datos de la NASA como los obtenidos desde la API de pronóstico real), de modo que, si se vuelve a solicitar un forecast previamente calculado, el sistema puede responder de forma inmediata sin necesidad de repetir las operaciones de cálculo o las consultas externas a las APIs. Esto reduce significativamente los tiempos de respuesta y la carga sobre los servicios externos.

El prototipo incluye un sistema de autenticación mediante JSON Web Tokens (JWT) que protege las rutas relacionadas con la gestión de locaciones favoritas. Los usuarios autenticados pueden crear, eliminar y consultar sus locaciones, así como obtener el pronóstico de siete días para cualquiera de ellas.

Además, se incorporó la funcionalidad para descargar los resultados en formato JSON o CSV, permitiendo la reutilización o análisis externo de los datos generados.

El núcleo del procesamiento estadístico implementa un algoritmo de forecasting probabilístico basado en análisis de series históricas. Este modelo, en lugar de intentar predecir valores exactos, estima probabilidades y rangos de confianza para distintas condiciones climáticas, calculadas a partir de promedios y desviaciones estándar.

Si bien el sistema aún no integra modelos predictivos avanzados ni visualizaciones con funcionalidades altamente desarrolladas pensando en el 100% de las heurísticas de usabilidad, el prototipo desarrollado representa adecuadamente la esencia de la solución final, al demostrar la viabilidad técnica del flujo completo de autenticación, obtención, procesamiento, cacheo, exportación y visualización de datos.

Se considera, por tanto, que el alcance alcanzado resulta representativo y oportuno para el objetivo y contexto académico del proyecto, ya que valida la arquitectura propuesta, prueba la integración con fuentes oficiales de información y sienta las bases para una futura versión ampliada y de producción del sistema.

Diseño del prototipo

1. Diagrama de componentes

El sistema se compone de cinco elementos principales: un frontend web desarrollado en React, un backend en Node.js con Express encargado de la lógica de negocio, una base de datos SQLite para la persistencia de usuarios y locaciones, un sistema de cacheo Redis para acelerar respuestas de pronóstico, y dos fuentes de datos externas (NASA POWER API y una API de pronóstico meteorológico real).

El flujo general consiste en que el usuario interactúa con el frontend, que envía solicitudes al backend. Éste procesa la información, consulta las fuentes necesarias, almacena resultados en la caché o la base de datos y devuelve la respuesta al cliente (este flujo será representado de manera más detallada en la sección de diagramas de arquitectura).

2. Análisis de alternativas y justificación de diseño

Durante la construcción del prototipo se evaluaron diferentes alternativas tecnológicas para cada uno de los componentes de la arquitectura. La selección final respondió principalmente a la familiaridad del equipo con las herramientas, la simplicidad de implementación, la portabilidad del sistema y la necesidad de cumplir con los tiempos acotados tanto del hackathon NASA Space Apps Challenge como del reto académico posterior en la UCU.

A continuación, se detallan las decisiones adoptadas y su justificación:

  • Backend: Node.js + Express

Se optó por Node.js junto con el framework Express debido a la experiencia previa del equipo con este entorno, su baja curva de aprendizaje y la facilidad para construir APIs REST de forma rápida y modular.
Alternativas como Django (Python) o Spring Boot (Java) fueron descartadas por requerir una configuración más extensa y un mayor tiempo de desarrollo inicial, lo cual resultaba poco viable en el contexto del desafío.
La elección permitió un desarrollo ágil, compatibilidad con una gran cantidad de librerías y un entorno de ejecución eficiente en términos de concurrencia.

  • Frontend: React + Vite

Para la capa de presentación se seleccionó React junto con Vite como herramienta de build. La decisión se basó en la familiaridad del grupo con React y en las ventajas de Vite en tiempos de compilación y recarga, lo que permitió un flujo de trabajo fluido durante el desarrollo.
Otras alternativas consideradas de forma superficial fueron Vue.js y Angular, pero se priorizó React por su ecosistema maduro, su enfoque declarativo y la rapidez de desarrollo que ofrecía dada la experiencia previa del equipo (justamente habiendo trabajado con estas tecnologías en la asignatura DWYM).

  • Base de datos: SQLite

La base de datos elegida fue SQLite, fundamentalmente por su simplicidad, portabilidad y bajo costo de configuración.
En comparación con sistemas como PostgreSQL o MySQL, SQLite resultó más adecuada para un prototipo que debía ejecutarse fácilmente en entornos locales o de demostración, sin requerir un servidor de base de datos dedicado.
Además, la familiaridad del equipo con esta herramienta permitió implementar la persistencia de datos (usuarios y locaciones favoritas) de manera rápida y confiable.

  • Cache: Redis

Se incorporó Redis como sistema de caché para almacenar temporalmente los resultados de pronósticos, tanto históricos como de corto plazo.
Esta decisión se tomó por su simplicidad de uso, rendimiento en operaciones en memoria y porque es una de las herramientas más reconocidas para este tipo de tareas.
Si bien se consideraron alternativas como la implementación de caché en memoria dentro del propio backend, Redis ofrecía mayor escalabilidad y flexibilidad, permitiendo evitar llamadas repetitivas a las APIs externas y reduciendo significativamente los tiempos de respuesta.

  • Fuentes de datos externas

Se emplearon dos APIs externas:

  • NASA POWER API, seleccionada entre las fuentes sugeridas por los facilitadores del evento, por ofrecer datos climáticos históricos más completos, centralizados y relevantes para los objetivos del proyecto. Otras APIs evaluadas carecían de variables clave o presentaban una documentación menos accesible.
  • Open-Meteo API, utilizada para obtener pronósticos reales a corto plazo (hasta 10 días). La elección fue principalmente pragmática: se trató de la primera API de forecast que se ajustó a los requerimientos del proyecto y permitió una integración rápida y sin necesidad de autenticación o claves de acceso.

En conjunto, las decisiones tomadas reflejan un enfoque orientado a la eficiencia, la simplicidad y la ejecución rápida, priorizando herramientas que el equipo ya dominaba para garantizar la viabilidad del prototipo dentro de los plazos del desafío.

3. Diagramas de arquitectura

Incompleto.

Próximos pasos

En caso de continuar con el desarrollo del proyecto, los siguientes pasos se orientarían a profundizar el modelo de pronóstico, optimizar y mejorar la experiencia de usuario y preparar la aplicación para un entorno de producción.

Los principales aspectos a abordar serían los siguientes:

  1. Mejora del algoritmo de forecasting
    Actualmente el modelo se basa en un análisis estadístico simple de datos históricos. Un siguiente paso sería incorporar modelos de predicción más avanzados, combinando técnicas de machine learning o modelos híbridos de regresión y climatología.
    Si bien las predicciones de largo plazo tienen limitaciones físicas, estas mejoras permitirían aumentar la precisión en rangos de días o semanas, además de ofrecer análisis probabilísticos más robustos.
  2. Ampliación de fuentes de datos
    Integrar otras fuentes oficiales como NOAA (National Oceanic and Atmospheric Administration), Copernicus Climate Data Store, o OpenWeatherMap, permitiría disponer de datos complementarios para validar y mejorar los cálculos del modelo.
  3. Mejoras en visualización y usabilidad
    Incorporar gráficos interactivos, mapas de calor o líneas de tiempo para visualizar tendencias climáticas.
    Además, optimizar la interfaz para dispositivos móviles y mejorar la accesibilidad general del sitio.
  4. Persistencia y escalabilidad
    Migrar la base de datos de SQLite a PostgreSQL o MongoDB (dependiendo del análisis sobre qué tipo de bd se necesita), permitiendo manejar un mayor volumen de usuarios y consultas.
    En la misma línea, desplegar el sistema en un entorno en la nube (por ejemplo, AWS o Azure) para trabajar en la mejoría en el marco de los atributos de calidad de disponibilidad, rendimiento y/o seguridad.
  5. Autenticación y seguridad
    Implementar un sistema de registro más robusto, con recuperación de contraseñas, cifrado de datos sensibles y validación de tokens en múltiples niveles.
    Además,     contemplar un control de uso para evitar abuso de la API (probablemente rate limiting).

Conclusiones

Incompleto.

Referencias