MiFibro es una aplicación para que una persona con fibromialgia registre cada día cómo se encuentra: dónde le duele, cuánto, cómo ha dormido, qué ha podido hacer. Con ese historial, una consulta médica deja de depender de la memoria y pasa a apoyarse en datos.
Cuando empecé di por hecho lo de siempre: una base de datos en la nube, autenticación
por correo, una tabla registros y a correr. Es lo que sé hacer y lo que
había hecho en otros proyectos. Tardé poco en darme cuenta de que estaba resolviendo el
problema equivocado.
El dato de salud no es un dato cualquiera
El RGPD llama a los datos de salud categoría especial. Traducido a consecuencias prácticas para alguien que desarrolla solo: hace falta una base jurídica más exigente, hay que informar con detalle de qué se guarda y dónde, y si algún día hay una brecha, quien responde soy yo.
Y hay algo que pesa más que lo legal. Estaba pidiendo a personas con una enfermedad crónica —una enfermedad que muchas veces ni siquiera les creen— que me confiaran el registro íntimo de su dolor. Cada fila de esa base de datos sería exactamente el tipo de información que nadie quiere que se filtre.
La pregunta dejó de ser «cómo protejo estos datos» y pasó a ser «¿de verdad necesito tenerlos?».
La respuesta era que no. La aplicación no necesita ver los datos de nadie para funcionar: guardar, mostrar la evolución, calcular el cuestionario FIQ o preparar un resumen para el médico son operaciones que se pueden hacer enteras en el dispositivo.
La arquitectura que salió de ahí
MiFibro es una aplicación web instalable que guarda todo en el propio navegador, con un service worker que cachea la app para que abra al instante y funcione sin conexión. No hay cuentas de usuario, no hay servidor de aplicación y no hay analítica que siga a nadie.
La parte que más cuidado exige es el guardado. Sin servidor no hay red de seguridad: si una escritura falla, falla del todo. Por eso todas pasan por una única función que versiona el esquema y nunca deja el almacenamiento a medias.
const CLAVE = 'mifibro:registros';
const VERSION_ESQUEMA = 3;
export function guardarRegistros(registros) {
try {
localStorage.setItem(CLAVE, JSON.stringify({ v: VERSION_ESQUEMA, registros }));
return { ok: true };
} catch (error) {
// Cuota llena o modo privado: hay que avisar, nunca fallar en silencio.
return { ok: false, motivo: error.name };
}
}
Ese return con el motivo del fallo no es un detalle. En una app sin
servidor, el peor escenario no es perder la base de datos: es que alguien crea que sus
registros están guardados cuando no lo están.
Lo que gané
- Privacidad por diseño. No puedo filtrar lo que no tengo.
- Coste de infraestructura cero. Es hosting estático: el proyecto puede vivir años sin depender de que yo pague una factura.
- Funciona sin conexión. Relevante cuando alguien anota su dolor a las tres de la mañana con mala cobertura.
- Velocidad. Ninguna operación espera a la red. Abrir y anotar es cuestión de segundos, que es justo lo que necesita alguien con dolor.
Lo que perdí, que también hay que contarlo
- No hay sincronización entre dispositivos. El historial vive donde se creó.
- Si se borran los datos del navegador, se pierde el historial. Es el riesgo real, y no tiene solución elegante sin servidor.
- No veo datos agregados. Ni métricas de uso ni estadísticas para mejorar el producto.
Los dos primeros los mitigué con una exportación del historial a fichero, explicada sin exigir saber qué es un JSON, y con avisos claros dentro de la app. El tercero lo asumí: prefiero decidir a ciegas antes que mirar los datos de salud de alguien.
Y si algún día hace falta la nube
La sincronización es la petición más repetida, y tiene una respuesta que no obliga a renunciar a nada: cifrar en el dispositivo antes de que nada salga de él. El servidor guarda un bloque ilegible y la clave nunca abandona el móvil. Es más trabajo y bastante más difícil de hacer bien, pero mantiene la propiedad que hace que la aplicación se pueda recomendar sin letra pequeña: yo tampoco puedo leerlo.
Lo que me llevo
Que la solución técnicamente más avanzada rara vez es la mejor solución de producto. Un backend habría quedado mejor en mi currículum, y peor en términos de responsabilidad. Elegir la arquitectura es también elegir qué riesgos le estás pidiendo a otra persona que asuma sin que se entere.
