Desarrollador explora alternativas a los backends en la nube centralizados para la propiedad de los datos del usuario

En una reflexión reciente publicada el 26 de octubre de 2026, el desarrollador Brandon expone los importantes desafíos arquitectónicos que conlleva crear aplicaciones web que prioricen la propiedad de los datos por parte del usuario. El autor describe un intento de construir Cheapskate, una herramienta de seguimiento financiero, sin depender de proveedores centralizados de backend-as-a-service como Supabase. La tensión principal identificada radica en ofrecer una funcionalidad fluida entre dispositivos y garantizar que los datos personales sensibles permanezcan exclusivamente bajo el control del usuario, en lugar de almacenarse en los servidores de un proveedor.

Qué ocurrió

El autor comenzó a desarrollar Cheapskate con la intención de evitar la práctica estándar de delegar la autenticación y la gestión de bases de datos a servicios de terceros. Aunque reconoce la comodidad de herramientas como Supabase para manejar infraestructuras básicas, el desarrollador argumentó que este modelo es fundamentalmente defectuoso para aplicaciones que manejan información financiera sensible. La pregunta central planteada fue si es posible ofrecer el mismo nivel de durabilidad, sincronización entre dispositivos y capacidades de compartición que se encuentran en las stacks modernas de la nube, manteniendo los datos locales al usuario.

Para responder a esto, el desarrollador evaluó sistemáticamente varios enfoques técnicos que afirman apoyar modelos de datos local-first o de propiedad del usuario. Cada opción se probó contra criterios específicos: facilidad de implementación, accesibilidad entre dispositivos, capacidades de compartición y soporte de navegador. La investigación reveló que la mayoría de las soluciones existentes obligan a hacer compromisos, ya sea bloqueando a los usuarios en ecosistemas específicos, careciendo de funciones maduras de colaboración o requiriendo conocimientos técnicos muy superiores a los que poseen los usuarios finales típicos. La conclusión fue que ninguna solución actual lista para usar reemplaza adecuadamente la conveniencia de las bases de datos SQL centralizadas para este caso de uso específico.

Detalles clave

• localStorage: Descartado porque no admite el acceso a datos desde múltiples dispositivos ni permite compartirlos con otros usuarios.
• showDirectoryPicker: Rechazado debido al soporte incompleto en navegadores y a la necesidad de servicios externos como Dropbox para gestionar el intercambio de archivos.
• CloudKit Private Database: Descartado porque requiere inicio de sesión único de Apple, una suscripción de pago para desarrolladores y carece de soporte de librerías JavaScript para compartir datos.
• SQLite en Google Drive: Se encontró que su configuración es técnicamente miserable tanto para desarrolladores como para usuarios, además de imponer la dependencia de una cuenta de Google.
• Bring-your-own DynamoDB: Considerado funcional pero poco práctico, ya que pedir a los usuarios que gestionen claves de AWS para iniciar sesión es irrazonable.
• remoteStorage y CRDTs: Identificados como conceptos prometedores, pero actualmente carecen de herramientas maduras para la colaboración y garantías claras de privacidad.

Contexto

Las plataformas Backend-as-a-Service (BaaS) como Supabase se han convertido en un estándar en el desarrollo web moderno porque abstraen tareas complejas de infraestructura. Proporcionan autenticación gestionada, bases de datos en tiempo real y almacenamiento, permitiendo a los desarrolladores centrarse en la lógica frontend. Sin embargo, esta comodidad tiene un coste: el proveedor del servicio aloja y controla los datos subyacentes. Para aplicaciones que manejan datos no sensibles, esto rara vez es un problema. Para aplicaciones financieras o relacionadas con la salud, algunos desarrolladores y usuarios prefieren un modelo donde los datos residan en dispositivos controlados por el individuo, a menudo denominado arquitectura "local-first" o de "propiedad del usuario".

El software local-first busca mantener los datos en el dispositivo del usuario, sincronizándolos solo cuando es necesario. Tecnologías como los Conflict-free Replicated Data Types (CRDTs) ayudan a gestionar la consistencia de los datos entre dispositivos sin que un servidor central actúe como única fuente de verdad. A pesar de los beneficios teóricos para la privacidad, el ecosistema para construir estas aplicaciones es menos maduro que los modelos tradicionales cliente-servidor. Los desarrolladores a menudo enfrentan herramientas fragmentadas, APIs de navegador inconsistentes y una falta de protocolos estandarizados para la colaboración segura entre pares.

Por qué importa

Para equipos que ejecutan software autoalojado o construyen productos para mercados conscientes de la privacidad, este análisis destaca una brecha crítica en el panorama actual de herramientas. Muchas organizaciones eligen el autoalojamiento para mantener el control sobre sus datos, pero aún dependen de arquitecturas centralizadas dentro de su propia infraestructura. La dificultad para implementar verdaderos modelos de datos de propiedad del usuario significa que incluso las aplicaciones centradas en la privacidad a menudo terminan almacenando datos en servidores de la empresa. Esto crea problemas de responsabilidad y confianza, ya que los usuarios deben creer que el operador protegerá sus datos, en lugar de tener garantías criptográficas o arquitectónicas de que ellos son los dueños.

La ausencia de un "Firebase para CRDTs" o de una API universal simple para consultas SQL controladas por el usuario obliga a los desarrolladores a tomar decisiones difíciles. Pueden optar por construir capas complejas de sincronización personalizadas, lo que aumenta la carga de mantenimiento y la superficie de errores, o aceptar los compromisos de privacidad del almacenamiento centralizado. Para empresas pequeñas y medianas, esto significa que ofrecer verdadera soberanía de datos a los clientes es actualmente más costoso y técnicamente arriesgado que utilizar proveedores de nube estándar. Hasta que las herramientas maduren, las funciones centradas en la privacidad pueden seguir siendo una capacidad de nicho en lugar de una oferta estándar.

Qué puedes hacer

• Evalúa si tu aplicación realmente requiere sincronización en tiempo real entre dispositivos antes de comprometerte con arquitecturas complejas de local-first.
• Si usas almacenamiento centralizado, implementa políticas estrictas de retención de datos y mecanismos claros de consentimiento del usuario para mitigar los riesgos de privacidad.
• Monitorea el desarrollo de librerías remoteStorage y CRDT, ya que estos ecosistemas están evolucionando rápidamente y podrían ofrecer soluciones viables pronto.
• Considera modelos híbridos donde los datos sensibles se cifran en el lado del cliente antes de ser almacenados en tus servidores, dando al usuario el control de las claves.
• Documenta tu arquitectura de datos de forma transparente para los usuarios, explicando dónde residen los datos y quién tiene acceso a ellos.
• Participa en comunidades de código abierto que trabajan en protocolos local-first para compartir comentarios y acelerar la madurez de las herramientas.