≡En resumen
- En pull el cliente pregunta y el servidor responde; en push el servidor envía sin que se lo pidan.
- Técnicamente se implementa con consultas al abrir, sondeo cada cierto tiempo o long polling.
- Es sencillo y no requiere permisos de notificación, pero la información no llega en tiempo real.
- En marketing, pull es el contenido que el usuario busca por sí mismo: bandejas, feeds, RSS, buscadores.
- La mayoría de productos combinan ambos: push para avisar y pull para consultar el detalle.
01 ¿Qué son las notificaciones pull?
Pull significa «tirar» en inglés: el cliente «tira» de la información. Es el modelo más antiguo de la web (el navegador pide una página y el servidor la devuelve) y la base de la arquitectura cliente-servidor mediante APIs. Su contrario son las notificaciones push, que el servidor envía al dispositivo aunque el usuario no esté usando la app; allí explicamos permisos, web push y buenas prácticas de envío.
| Aspecto | Pull | Push |
|---|---|---|
| Quién inicia | El cliente (usuario o app) | El servidor |
| Tiempo real | No; depende de cuándo se consulte | Sí, casi inmediato |
| Permiso de notificaciones | No hace falta | Obligatorio en móviles y navegadores |
| Intrusión | Baja: el usuario decide cuándo mira | Alta si se abusa |
| Complejidad técnica | Baja | Media: tokens, servicios de push, segmentación |
| Coste de recursos | Alto si se sondea muy a menudo sin novedades | Eficiente: solo se envía cuando hay algo |
02 Cómo funciona el modelo pull técnicamente
Hay varias formas de implementar el pull, de más simple a más cercana al tiempo real. La elección depende de cada cuánto cambian los datos y de cuánto importa enterarse al instante.
| Técnica | Cómo funciona | Cuándo usarla |
|---|---|---|
| Consulta al abrir o refrescar | La app pide novedades al arrancar o al deslizar hacia abajo | Feeds, bandejas, datos que no son urgentes |
| Sondeo (polling) | El cliente pregunta cada X segundos o minutos | Estados que cambian con cierta frecuencia; prototipos |
| Long polling | El servidor mantiene la petición abierta hasta que hay novedad o vence el tiempo | Casi tiempo real sin infraestructura especial |
| Server-Sent Events (SSE) | El servidor envía eventos por una conexión HTTP abierta, en un solo sentido | Paneles en directo, progreso de tareas (modelo push sobre la web) |
| WebSockets | Canal bidireccional permanente | Chats y colaboración en tiempo real (modelo push) |
| Webhooks | Un servidor avisa a otro con una petición HTTP cuando ocurre algo | Integraciones entre sistemas (push entre servidores) |
Para profundizar en la arquitectura de apps, la revista Software Guru publicó un análisis sobre cómo es la arquitectura pull y push en aplicaciones móviles.
03 Ejemplos de notificaciones pull
Deslizar para actualizar
El gesto de arrastrar hacia abajo para cargar novedades lo creó Loren Brichter para la app Tweetie 2 y hoy lo usan casi todos los feeds. Es pull en estado puro.
Bandeja de notificaciones in-app
La campana con el contador: los avisos se guardan en el servidor y la app los descarga al abrirla.
Correo electrónico
Tu cliente de correo consulta el buzón (IMAP o POP3) para ver si hay mensajes nuevos.
Lectores RSS
El lector consulta periódicamente el feed de cada web; el elemento ttl del RSS indica cuántos minutos puede guardarse en caché.
Consulta de estado
Entrar en la web de una mensajería para ver dónde está tu paquete, en lugar de recibir un aviso.
Una app de gestión de incidencias envía una push breve («Nueva incidencia asignada»). Al tocarla, la app hace pull: pide al servidor el detalle completo, los comentarios y los adjuntos. Así la push lleva poca información (y ningún dato sensible en la pantalla de bloqueo) y el contenido siempre está actualizado.
04 Pull en marketing: contenido que el usuario va a buscar
En marketing, la lógica pull equivale a atraer en lugar de interrumpir: el usuario llega porque busca algo (en Google, en tu blog, en su bandeja de entrada, en un feed al que se ha suscrito). Es la base del marketing de atracción, mientras que los anuncios intrusivos o las push promocionales pertenecen a la lógica push.
| Canal | Lógica | Por qué |
|---|---|---|
| SEO y blog | Pull | El usuario busca y encuentra tu contenido |
| Newsletter | Mixta | Llega a la bandeja (push), pero el usuario decide cuándo leerla y se suscribió antes |
| RSS y podcasts | Pull | El usuario se suscribe y su lector consulta las novedades |
| Bandeja in-app | Pull | Los avisos esperan a que el usuario abra la app |
| Notificación push promocional | Push | Interrumpe al usuario en el momento que elige la marca |
| Anuncios display | Push | Aparecen sin que el usuario los haya buscado |
05 Ventajas y desventajas del modelo pull
Ventaja: control del usuario
No interrumpe: la información espera a que la persona quiera verla.
Ventaja: sin permisos
No depende de que el usuario acepte notificaciones ni del servicio de push de cada plataforma.
Ventaja: simplicidad
Una API que responde peticiones; fácil de cachear, escalar y depurar.
Desventaja: retraso
Si el usuario no abre la app, no se entera. No sirve para avisos urgentes.
Desventaja: peticiones inútiles
El sondeo frecuente consume batería, datos y servidor aunque no haya novedades.
En la práctica, el pull es la opción por defecto para todo lo que no es urgente, porque es más barato de construir y de mantener. Se añade push solo donde un retraso tiene un coste real para el usuario, como un pago no reconocido o una cita que empieza en una hora, y se evita el sondeo frecuente cuando la app está en segundo plano, porque los sistemas operativos móviles limitan cada vez más la actividad de las apps que no están en pantalla.
06 Cuándo usar pull, push o ambos en tu app o web
- ✓Usa pull para contenido que el usuario consulta a su ritmo: feeds, historial, catálogos, informes.
- ✓Usa push para lo urgente o esperado: pagos, mensajes, cambios de estado de un pedido o una cita.
- ✓Combina ambos: una push corta que lleva a una pantalla que carga el detalle por pull.
- ✓Si necesitas tiempo real dentro de la app abierta, WebSockets o SSE en lugar de sondeo agresivo.
- ✓Mide las peticiones que devuelven «sin cambios» para ajustar la frecuencia de consulta.
La decisión entre pull y push afecta a la arquitectura, al consumo de batería y a la experiencia del usuario, así que conviene tomarla al diseñar la aplicación. Nuestro equipo de desarrollo de aplicaciones web la plantea desde el primer prototipo, y si el proyecto incluye app para iOS y Android, lo hace junto a una empresa de desarrollo de aplicaciones que conozca los servicios de push de cada plataforma.
Preguntas frecuentes sobre Notificaciones pull
Son actualizaciones que el usuario recibe porque las pide: al abrir la app, refrescar, consultar una bandeja o un feed. El servidor no las envía por iniciativa propia.
En pull el cliente pregunta y el servidor responde. En push el servidor envía la información en cuanto ocurre algo, sin que se la pidan.
Es una técnica pull en la que el cliente pregunta al servidor cada cierto intervalo si hay novedades. Es simple, pero genera muchas peticiones vacías si la frecuencia es alta.
Es pull: el lector RSS consulta periódicamente el feed de cada web para ver si hay entradas nuevas.
No. Como la información se muestra dentro de la app o la web cuando el usuario la abre, no hace falta el permiso de notificaciones del sistema.
Es la estrategia de atraer al cliente con contenido que busca por sí mismo, como SEO, blog o redes, en lugar de interrumpirle con anuncios o mensajes no solicitados.
Ninguno es mejor en general. Push conviene para avisos urgentes o esperados; pull, para contenido que el usuario consulta a su ritmo. La mayoría de apps combinan los dos.
Es una variante del sondeo en la que el servidor mantiene abierta la petición del cliente hasta que tiene una novedad o vence un tiempo límite. Reduce las respuestas vacías y se acerca al tiempo real.
Fuentes consultadas
Sobre el autor
Germán Gutiérrez
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil en LinkedIn ↗