CAPÍTULO 6 · Los datos empiezan a llegar
Una pantalla que sigue lo que está ocurriendo
Consultar un histórico es suficiente para analizar el pasado, pero algunas vistas necesitan acompañar el proceso mientras sucede. Repetir una solicitud cada cierto intervalo puede servir en algunos casos; en otros, la experiencia requiere recibir novedades sobre una conexión que permanece abierta. Esa necesidad cambia la forma de pensar el transporte.
Estudiamos ASGI y WebSockets, reconociendo lo que agregan frente al recorrido HTTP habitual. El canal necesita controles de identidad, permisos y tratamiento de desconexiones. Mantener una conexión no debe convertirse en una excepción a la política que ya aplicamos a los endpoints. Tampoco vuelve confiable un dato que no pasó por la validación correspondiente.
La interfaz puede recibir novedades con mayor continuidad. Pero mostrar cada valor no le dice al usuario cuáles requieren atención. Para que la información ayude a actuar, SensorHub debe reconocer condiciones relevantes y seguirlas en el tiempo. Esa es la diferencia entre mostrar un número y administrar una alarma.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Una conexión viva con permisos
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Cliente. Abre conexión persistente
- ASGI. Gestiona conexión y eventos
- Consumer. Verifica acceso y alcance
- Canal. Distribuye eventos autorizados
01 / EL PROBLEMA
¿Para qué sirve?
Hacer polling muy frecuente repite consultas aunque no haya cambios. Un WebSocket permite enviar novedades mientras la conexión permanece abierta.
02 / COMPRENDER
El concepto, explicado
ASGI admite protocolos diferentes; ProtocolTypeRouter compone HTTP y websocket. Un consumer maneja conexión, eventos y desconexión.
Los grupos direccionan eventos, pero no conceden acceso. Verifica identidad, capacidad y alcance antes de accept. Para varios procesos necesitas una capa de canales compartida.
03 / CONSTRUIR
Implementación paso a paso
- Configura Channels y servidor ASGI.
- Enruta HTTP y WebSocket.
- Autoriza antes de aceptar.
- Limpia grupos al desconectar.
04 / APLICAR
Ejemplo en SensorHub
from channels.generic.websocket import AsyncJsonWebsocketConsumer
class SensorConsumer(AsyncJsonWebsocketConsumer):
async def connect(self):
# Verificar permisos y sensor con acceso autorizado antes de accept.
self.group = None
if not await self.authorized():
await self.close(code=4403)
return
self.group = "sensor_" + self.scope["url_route"]["kwargs"]["sensor_id"]
await self.channel_layer.group_add(self.group, self.channel_name)
await self.accept()
async def disconnect(self, code):
if self.group:
await self.channel_layer.group_discard(self.group, self.channel_name)
async def reading_created(self, event):
await self.send_json(event["data"])Cómo leer el ejemplo
- authorized es un método a implementar con la política del ejemplo y acceso ORM mediante database_sync_to_async.
- Inicializar group antes del rechazo evita fallos de limpieza.
- El tipo reading.created se resuelve al handler reading_created en Channels.
Error habitual
InMemoryChannelLayer no comparte eventos entre workers. Verifica Origin para conexiones con cookies y define revocación de permisos de conexiones largas.
05 / PRACTICAR
Tu turno
Prueba un rechazo de conexión y luego disconnect.
Ver solución orientativa
El consumer cierra sin intentar usar un nombre de grupo que nunca se inicializó.
06 / VERIFICAR
Cómo sabes que funciona
- Usuarios sin acceso no reciben eventos.
- Dos procesos intercambian eventos con una capa compartida.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Alarmas como máquina de estados →Continuar en modo relato