Al construir servicios web o APIs en Python, elegir la tecnología de comunicación adecuada es una de las decisiones de diseño más fundamentales. REST, WebSocket, gRPC, MQTT — probablemente has oído hablar de todas, pero saber cuál se adapta a tu proyecto puede ser sorprendentemente difícil.
Este artículo compara 8 tecnologías de comunicación utilizadas habitualmente en Python, organizadas por caso de uso, dificultad, velocidad y capacidad en tiempo real, con ejemplos de código prácticos y orientación sobre cuándo elegir cada una.
Resumen comparativo
| Tecnología | Uso principal | Dificultad | Velocidad | Tiempo real | Característica |
|---|---|---|---|---|---|
| REST | APIs (general) | Baja | Media | ✗ | Estándar de API web |
| WebSocket | Comunicación en tiempo real | Media | Alta | ◎ | Bidireccional persistente |
| gRPC | Microservicios internos | Alta | ◎ | ○ | Protocol Buffers |
| MQTT | IoT / Sensores | Media | Alta | ○ | Pub/Sub ultraligero |
| SSE | Servidor → Cliente push | Baja | Media | ○ | Stream unidireccional |
| Celery | Procesamiento en segundo plano | Media | Alta | ✗ | Cola de tareas |
| requests | Cliente HTTP | Baja | Media | ✗ | Síncrono y simple |
| aiohttp | Cliente HTTP asíncrono | Media | Alta | ✗ | Nativo de asyncio |
El punto clave: no elijas una tecnología porque sea «rápida» o «moderna». Elige la que se adapte a los requisitos de tu proyecto. El 90% de los proyectos funcionan perfectamente solo con REST, y siempre puedes añadir WebSocket o Celery más tarde.
REST — El estándar de las API web
REST (Representational State Transfer) utiliza métodos HTTP (GET / POST / PUT / DELETE) para operar sobre recursos. Es el estilo de diseño de API más ampliamente adoptado, y la regla práctica es simple: en caso de duda, usa REST.
En Python, FastAPI se ha convertido en el estándar de facto. Ofrece validación basada en type hints, documentación automática (Swagger UI) y soporte asíncrono.
from fastapi import FastAPI
app = FastAPI()
@app.get("/users/{user_id}")
def get_user(user_id: int):
return {"user_id": user_id, "name": "Alice"}
# GET /users/1 → {"user_id": 1, "name": "Alice"}
Cuándo usar:
- APIs web públicas o internas
- Operaciones CRUD
- Backends de paneles de administración
- Lógica del lado servidor para apps móviles
FastAPI genera automáticamente Swagger UI en /docs. Solo esto cubre el 80% de las necesidades de documentación de tu API. Si vienes de Flask, la curva de aprendizaje es mínima.
REST es fundamentalmente petición/respuesta. Si necesitas que el servidor envíe datos continuamente al cliente, REST no puede hacerlo nativamente. Intentar simularlo con polling genera alta carga y mala latencia.
pip install fastapi uvicorn
WebSocket — Comunicación bidireccional en tiempo real
WebSocket establece un canal de comunicación persistente y bidireccional entre cliente y servidor. A diferencia de HTTP, una vez conectados, ambos lados pueden enviar datos libremente.
FastAPI soporta WebSocket de forma nativa, por lo que puedes añadir endpoints en tiempo real junto a tu API REST en el mismo proyecto.
from fastapi import FastAPI, WebSocket
app = FastAPI()
@app.websocket("/ws")
async def websocket_endpoint(ws: WebSocket):
await ws.accept()
while True:
data = await ws.receive_text()
await ws.send_text(f"Echo: {data}")
Cuándo usar:
- Aplicaciones de chat
- Dashboards en tiempo real
- Sincronización de estado de juegos online
- Edición colaborativa
WebSocket mantiene conexiones activas, por lo que el consumo de memoria escala linealmente con los clientes conectados. Para miles de conexiones simultáneas, necesitarás Redis Pub/Sub para escalar horizontalmente.
Algunos principiantes implementan toda su API sobre WebSocket, pero la obtención estándar de datos es mucho más simple y compatible con caché usando REST.
pip install fastapi uvicorn
gRPC — Comunicación de alta velocidad entre microservicios
gRPC es un framework RPC desarrollado por Google. Utiliza Protocol Buffers (protobuf) para la serialización de datos, resultando en payloads más pequeños y procesamiento más rápido que REST basado en JSON.
Defines las interfaces de servicio en archivos .proto, y luego se genera automáticamente el código de cliente y servidor. Esto garantiza seguridad de tipos.
# Using a client generated from greeter.proto
import grpc
import greeter_pb2
import greeter_pb2_grpc
channel = grpc.insecure_channel('localhost:50051')
stub = greeter_pb2_grpc.GreeterStub(channel)
response = stub.SayHello(greeter_pb2.HelloRequest(name='World'))
print(response.message) # Hello, World!
Cuándo usar:
- Comunicación interna entre microservicios
- Sistemas de alta carga sensibles a latencia
- Entornos multi-lenguaje (Python ↔ Go ↔ Java)
- Escenarios de comunicación streaming
gRPC funciona sobre HTTP/2, permitiendo multiplexación — múltiples peticiones en paralelo sobre una sola conexión TCP. En entornos de alta carga, esto marca una diferencia significativa.
gRPC no se puede llamar directamente desde navegadores (necesitas gRPC-Web). El patrón estándar es usar REST para APIs públicas y gRPC solo para comunicación interna.
pip install grpcio grpcio-tools
MQTT — Protocolo ligero para IoT
MQTT es un protocolo de mensajería Pub/Sub ultraligero diseñado para entornos con ancho de banda limitado. Funciona sobre TCP, con un header que puede ser tan pequeño como 2 bytes.
Los mensajes fluyen a través de un servidor «broker»: los publicadores envían mensajes a temas, y los suscriptores los reciben.
import paho.mqtt.client as mqtt
def on_connect(client, userdata, flags, rc):
print(f"Connected (rc={rc})")
client.subscribe("sensor/temperature")
def on_message(client, userdata, msg):
print(f"{msg.topic}: {msg.payload.decode()}")
client = mqtt.Client()
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.hivemq.com", 1883)
client.loop_forever()
Cuándo usar:
- Recolección de datos de sensores IoT
- Control remoto de robots
- Coordinación de dispositivos smart home
- Monitoreo de equipos industriales
MQTT ofrece 3 niveles de QoS. QoS 0 es «enviar y olvidar», QoS 1 garantiza «al menos una entrega», QoS 2 garantiza «exactamente una entrega». Usa QoS 0 para datos de sensores y QoS 1+ para comandos de control.
MQTT no es adecuado para comunicación web general. En navegadores requiere MQTT sobre WebSocket, y para APIs web típicas, REST o WebSocket son más directos.
pip install paho-mqtt
SSE — Push unidireccional del servidor
SSE (Server-Sent Events) proporciona comunicación en tiempo real unidireccional del servidor al cliente. Funciona sobre HTTP estándar, con mejor compatibilidad con proxies y firewalls que WebSocket.
Es ideal para escenarios donde el servidor envía actualizaciones continuamente — streaming de logs, feeds de notificaciones, indicadores de progreso.
from fastapi import FastAPI
from fastapi.responses import StreamingResponse
import asyncio
app = FastAPI()
async def event_generator():
for i in range(10):
yield f"data: Event {i}
"
await asyncio.sleep(1)
@app.get("/stream")
async def stream():
return StreamingResponse(
event_generator(),
media_type="text/event-stream"
)
Cuándo usar:
- Feeds de notificaciones
- Visualización de logs en tiempo real
- Barras de progreso para operaciones largas
- Respuestas streaming de IA (estilo ChatGPT)
En el lado del navegador, SSE solo requiere la API EventSource — mucho menos esfuerzo que WebSocket. Si el push «servidor → cliente» es suficiente, SSE es la opción más simple.
SSE no puede enviar datos del cliente al servidor. Para comunicación bidireccional, usa WebSocket. Bajo HTTP/1.1, los navegadores limitan las conexiones simultáneas por dominio (típicamente 6).
pip install fastapi uvicorn
Celery — Cola de tareas en segundo plano
Celery es un sistema de cola de tareas para ejecución asíncrona en segundo plano de operaciones pesadas. Celery descarga estas tareas para que la petición retorne inmediatamente.
Utiliza un broker de mensajes (Redis o RabbitMQ) para encolar y distribuir tareas entre procesos worker.
from celery import Celery
app = Celery('tasks', broker='redis://localhost:6379/0')
@app.task
def send_welcome_email(user_id: int):
# Heavy operation (email, external API call, etc.)
print(f"Sending email to user {user_id}")
return True
# Caller: send_welcome_email.delay(42)
Cuándo usar:
- Envío asíncrono de emails / notificaciones
- Procesamiento de imágenes y video
- Tareas batch programadas (celery beat)
- Generación de reportes, exportación de datos
Celery también soporta ejecución programada. Con celery beat, puedes gestionar tareas periódicas tipo cron directamente en Python — por ejemplo, «generar un informe cada día a las 3 AM».
Celery requiere Redis o RabbitMQ como infraestructura. Si solo necesitas enviar algunos emails al día, BackgroundTasks de FastAPI es suficiente. Introduce Celery cuando necesites reintentos o escalado de workers.
pip install celery redis
requests — El cliente HTTP más simple
requests es la librería de referencia para hacer llamadas HTTP en Python. Ya sea para consumir APIs externas, hacer web scraping o probar endpoints, es típicamente la primera opción.
Su mayor fortaleza es la simplicidad absoluta. Un GET HTTP completo se hace en solo 3 líneas.
import requests
response = requests.get("https://api.github.com/users/python")
print(response.status_code) # 200
print(response.json()["name"]) # Python
Cuándo usar:
- Consumo de APIs REST externas
- HTTP para web scraping
- Tests de API durante desarrollo
- Herramientas CLI con peticiones HTTP
Usa requests.Session() para compartir cookies y headers entre peticiones y reutilizar conexiones TCP. Esto acelera significativamente las peticiones secuenciales al mismo servidor.
requests es síncrono. Si necesitas llamar a 100 APIs secuencialmente a 0.5s cada una, son 50 segundos. Para grandes volúmenes en paralelo, usa aiohttp.
pip install requests
aiohttp — Cliente HTTP asíncrono
aiohttp es una librería cliente/servidor HTTP asíncrona basada en asyncio. Piensa en ella como la versión async de requests. Puede enviar grandes cantidades de peticiones HTTP concurrentemente.
import aiohttp
import asyncio
async def fetch(url: str) -> int:
async with aiohttp.ClientSession() as session:
async with session.get(url) as response:
return response.status
async def main():
urls = ["https://api.github.com"] * 10
tasks = [fetch(url) for url in urls]
results = await asyncio.gather(*tasks)
print(results) # [200, 200, 200, ...]
asyncio.run(main())
Cuándo usar:
- Alto volumen de llamadas API externas
- Web crawlers y scrapers
- Proyectos que ya usan asyncio
- Construcción de servidores web async
Combinado con asyncio.gather(), puedes enviar 10 peticiones «casi simultáneamente». Lo que tarda 50 segundos con requests puede completarse en segundos con aiohttp. Ten cuidado con los rate limits (asyncio.Semaphore).
Usar aiohttp sin entender async/await lleva a confusión y bugs. Empieza con requests, familiarízate, y migra cuando la necesidad de concurrencia sea clara.
pip install aiohttp
Guía de selección + patrones de arquitectura
Tras revisar las 8 tecnologías, recuerda que en la práctica rara vez usas solo una — las combinas. Estos son patrones de arquitectura probados organizados por escala.
| Escala | Stack | Ejemplo |
|---|---|---|
| Personal / Pequeño | FastAPI (REST) | API de sitio de herramientas, blog personal |
| Con tiempo real | FastAPI (REST + WebSocket) | Servicio con chat, dashboard |
| Mediano | FastAPI (REST) + Celery + Redis | E-commerce, SaaS |
| Grande | FastAPI (REST) + gRPC (internal) + Celery | Plataforma de microservicios |
| IoT | MQTT + REST (admin) | Red de sensores, hogar inteligente |
Errores comunes de principiantes:
- Construir todo con WebSocket — Las partes sin necesidad de tiempo real pierden caché y son más difíciles de depurar
- Empezar con gRPC — Para proyectos pequeños, REST es más que suficiente
- Usar aiohttp sin entender async — Si
requestsno causa problemas, no fuerces la migración - Sobre-introducir Celery — Para pocas tareas,
BackgroundTasksde FastAPI basta
El denominador común es sobre-ingeniería del stack tecnológico. Empieza simple y añade complejidad solo cuando los requisitos lo exijan.
Resumen
Las tecnologías de comunicación web en Python son fáciles de elegir cuando conoces tu caso de uso.
- APIs en general → REST (FastAPI)
- Bidireccional en tiempo real → WebSocket
- Alta velocidad interna → gRPC
- IoT / Sensores → MQTT
- Push del servidor → SSE
- Procesamiento en segundo plano → Celery
- Cliente HTTP (síncrono) → requests
- Cliente HTTP (asíncrono) → aiohttp
En caso de duda, empieza con REST. La mayoría de los proyectos arrancan perfectamente solo con REST, y añadir WebSocket o Celery después no es difícil. En la selección tecnológica, «añadir cuando lo necesites» es la mentalidad correcta.

Deja una respuesta