¿Qué es una PWA (Progressive Web App)?

Una PWA es una app web que usa service workers, un manifest y HTTPS para ser instalable, funcionar offline y recibir notificaciones push. Acuñado por Alex Russell y Frances Berriman en 2015, el término cierra la brecha entre un sitio web y una app instalada sin salir de la web: una sola base de código, un ícono en la pantalla de inicio, una ventana propia y una pantalla que sigue funcionando cuando el tren entra al túnel. El ángulo que este glosario agrega — y que las guías de frontend se saltan: una PWA sigue siendo un cliente — el service worker cachea, pero tu backend es la fuente de la verdad.

Puntos clave

Los tres pilares, y el backend detrás de ellos

// JavaScript — the PWA's three pillars + the backend behind them
// 1 · Service worker: caches the shell, buffers writes when offline
navigator.serviceWorker.register('/sw.js');

// 2 · Manifest (public/manifest.json) makes it installable:
//    { "name": "Notes", "display": "standalone", "start_url": "/", "icons": [...] }

// 3 · HTTPS is required — service workers refuse to run otherwise.

// The catch: the SW cache is a MIRROR, not the source of truth.
// When back online, queued writes sync to the real backend:
const note = new Parse.Object('Note').set('text', draft);
await note.save(); // the BaaS is authoritative; the cache was a buffer

// Flutter / Dart — Back4app Flutter SDK (Flutter web compiles to a PWA)
// The service worker caches the app shell; data still lives on the backend.
final note = ParseObject('Note')..set('text', draft);
await note.save();
// Offline-first pattern: write locally, queue, and sync when connectivity
// returns — the API/BaaS is the source of truth, the cache is a local mirror.
// Push notifications need a BACKEND to send them; the client only subscribes.

// Swift — a native shell can host a PWA/WebView; the backend is shared
// The point of parity: whatever the client (PWA, native, web), the
// source of truth is the same backend API.
var note = Note()
note.text = draft
_ = try await note.save()
// Offline-first: cache locally, sync when online — the API is authoritative.
// Web push (PWA) and native push (APNs) both need a backend to SEND them.

// Kotlin — a native shell can host a PWA/WebView; the backend is shared
// The point of parity: whatever the client (PWA, native, web), the
// source of truth is the same backend API.
val note = ParseObject("Note")
note.put("text", draft)
note.save()
// Offline-first: cache locally, sync when online — the API is authoritative.
// Web push (PWA) and native push (APNs/FCM) both need a backend to SEND them.

Un service worker es un script en segundo plano que se ubica entre la app y la red como un proxy — cachea el shell y lo sirve offline; un web app manifest es el archivo de metadatos JSON (nombre, íconos, display: standalone, URL de inicio) que hace la app instalable; y HTTPS es obligatorio, porque los service workers se niegan a correr fuera de un contexto seguro. Esos tres construyen el frente de la app. El save() en las pestañas de código muestra lo que queda detrás: el caché es un espejo, y cuando la red vuelve, la escritura se sincroniza con el backend autoritativo.

Cómo una PWA sirve una página offline

Estrategias de caché offline

La decisión es por recurso, no por app: el shell de la app quiere cache-first para cargar al instante; los datos vivos del usuario quieren network-first para frescura; un feed acepta stale-while-revalidate para sentirse instantáneo y corregirse solo. Elijas lo que elijas, el caché es un buffer de lectura/escritura sobre la API — las escrituras offline se encolan localmente y se reconcilian al reconectar, la misma disciplina de puesta al día que necesita cualquier cliente offline-first.

De dónde vienen realmente las notificaciones push

El mecanismo que casi ningún glosario explica, y la razón por la que una PWA necesita un backend hasta para notificar. El cliente solo se suscribe: pide permiso y recibe un endpoint de suscripción. Enviar es trabajo del servidor — tu backend → el servicio de push del navegador → el evento push del service worker → una notificación mostrada. El service worker puede despertar para mostrarla con la app cerrada, pero nada llega si un backend no lo envió — por eso “las PWA tienen push” es solo la mitad de una funcionalidad sin la mitad del servidor. La entrada de notificaciones push cubre la cadena de entrega; el punto aquí es que tanto el web push como el push nativo terminan en tu código decidiendo enviar.

PWA vs. app nativa

La asimetría honesta vive en la última fila: iOS es donde las PWA son más débiles — instalación solo a través de Safari, sin prompt de instalación automático, push solo con la app instalada y solo en versiones recientes, y sincronización en segundo plano incompleta. En Android y desktop la distancia con lo nativo es pequeña; en iOS es el factor decisivo para muchos productos.

Casos de uso comunes

• Contenido y comercio — alcance, SEO y baja fricción de instalación valen más que una descarga de tienda para llegar a usuarios nuevos.
• Herramientas internas — apps instalables y tolerantes al offline para usuarios conocidos, sin distribución por tienda.
• Apps de campo offline-first — captura datos sin señal, sincroniza cuando vuelve; el patrón del caché como buffer.
• Alcance multiplataforma con poco presupuesto — una base de código web cubriendo plataformas que un build nativo triplicaría.
• Compañera de una app nativa — el mismo backend sirviendo una PWA para alcance y una app nativa para profundidad.

¿Deberías construir una PWA? Matriz de decisión

Limitaciones y trade-offs

• iOS limita el techo. Instalación solo por Safari, push restringido y huecos en la sincronización en segundo plano hacen de iOS la restricción que más a menudo decide el duelo PWA-versus-nativo.
• El acceso al hardware es parcial. Bluetooth, NFC, contactos y APIs avanzadas de cámara están limitados o ausentes según el SO — las apps que se hunden en el dispositivo siguen pidiendo nativo.
• El caché no es la base de datos. Tratar el caché del service worker como fuente de la verdad invita escrituras perdidas y conflictos de datos viejos; es un buffer sobre el backend autoritativo.
• El push es mitad cliente, mitad servidor. Suscribirse es fácil; la PWA sigue necesitando un backend para enviar, así que “offline y push” es una funcionalidad de backend con credencial de frontend.
• La descubribilidad corta por ambos lados. Sin el peaje de la tienda tampoco hay vitrina de tienda; cambias curaduría y ceremonia de instalación por una URL.

PWAs en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Es la mitad backend de la funcionalidad que los pilares de frontend apenas completan: el service worker cachea el shell, pero Back4app es la fuente de la verdad que ese caché espeja — usuarios autenticados, datos sincronizados que reconcilian escrituras offline al reconectar, y el servidor que de verdad envía el web push al que una PWA solo puede suscribirse. Como un solo backend sirve por igual a una PWA, una app web común y una app nativa a través de SDKs por plataforma, el alcance multiplataforma que la PWA promete en el frontend se encuentra con el alcance escribe-una-vez del backend — el cliente cachea, la plataforma recuerda, y las dos mitades de “instalable, offline y push” por fin se juntan.