El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència

HOME

L'arquitectura client-servidor és el model de comunicació distribuïda més influent de la història del programari. Des de les primeres aplicacions d'escriptori que es connectaven a una base de dades central, passant per les arquitectures de tres nivells, fins a la web que utilitzes cada dia: pràcticament tot el que es comunica per xarxa segueix, a la seva arrel, el patró client-servidor. A diferència de l'arquitectura en capes (que organitza el codi), l'arquitectura client-servidor organitza la distribució física del sistema entre màquines. En aquesta lliçó recorrerem els models de dos i tres nivells, la diferència entre clients lleugers (thin) i pesants (thick), i com tot això va evolucionar cap a l'arquitectura web moderna.

Contingut

El model client-servidor
Model de dos nivells (2-tier)
Model de tres nivells (3-tier)
Thin client vs thick client
L'evolució cap a la web
Avantatges i inconvenients
Errors comuns i consells
Exercicis
Conclusió

El model client-servidor

En el model client-servidor, les responsabilitats es reparteixen entre dos rols:

Client: inicia les peticions. Demana dades o serveis.
Servidor: espera peticions, les processa i retorna respostes. Centralitza recursos compartits (dades, lògica).

sequenceDiagram
    participant C as Client
    participant S as Servidor
    C->>S: Petició (p. ex. "dóna'm la pòlissa 42")
    S->>S: Processa / consulta recursos
    S-->>C: Resposta (dades de la pòlissa)

Característiques essencials:

Asimetria de rols: el client demana, el servidor serveix. No són iguals (a diferència de les xarxes peer-to-peer).
Centralització: el servidor concentra els recursos compartits, cosa que facilita la gestió, la seguretat i la consistència.
Comunicació per xarxa: client i servidor són tiers diferents; entre ells hi ha latència, errors possibles i necessitat d'un protocol.

Model de dos nivells (2-tier)

El model de dos nivells va ser el primer a popularitzar-se als anys 90 amb les aplicacions d'escriptori corporatives. El repartiment típic:

Tier 1 — Client: l'aplicació d'escriptori, que conté la interfície i la lògica de negoci.
Tier 2 — Servidor de base de dades: emmagatzema les dades i, sovint, part de la lògica en stored procedures.

graph LR
    C[Client d'escriptori\nUI + Lògica de negoci] -->|SQL per xarxa| BD[(Servidor de Base de Dades)]

-- En 2-tier era comú posar lògica de negoci a la mateixa BD
CREATE PROCEDURE contratar_poliza(IN cliente VARCHAR(120), IN riesgo VARCHAR(60))
BEGIN
    -- Regla de negoci incrustada en el servidor de dades
    IF riesgo = 'NO_ASEGURABLE' THEN
        SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Riesgo no asegurable';
    END IF;
    INSERT INTO polizas(cliente, riesgo) VALUES(cliente, riesgo);
END;

Problemes del 2-tier que van motivar el seu declivi:

Client "gras" difícil de mantenir: cada canvi de lògica obligava a reinstal·lar l'aplicació a cada PC.
Escalabilitat limitada: cada client obria la seva pròpia connexió a la BD; amb centenars d'usuaris, la BD se saturava.
Lògica dispersa: les regles vivien a mitges en el client i a mitges en stored procedures, difícils de versionar i provar.

Model de tres nivells (3-tier)

El model de tres nivells introdueix un nivell intermedi —el servidor d'aplicacions— que concentra la lògica de negoci. És el model dominant en aplicacions empresarials.

Tier 1 — Presentació (client): navegador o client lleuger. Només presenta.
Tier 2 — Aplicació (servidor d'aplicacions): conté la lògica de negoci.
Tier 3 — Dades (servidor de BD): persisteix la informació.

graph LR
    C[Client\nNavegador] -->|HTTP/JSON| A[Servidor d'Aplicacions\nLògica de negoci]
    A -->|SQL| BD[(Servidor de Base de Dades)]

Aspecte	2-tier	3-tier
On viu la lògica	En el client i/o en la BD	En el servidor d'aplicacions
Manteniment del client	Costós (reinstal·lar)	Senzill (centralitzat en el servidor)
Escalabilitat	Limitada	Bona (s'escala el tier intermedi)
Connexions a BD	Una per client	Compartides (pool en el servidor)
Desplegament de canvis	A cada màquina client	En el servidor

No confonguis els tres nivells físics amb les tres capes lògiques de la lliçó anterior. Coincideixen sovint (presentació/negoci/dades), però són conceptes diferents: les capes organitzen codi i els nivells organitzen desplegament. Un servidor d'aplicacions 3-tier pot tenir internament les seves pròpies capes.

Thin client vs thick client

La gran pregunta del disseny client-servidor: quanta responsabilitat poso en el client?

Thin client (client lleuger): amb prou feines presenta; tota la lògica és al servidor. Exemple clàssic: una web servida íntegrament des del servidor, un terminal.
Thick / fat client (client pesant): conté lògica significativa i estat. Exemple: una app d'escriptori o una SPA moderna amb molta lògica al navegador.

graph TD
    subgraph Thin Client
        T1[Client: només render] --> T2[Servidor: render + lògica + dades]
    end
    subgraph Thick Client
        K1[Client: UI + lògica + estat] --> K2[Servidor: API + dades]
    end

Criteri	Thin client	Thick client
Lògica en el client	Mínima	Significativa
Funcionament offline	No	Possible
Desplegament de canvis	Immediat (tot al servidor)	Requereix actualitzar el client
Càrrega en el servidor	Alta	Menor (part es delega)
Latència percebuda	Depèn del round-trip	Bona (reacciona en local)
Seguretat de la lògica	Alta (amagada al servidor)	Menor (el codi viatja al client)

// Exemple de thick client (SPA): el client valida i desa estat localment
function validarPrima(prima) {
  // Lògica executada al navegador (thick): resposta immediata sense xarxa
  if (prima <= 0) return "La prima ha de ser positiva";
  return null;
}
// El servidor HA de revalidar igualment: mai no confiïs en el client

Punt crític de seguretat: en un thick client, la validació al client millora l'experiència, però el servidor sempre ha de revalidar. El codi del client és manipulable.

L'evolució cap a la web

La web és, en essència, una arquitectura client-servidor de 3 nivells que ha oscil·lat entre thin i thick al llarg del temps:

timeline
    title Evolució del client web
    Web 1.0 : HTML estàtic : Thin client pur
    Server-side : JSP/PHP/Servlets : El servidor genera l'HTML
    AJAX : Pàgines dinàmiques parcials : El client comença a engreixar-se
    SPA : Angular/React/Vue : Thick client al navegador
    SSR / Hibrid : Next.js, etc. : Render mixt client-servidor

Etapes clau:

Web 1.0 (HTML estàtic): thin pur. El servidor lliura documents.
Server-side rendering (JSP, PHP, Servlets): el servidor genera HTML dinàmic per petició. Client lleuger.
AJAX: el navegador comença a demanar trossos de dades sense recarregar la pàgina. El client s'engreixa.
SPA (Single Page Application): Angular, React, Vue. El navegador és un thick client que consumeix una API REST/GraphQL.
SSR / híbrid: es torna a renderitzar part al servidor (rendiment, SEO) combinant-ho amb interactivitat al client.

# Petició HTTP típica d'un client web a una API REST (model 3-tier)
curl -X GET https://api.fiatc.example/polizas/42 \
     -H "Authorization: Bearer <token>" \
     -H "Accept: application/json"

Explicació: el navegador (tier 1) fa una petició HTTP al servidor d'aplicacions (tier 2), que al seu torn consultarà la BD (tier 3). El protocol és HTTP, el format JSON, i l'autenticació viatja en una capçalera. Aquest és l'esquelet de pràcticament tota la web moderna.

Avantatges i inconvenients

Avantatges	Inconvenients
Centralització de recursos i seguretat	El servidor és un punt únic de fallada (cal replicar-lo)
Manteniment i actualització centralitzats (en 3-tier)	Dependència de la xarxa: latència i errors possibles
Escalabilitat del tier intermedi	Major complexitat que un sistema local
Separació física de responsabilitats	Cost d'infraestructura i operació
Reutilització del servidor per molts clients	El protocol i els contractes s'han de gestionar amb cura

Errors Comuns i Consells

Confiar en la validació del client. En qualsevol thick client, valida també al servidor. El client és territori hostil.
Confondre tier amb layer. Tres nivells físics no obliguen a tres capes lògiques, ni al revés.
Posar lògica de negoci a la base de dades sense control. Heretat del 2-tier; dificulta proves i versionat. Utilitza-ho només amb criteri.
Oblidar que la xarxa falla. Tota crida client-servidor pot donar timeout o error; dissenya reintents i gestió d'errors.
No replicar el servidor. Un únic servidor és un punt únic de fallada; planifica alta disponibilitat.
Consell: decideix conscientment quant posar en el client. Més lògica en el client millora l'experiència offline però complica el desplegament i la seguretat.

Exercicis

Exercici 1. Una empresa té una app d'escriptori que es connecta directament a la base de dades amb la lògica de negoci dins de l'executable. Indica el model, els seus dos problemes principals i a quin model migraries.

Exercici 2. Classifica com a thin o thick: (a) un terminal que només mostra el que envia el servidor; (b) una SPA de React que valida formularis i cacheja dades; (c) una pàgina PHP que genera HTML al servidor.

Exercici 3. Explica per què validar una prima negativa només al navegador és insuficient i què ha de fer el servidor.

Solucions

Solució 1. És un model 2-tier amb thick client. Problemes: (1) manteniment costós, cada canvi exigeix reinstal·lar a cada PC; (2) escalabilitat limitada, cada client obre la seva pròpia connexió a la BD. Migració recomanada: 3-tier, introduint un servidor d'aplicacions que concentri la lògica i exposi una API.

Solució 2. (a) Thin. (b) Thick. (c) Thin (la lògica i el render són al servidor; el navegador només mostra HTML).

Solució 3. El codi JavaScript del navegador és manipulable: un usuari pot saltar-se la validació o enviar peticions directes a l'API. El servidor ha de revalidar sempre la prima abans de persistir-la, perquè és l'única frontera de confiança real.

Conclusió

L'arquitectura client-servidor defineix com es reparteix un sistema entre màquines: clients que demanen i servidors que serveixen. Hem vist el pas del fràgil 2-tier al robust 3-tier, la tensió entre clients lleugers i pesants, i com la web ha oscil·lat entre tots dos extrems. Aquest repartiment físic complementa el repartiment lògic en capes de la lliçó anterior. A continuació farem un salt qualitatiu en l'organització de l'interior del servidor: l'Arquitectura Hexagonal (Ports i Adaptadors), que protegeix el nucli de domini dels detalls d'infraestructura i inverteix la dependència que en les capes clàssiques apuntava perillosament cap a la base de dades.

Arquitectura Client-Servidor

Contingut

El model client-servidor

Model de dos nivells (2-tier)

Model de tres nivells (3-tier)

Thin client vs thick client

L'evolució cap a la web

Avantatges i inconvenients

Errors Comuns i Consells

Exercicis

Solucions

Conclusió

Curs d'Arquitectura d'Aplicacions

Mòdul 1: Fonaments de l'Arquitectura d'Aplicacions

Mòdul 2: Principis i Tàctiques de Disseny

Mòdul 3: Estils i Patrons Arquitectònics

Mòdul 4: Arquitectures Distribuïdes i Microserveis

Mòdul 5: Arquitectures Dirigides per Esdeveniments i Missatgeria

Mòdul 6: Disseny Dirigit pel Domini (DDD)

Mòdul 7: Dades i Persistència

Mòdul 8: Arquitectura al Núvol i Desplegament

Mòdul 9: Qualitat, Seguretat i Observabilitat

Mòdul 10: Evolució, Governança i Casos Pràctics