Cliente y servidor: quién pregunta y quién responde

En os:1 seguiste un programa en una sola máquina: recibe una porción de la CPU, es dueño de algunas páginas de memoria, se puede pausar y reanudar. En networking:1 seguiste una petición por todo el planeta: encuentra un host, abre una conexión TCP y vuelve como respuesta. La arquitectura empieza donde se encuentran esos dos mundos. En el momento en que tu programa habla con un programa en otra máquina, ya no estás escribiendo un solo programa. Estás trazando una línea entre dos de ellos, y casi todas las decisiones que vienen después dependen de dónde traces esa línea.

El cliente es el programa que empieza la conversación. Tiene una pantalla, un usuario y ninguna idea de cuál es la respuesta correcta. El servidor es el programa que espera conversaciones, guarda los datos y decide qué hacer con cada petición. Esa es toda la definición, y no dice nada sobre el tamaño: un teléfono puede ser un cliente, pero ese mismo teléfono puede ejecutar un servidor; una laptop es un servidor mientras aloja una partida para tus amigos. Lo que convierte algo en servidor es que responde peticiones que no inició, y que las peticiones de otras personas llegan esté listo o no.

GET /orders/77 HTTP/1.1
Host: shop.example
Authorization: Bearer eyJhbGciOi...


HTTP/1.1 200 OK
Content-Type: application/json

{"id": 77, "total": 12.90, "status": "paid"}

Aquí está la regla que decide casi todo: el cliente no es tuyo. Se ejecuta en la máquina de otra persona, en una red que no controlas, y su código se puede leer y modificar en las herramientas de desarrollador de un navegador en unos diez segundos. Por eso el servidor nunca debe creerle a un cliente. "Soy el usuario 5" es una afirmación, no un hecho. El servidor tiene que comprobarlo contra algo que el cliente no pueda falsificar, normalmente un token firmado en el servidor. Un precio que envía el navegador es una sugerencia que hay que recalcular desde la base de datos, nunca un número que se cobre tal cual.

Un servidor que no guarda nada entre peticiones se llama sin estado. Recibe una petición, produce una respuesta y olvida que la petición existió. Eso suena a que pierdes algo, pero es la razón por la que un solo servidor puede atender a un millón de personas: nada de ti queda atado a esa máquina en particular, así que tu siguiente petición puede ir a cualquiera de veinte servidores idénticos. Todo lo que debe sobrevivir entre peticiones — un carrito de compras, una sesión iniciada — se guarda en algún lugar compartido: una base de datos, una caché o dentro de un token firmado que el cliente lleva consigo. Es la misma idea que viste con HTTP en redes:1, ahora aplicada como una decisión de arquitectura.