Protocolos y payloads eficientes

1 // Cada byte, tres veces

Un byte de más en una respuesta no se paga una vez, sino en tres sitios:

1. En el servidor: hay que obtener el dato, convertirlo a JSON (serializar) y comprimirlo.
2. En la red: hay que transmitirlo. Recuerda del módulo 2 que los modelos reparten el consumo de la red en proporción a los datos, y que a largo plazo más tráfico significa más infraestructura.
3. En el cliente: hay que descomprimirlo, interpretarlo (deserializar) y guardarlo en memoria, a menudo en un móvil con batería.

Y hay un cuarto coste que no es energético: el tiempo de espera, que en conexiones móviles lentas o con tarifas de datos limitadas afecta de verdad a los usuarios.

2 // Adelgazar las respuestas

Hay cuatro formas de reducir un payload, y se pueden combinar:

Enviar sólo los campos necesarios. Es muy habitual que una API devuelva el objeto completo de la base de datos, con treinta campos, cuando la pantalla que la consume sólo muestra tres. Soluciones: crear respuestas específicas (DTO) para cada uso, permitir que el cliente elija los campos con un parámetro como ?fields=id,nombre,precio, o usar GraphQL, cuyo punto fuerte es precisamente pedir sólo lo que se necesita.

Enviar sólo los elementos necesarios. Una lista de 5.000 productos cuando se muestran 20 es un derroche. La paginación, que tratarás desde el lado del frontend en el módulo 4, empieza aquí.

Comprimir. Los servidores web y los frameworks pueden comprimir las respuestas con gzip o Brotli si el cliente lo admite. En texto como JSON o HTML, la reducción suele ser enorme.

Elegir un formato más compacto. JSON es legible y universal, pero repite los nombres de los campos en cada objeto. Los formatos binarios como Protocol Buffers no envían nombres, sólo números de campo y valores codificados de forma compacta.

3 // Conexiones: menos saludos, más datos

Antes de enviar un solo byte útil, cliente y servidor tienen que establecer la conexión: el saludo de TCP y la negociación de cifrado TLS. Si cada petición abre una conexión nueva, ese trabajo se repite una y otra vez.

• HTTP/1.1 ya permite reutilizar conexiones (keep-alive), pero atiende las peticiones de una en una por conexión, y los navegadores abren varias en paralelo.
• HTTP/2 permite enviar muchas peticiones a la vez por una sola conexión (multiplexación) y comprime las cabeceras, que en APIs con muchas llamadas pequeñas pueden pesar tanto como el propio contenido.
• HTTP/3 hace lo mismo sobre QUIC, un transporte basado en UDP que se recupera mejor en redes móviles con pérdidas.

En el lado del servidor, lo equivalente es usar pools de conexiones a la base de datos y a otros servicios, en lugar de abrir y cerrar una conexión en cada petición.

4 // REST frente a gRPC

REST con JSON es el estándar de facto de las APIs web: legible, fácil de probar con el navegador o con curl, y entendido por cualquier lenguaje.

gRPC es un framework de llamadas remotas creado por Google. Usa Protocol Buffers como formato y HTTP/2 como transporte, y define la API en un contrato (un fichero .proto) a partir del cual se genera el código de cliente y servidor.

La conclusión práctica: gRPC brilla en la comunicación interna entre microservicios, donde hay muchísimas llamadas, ambos extremos los controla el mismo equipo y nadie necesita leer los mensajes a mano. Para una API pública o una que consume directamente el navegador, REST con respuestas ajustadas y comprimidas suele ser la opción más razonable.