Red

Cuando desarrollamos una aplicación moderna, una de las primeras decisiones que debemos tomar es cómo van a comunicarse sus diferentes componentes.

Una aplicación web puede necesitar consultar usuarios, enviar pedidos, recibir notificaciones, mantener una comunicación permanente con un servidor o incluso intercambiar información con sensores IoT.

Para cada escenario existen diferentes tecnologías y patrones de comunicación.

Entre los más utilizados encontramos:

REST
GraphQL
gRPC
WebSockets
Webhooks
SSE (Server-Sent Events)
MQTT

Aunque a menudo se habla de todos ellos como “protocolos de API”, técnicamente no son equivalentes. Algunos son arquitecturas, otros protocolos, otros mecanismos de comunicación.

La diferencia es importante porque cada uno resuelve un problema diferente.

1. REST

REST es probablemente el modelo más conocido para crear APIs web.

REST significa Representational State Transfer y se basa normalmente en HTTP.

Una API REST suele representar los recursos mediante URLs:

GET    /users
GET    /users/123
POST   /users
PUT    /users/123
DELETE /users/123

Por ejemplo:

GET /api/users/123

Podría devolver:

{
  "id": 123,
  "name": "Ana",
  "email": "[email protected]"
}

¿Cómo funciona?

El cliente realiza una petición:

Cliente
   |
   | GET /users
   v
Servidor
   |
   | JSON
   v
Cliente

Es especialmente adecuado cuando queremos que un cliente consulte o modifique recursos.

Ejemplo

Imaginemos una tienda online:

/users
/products
/orders

Podemos tener:

GET /products
GET /products/25
POST /orders
GET /orders/100

Ventajas

Sencillo de entender.
Utiliza HTTP.
Muy compatible con navegadores y herramientas.
Fácil de probar.
Muy extendido.
Funciona bien para APIs públicas.

Inconvenientes

En determinadas aplicaciones puede producirse el problema conocido como overfetching.

Por ejemplo, el servidor devuelve:

{
  "id": 10,
  "name": "Portátil",
  "description": "...",
  "price": 1299,
  "manufacturer": "...",
  "stock": 23,
  "reviews": [...]
}

pero el cliente solamente necesitaba:

name
price

Aquí aparecen alternativas como GraphQL.

2. GraphQL

GraphQL cambia la filosofía.

En lugar de tener diferentes endpoints para obtener diferentes recursos, normalmente tenemos un endpoint y el cliente especifica qué información necesita.

Por ejemplo:

query {
  product(id: 25) {
    name
    price
  }
}

El servidor podría responder:

{
  "data": {
    "product": {
      "name": "Portátil",
      "price": 1299
    }
  }
}

El cliente ha solicitado exactamente esos campos.

REST frente a GraphQL

Con REST podríamos tener:

GET /products/25

Con GraphQL:

query {
  product(id: 25) {
    name
    price
  }
}

Una diferencia importante es que GraphQL permite al cliente expresar la estructura de los datos que necesita.

¿Cuándo utilizar GraphQL?

Puede ser especialmente interesante cuando:

Tenemos aplicaciones móviles.
El frontend necesita datos muy diferentes según la pantalla.
Existen relaciones complejas entre datos.
Queremos evitar múltiples peticiones.
El cliente necesita controlar qué campos recibe.

3. gRPC

gRPC está orientado a la comunicación entre servicios.

Fue desarrollado originalmente por Google y utiliza Protocol Buffers (Protobuf) como mecanismo habitual para definir los mensajes y servicios.

En lugar de pensar principalmente en recursos HTTP:

GET /users/123

podemos pensar en llamadas a métodos:

GetUser()
CreateUser()
DeleteUser()

Por ejemplo, podemos definir un servicio:

service UserService {
    rpc GetUser(GetUserRequest) returns (User);
}

Y después el cliente puede invocar:

GetUser()

Arquitectura

Podríamos tener:

Servicio A
    |
    | gRPC
    v
Servicio B

Esto resulta especialmente interesante en arquitecturas de microservicios.

Por ejemplo:

Frontend
    |
    v
API Gateway
    |
    +---- gRPC ----> Servicio usuarios
    |
    +---- gRPC ----> Servicio pedidos
    |
    +---- gRPC ----> Servicio pagos

Ventajas

Alto rendimiento.
Comunicación eficiente.
Contratos fuertemente definidos.
Generación automática de código.
Streaming.
Muy apropiado para comunicación entre servicios.

¿REST o gRPC?

Una aproximación habitual sería:

Aplicación web
      |
     REST
      |
 API pública

mientras que internamente:

Servicio A
     |
    gRPC
     |
Servicio B

No significa que siempre tenga que hacerse así. La elección depende de la arquitectura.

4. WebSockets

Aquí cambia radicalmente el modelo.

REST funciona normalmente así:

Cliente ---> Servidor
Cliente <--- Servidor

El cliente realiza una petición y el servidor responde.

Con WebSockets podemos mantener una conexión abierta:

Cliente <=================> Servidor

Los dos extremos pueden enviar información.

Por ejemplo:

Cliente ---> mensaje
Servidor --> mensaje
Cliente ---> mensaje
Servidor --> mensaje

¿Para qué sirven?

Son especialmente útiles cuando necesitamos comunicación bidireccional.

Por ejemplo:

Chats.
Juegos online.
Aplicaciones colaborativas.
Trading.
Paneles interactivos.
Sistemas de monitorización.
Aplicaciones que necesitan actualizaciones frecuentes.

Un chat podría funcionar así:

Alice
  |
  | "Hola"
  v
Servidor
  |
  | "Hola"
  v
Bob

No es necesario que Bob esté realizando continuamente peticiones HTTP para comprobar si ha llegado un mensaje.

5. Webhooks

Los Webhooks utilizan una idea diferente.

En lugar de que una aplicación esté preguntando constantemente:

¿Ha ocurrido algo?

¿Ha ocurrido algo?

¿Ha ocurrido algo?

¿Ha ocurrido algo?

otra aplicación puede avisarnos cuando sucede el evento.

Por ejemplo:

Pago realizado
     |
     v
Stripe
     |
     | POST
     v
https://miweb.com/webhook

El servidor recibe algo parecido a:

{
  "event": "payment.completed",
  "id": "12345",
  "amount": 49.99
}

Polling frente a Webhook

Sin webhook:

Aplicación
    |
    | ¿Hay novedades?
    v
Servidor

Aplicación
    |
    | ¿Hay novedades?
    v
Servidor

Aplicación
    |
    | ¿Hay novedades?
    v
Servidor

Con webhook:

Servidor
   |
   | Ha ocurrido algo
   v
Webhook
   |
   v
Aplicación

Es un patrón muy utilizado en integraciones entre servicios.

Por ejemplo:

GitHub
   |
   | push
   v
Webhook
   |
   v
Servidor CI/CD

6. SSE — Server-Sent Events

SSE significa Server-Sent Events.

Permite que el servidor mantenga una conexión HTTP abierta y vaya enviando eventos al cliente.

La comunicación es principalmente:

Servidor
   |
   | evento
   v
Cliente

Por tanto, a diferencia de WebSockets, la comunicación está orientada a que el servidor envíe información al cliente.

Por ejemplo:

Servidor
   |
   | temperatura: 22
   v
Navegador
   |
   | temperatura: 23
   v
Navegador
   |
   | temperatura: 24
   v
Navegador

Un ejemplo sencillo en JavaScript sería:

const eventos = new EventSource("/events");

eventos.onmessage = function(event) {
    console.log(event.data);
};

El servidor puede enviar:

data: Temperatura: 22ºC

data: Temperatura: 23ºC

data: Temperatura: 24ºC

¿Cuándo puede ser útil?

Por ejemplo:

Paneles de monitorización.
Progreso de procesos.
Noticias.
Actualizaciones de estado.
Logs.
Notificaciones.
Sistemas donde el servidor genera eventos.

SSE frente a WebSockets

Una diferencia sencilla de recordar:

SSE

Servidor -----------> Cliente

mientras que:

WebSocket

Servidor <----------> Cliente

Si solamente necesitamos que el servidor envíe actualizaciones, SSE puede ser suficiente.

7. MQTT

MQTT es especialmente interesante cuando entramos en el mundo de IoT.

MQTT utiliza un modelo basado en:

Publisher
     |
     v
   Broker
     |
     +--------> Subscriber
     |
     +--------> Subscriber

El dispositivo no tiene necesariamente que conocer quién recibirá el mensaje.

Publica en un topic.

Por ejemplo:

casa/salon/temperatura

Un sensor podría publicar:

{
  "temperature": 23.5
}

El broker recibe el mensaje.

Después, cualquier dispositivo suscrito al topic puede recibirlo.

Sensor
  |
  | 23.5 ºC
  v
Broker
  |
  +----> Smartphone
  |
  +----> Raspberry Pi
  |
  +----> Servidor

¿Por qué MQTT es interesante para IoT?

Porque está diseñado para escenarios donde podemos tener:

Sensores.
Microcontroladores.
Dispositivos con pocos recursos.
Redes inestables.
Comunicaciones de pequeño tamaño.
Muchos dispositivos conectados.

Por ejemplo:

ESP32
  |
  | MQTT
  v
Broker
  |
  +----> Dashboard
  |
  +----> Base de datos
  |
  +----> Sistema de alertas

Esto hace que MQTT sea especialmente interesante para proyectos con ESP32, Raspberry Pi, sensores e IoT.

Comparativa rápida

Tecnología	Comunicación	Uso habitual
REST	Cliente → servidor	APIs web
GraphQL	Cliente → servidor	APIs con datos flexibles
gRPC	Servicio ↔ servicio	Microservicios
WebSockets	Bidireccional	Chat, juegos, tiempo real
Webhooks	Evento → receptor	Integraciones
SSE	Servidor → cliente	Eventos y actualizaciones
MQTT	Publisher → broker → subscribers	IoT

Una forma sencilla de recordarlos sería:

REST
"Quiero un recurso"

GraphQL
"Quiero exactamente estos datos"

gRPC
"Quiero ejecutar este método en otro servicio"

WebSockets
"Quiero mantener una conversación bidireccional"

Webhooks
"Avísame cuando ocurra algo"

SSE
"Envíame las novedades"

MQTT
"Publico este mensaje y los interesados lo reciben"

7 formas de comunicación entre aplicaciones: REST, GraphQL, gRPC, WebSockets, Webhooks, SSE y MQTT (Red)

1. REST

¿Cómo funciona?

Ejemplo

Ventajas

Inconvenientes

2. GraphQL

REST frente a GraphQL

¿Cuándo utilizar GraphQL?

3. gRPC

Arquitectura

Ventajas

¿REST o gRPC?

4. WebSockets

¿Para qué sirven?

5. Webhooks

Polling frente a Webhook

6. SSE — Server-Sent Events

¿Cuándo puede ser útil?

SSE frente a WebSockets

7. MQTT

¿Por qué MQTT es interesante para IoT?

Comparativa rápida

LIBRO DE POWERSHELL

LO ÚLTIMO

RECOMENDADO