No se trata de lo que quieres comprar, sino de quién quieres ser. Invierte en tu educación con el precio especial

Antes: $249

Currency
$209

Paga en 4 cuotas sin intereses

Paga en 4 cuotas sin intereses
Suscríbete

Termina en:

11 Días
23 Hrs
20 Min
10 Seg

Cómo hacer aplicaciones en tiempo real

1/26
Recursos

Aportes 19

Preguntas 1

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

En Platzi no hay cursos avanzados…

Si claro…

Que buen curso, cuantos cursos por hacer D:

El profesor: “No trates de leer mis mensajes, ese no es mi WhatsApp”

Yo: “¡Maldición!”

Estaba esperando este curso desde que lo anunciaron

Introducción

Una aplicación en tiempo real es aquella que permite mantener dos o más clientes conectados y que a su vez les informa sobre cambios en las páginas sin necesidad de que estas lo soliciten de manera explícita.

💡 En pocas palabras, en estas aplicaciones, tanto el cliente cómo el servidor pueden mandar información cuando sea necesario.

En la actualidad, vivimos rodeados de este tipo de aplicaciones. Por ejemplo, desde las aplicaciones de mensajería (como WhatsApp, Signal, Telegram, etc). hasta las redes sociales (como el feed Facebook, Twitter, Instagram, etc.) o aplicaciones de deliverys, son aplicaciones en tiempo real.

Es aquí donde el modelo tradicional se nos queda corto, haciendo difícil el desarrollo de aplicaciones en tiempo real, ya que en dicho modelo el cliente debe enviar una solicitud para que el servidor pueda responder.

💡 Es decir, no importa si el servidor tiene nueva información, esta no se verá reflejada en el navegador si este no la solicita y el navegador nunca sabrá cuándo solicitarla.

En parte, esto se debe a que el protocolo HTTP está diseñado especialmente para aplicaciones del tipo cliente-servidor (dónde lo “común” es mandar peticiones al servidor y recibir una respuesta de este) y no para aplicaciones en tiempo real.

Para resolver esta problemática, surgió el modelo Comet, que permitía simular aplicaciones en tiempo real, usando una solicitud HTTP de larga duración (HTTP Long-Polling Request).

Esto consistía básicamente en que el cliente iniciaba una solicitud, la cual se mantenía abierta por mucho tiempo, para que el servidor pueda responder en cuanto tenga nueva información, pero sin finalizar la respuesta.

💡 Comet también era conocido como “Ajas push” y fue usado por Gmail en sus inicios.

Esto era ineficiente, por ello, surge el protocolo Websockets, el cual, proporciona un canal bidireccional y full-duplex que permite tener varios puntos finales (o sockets) conectados al mismo tiempo.

Gracias a esto, los sockets pueden enviar datos a los demás (sin que estos los pidan), permitiendo tener una comunicación en tiempo real. Son más eficientes cuando necesitamos tener actualizaciones continuas, pues no se requiere enviar solicitudes para obtener una respuesta.

💡 Los sockets permiten que múltiples aplicaciones cliente se actualicen de forma “automática” siempre que hayan nuevos datos del servidor.

Se ve genial el curso…

El nuevo curso de Programación Básica tiene como proyecto hacer un video juego, para lo cual se usan cientos de peticiones http. Considero que, quien quiera optimizar ese video juego, debe si o si tomar este curso

**¿QUÉ ES UNA APLICACIÓN EN TIEMPO REAL?** *Una **aplicación** en **tiempo real** es un **sistema** de **software** **diseñado** para **procesar** y **transmitir datos instantáneamente entre** el **servidor** y el **cliente**, **garantizando** una **interacción** **continua** y **sin demoras perceptibles**. **Utiliza** **tecnologías** para **mantener** una **comunicación bidireccional persistente**, permitiendo la **actualización** **dinámica** de la **interfaz** de **usuario** en **respuesta** a **eventos** del **servidor** o de **otros** **clientes**. Esto es **esencial** en **aplicaciones** **donde** la **inmediatez** y la **sincronización** son **críticas**, como en:* * **chats** * **videojuegos multijugador** * **sistemas de monitoreo en vivo** * **plataformas de colaboración en tiempo real** * **Redes sociales** **¿CUÁL ES EL PROBLEMA?** *El **problema** es que en el **modelo** **tradicional*** **cliente-servidor** ***solo** se puede **actualizar** la **página** **únicamente** **si** el **cliente** lo **pide**, es decir, **no** **importa** **si** el **servidor** tiene una **nueva** **información**, este **no** podrá **mostrarla** **si** el **navegador** **no** lo **pide**. Esto **dificulta** el **desarrollo** de **aplicaciones** en **tiempo** **real**, pues **no** se **sabe** **cuándo** el **servidor** tendrá **información** **nueva** para **pedirla**.* *En parte, esto se debe a que el **protocolo*** **HTTP** *no está **especialmente** **diseñado** para este **tipo** de **aplicaciones**. Este **protocolo** es **usado** en **aplicaciones** que **usan** el **modelo** **tradicional*** **cliente-servidor***, ya que lo **común** es **mandar** un **request** y **recibir** un **response**.* **COMET** *Una de las **formas** mediante las cuales se podía **simular** **aplicaciones** en **tiempo** **real** con el **protocolo*** **HTTP** *era **usando** un **modelo** **llamado** “Comet” **también** era **conocido** como “Ajax Push”. Este **modelo** fue **utilizado** por* **Gmail** *en sus **inicios**.* **Comet** ***usa** una **solicitud*** **HTTP** *de **larga** **duración*** (Long-Polling Request)*. **Básicamente**, el **cliente** **inicia** una **solicitud** que se **mantiene** **abierta** por mucho **tiempo** para que el **servidor** pueda **responder** **datos** en **cuento** **tenga** **nueva** **información**, pero este **no** **finalizará** la **respuesta**.* **PROTOCOLO WEBSOCKET** *El **protocolo*** **WebSocket** *es una **tecnología** de **comunicación** que permite una **conexión** **bidireccional** y **persistente** **entre** un **cliente** y un **servidor**. A **diferencia** de los **protocolos** **tradicionales** como* **HTTP***, que **siguen** un **modelo** de* **petición-respuesta***,* **WebSocket** ***establece** una **única** **conexión** que permanece **abierta**, permitiendo el **intercambio** **continuo** de **datos** en **tiempo** **real** con **baja** **latencia**.*

Iniciando este curso, suena muy interesante, ya había escuchado al respecto pero no me había dado el tiempo de aprenderla, vamos a darle a este curso, el instructor es muy bueno, así que nunca pares de aprender!!!

Lo explicarán más adelante, pero igual quiero comentar que, un socket no envía información directamente a otros sockets, sino que se la envía al servidor. El servidor procesa la información enviada, y actualiza a todos los demás sockets que estén conectados al servidor por este protocolo. Obviamente hay que cubrir un montón más. Pero quise dejar eso claro por esta clase.

Nunca había esperado tanto un curso como este jajaaja, el semestre pasado en la universidad no pude entender este tema y tengo la esperanza de que con este curso por fin podre comprenderlo.

jajajajaj este profesor me sacó la risa con su is de enseñar, muy cool.
Aww~ Je je je, mi momento favorito de la clase introductoria ❤️~ Ahora sí que sí a hacer aplicaciones en tiempo real 🔥.
En 2024... quien me ayuada en angular?

Empezando este curso, estoy seguro que será muy genial, la introducción me encantó!

Excelente! :3 a seguir aprendiendo

Deseando terminar el curso para pasar una side project que actualmente “simula” tiempo real con recargas automáticas en cortos periodos de tiempo a websocket 😃


Solo he visto la introducción y no creo parar de aprender! Vamos con toda. Gracias profe

Ooooh estaba esperando este curso 😄
"efisiente, eficas, eferbesente"…
en ECDQEMSD dicen “rápido, económico y audaz”, que vendría siendo lo mismo ~

No nos dejen solo con lo básico, también es necesario cursos avanzados. Sino los que vienen con conocimientos más que básicos buscan también temas avanzados.
Recuerden que los estudiantes de platzi de las primeras generaciones también buscan cursos más avanzados.
Pero un crack de cómo enseñas.