¿Y si serverless significara no tener servidores de backend?

Artículo original ↗ Discusión en Hacker News ↗

Una publicación de blog que propone aplicaciones web “serverfree”, donde toda la lógica y los datos viven por completo en el dispositivo del usuario, provoca comparaciones con el software clásico de escritorio, los paquetes estilo Electron y el movimiento más amplio “local-first”. Los comentaristas sopesan el atractivo de la privacidad, la capacidad sin conexión y una facturación más simple frente a problemas prácticos como la sincronización entre dispositivos, las copias de seguridad, la resolución de conflictos y las actualizaciones, y a menudo concluyen que todavía se necesita alguna forma de sincronización opcional en la nube o entre pares. Muchos también critican la etiqueta “serverfree” por confusa, señalando que el alojamiento estático sigue siendo necesario y que ideas similares se han explorado durante años bajo otros nombres.

Alcance de “serverless” / “serverfree”

  • Muchos leen “serverless” como abreviatura de facturación por invocación, al estilo de Lambda; algunos sostienen que esto no es más que hosting compartido rebautizado.
  • Varios no gustan de “serverfree” como término porque un host estático sigue siendo un servidor y los “servidores” lógicos de app/base de datos siguen existiendo, solo que trasladados al lado del cliente.
  • Algunos prefieren “local-first” como algo más claro: primero el dispositivo, servidor opcional, frente a “offline-first” o “serverfree”, que suenan más limitantes.

“¿No es esto solo una app de escritorio / Electron?”

  • Varios comentarios dicen que la propuesta recrea en gran medida las apps de escritorio, o el empaquetado estilo Electron, pero mediante navegador + SQLite en WASM.
  • Los críticos señalan que hemos dado la vuelta para volver a stacks pesados y más lentos con el fin de recuperar capacidades que las apps de escritorio ya tenían.
  • Quienes apoyan responden que la distribución web (“ve a esta URL, sin instalación, sin tienda de apps, sin firma de código”) es una gran ventaja práctica.

Almacenamiento de datos, copia de seguridad y sincronización

  • Modelo central: los datos viven por completo en el dispositivo local (por ejemplo, SQLite del navegador + OPFS).
  • Preocupaciones:
    • No hay sincronización integrada entre dispositivos; los usuarios a menudo dependen de 3–4 dispositivos y esperan compartir sin fricción.
    • Riesgo de pérdida de datos por fallo o robo del dispositivo; la exportación/importación manual se ve como un “callejón sin salida de usabilidad”.
  • Mitigaciones sugeridas:
    • Usar almacenamiento genérico en la nube (Dropbox/Nextcloud/iCloud/etc.) para sincronizar archivos locales, opcionalmente cifrados.
    • Sincronización cifrada opcional hacia un servidor central, o sincronización entre pares (WebRTC, Bluetooth, LAN, protocolos P2P).
    • Distinguir entre almacenamiento “tonto” y lógica de resolución de conflictos específica de la aplicación.

Tecnologías local-first / de sincronización

  • La idea se alinea con el “local-first software”: almacenamiento primario en el dispositivo, sincronización como complemento.
  • Los comentaristas mencionan herramientas emergentes (por ejemplo, sistemas basados en CRDT, capas de sincronización para SQLite, protocolos de sincronización alternativos) y mantienen listas comparativas.
  • Hay interés en una sincronización genérica a nivel de sistema operativo, pero también se reconoce que la resolución de conflictos suele ser específica de la aplicación y compleja.

Preguntas de implementación

  • Se plantean dudas sobre:
    • Cómo se compara SQLite+WASM+OPFS con localStorage en rendimiento y durabilidad.
    • La sobrecarga y el beneficio de usar un worker que emule HTTP hacia una base de datos local frente al acceso directo a la BD.
    • Migraciones de esquema y cambios rompientes en una BD puramente del lado del cliente.
    • La practicidad de evitar cualquier backend cuando intervienen claves API o servicios de terceros.

Sentimiento general

  • Muchos encuentran el experimento intelectualmente interesante y alineado con objetivos de privacidad/control local.
  • Persiste un escepticismo importante sobre la terminología, la falta de sincronización/copia de seguridad, la robustez operativa y si esto realmente mejora a las apps de escritorio bien diseñadas o a las apps híbridas local+cloud.