Separar servidor de cliente: el patrón de 2026

Cerramos el nivel subiendo al plano donde todo encaja. Las cuatro lecciones anteriores fueron, en el fondo, una sola tesis vista desde cuatro ángulos: el estado de servidor es una cache, y una cache no es un store. La consecuencia práctica de tomarse eso en serio es una de las decisiones de arquitectura más rentables que puedes tomar en 2026: sacar del estado global todo lo que en realidad era servidor disfrazado, dárselo a una cache que sabe tratarlo, y quedarte con un estado de cliente tan pequeño y tan claro que por fin se entiende de un vistazo. Menos estado global, menos bugs. Este es el patrón dominante de la industria, y esta lección explica por qué ganó.

Dos clases, dos herramientas

El error que este nivel combate era meterlo todo en un cajón: estado de cliente y de servidor revueltos en el mismo store global. La disciplina que propone es partir por la propiedad, la pregunta que ha recorrido las cuatro lecciones: quién es dueño de la verdad.

El estado de cliente es el que posees: lo crea y lo muta tu aplicación, y tu última escritura es la verdad. El menú abierto, el paso del asistente, el tema oscuro. El estado de servidor es el que solo lees: su dueño vive en otra máquina y tu copia envejece sola. El perfil, el catálogo, los pedidos. Dos clases con dos naturalezas, y por tanto dos herramientas.

Meter la segunda clase en la primera es el error de categoría del que partió el nivel. Y respetar la frontera es más sencillo de lo que parece: un componente puede leer de una cache y de un store a la vez sin mezclarlos, porque cada dato vive donde su naturaleza manda.

function Pantalla() {
  // servidor: solo lo leemos, vive en una cache
  const { data: pedidos } = useQuery({ queryKey: ["pedidos"], queryFn: traerPedidos });

  // cliente: lo poseemos, vive en un store ligero
  const temaOscuro = useUI((s) => s.temaOscuro);

  return <Lista pedidos={pedidos} oscuro={temaOscuro} />;
}

flowchart TD
E[estado de la app] --> C[cliente: lo que posees]
E --> S[servidor: lo que solo lees]
E --> U[url: estado navegable]
E --> F[formularios: borrador efimero]
C --> CT[useState Zustand Jotai]
S --> ST[TanStack Query SWR]
style C fill:#a6e3a1,color:#11111b
style S fill:#fab387,color:#11111b
style U fill:#89b4fa,color:#11111b
style F fill:#cba6f7,color:#11111b

Lo que queda cuando el servidor se va

La sorpresa de aplicar esta separación a una app real es cuánto encoge el store global. Cuando extraes cada dato que en verdad vino de una petición HTTP, lo que queda casi nunca justifica la maquinaria pesada que tenías montada.

Buena parte de lo que la gente guardaba en Redux nunca fue estado de cliente: era servidor de paso, y con él se iban también los reducers, thunks y acciones que solo existían para leerlo y sincronizarlo. Al sacarlo, no pierdes lógica de dominio; tiras una cache casera que nunca debió estar ahí.

Lo que sobrevive es estado de cliente genuino, y suele ser poco: preferencias de UI, selección actual, un asistente a medias, un modal abierto. Tan poco que a menudo un store ligero —Zustand, Jotai, o incluso useState elevado— basta y sobra. Esta es, medida por el ecosistema, una de las razones de la caída de Redux entre 2020 y 2026: no es que empeorara, es que le quitaron el trabajo que en realidad nunca le correspondió.

El patrón se ve mejor con números que con adjetivos. Una app de comercio típica guardaba en el store el catálogo, el carrito remoto, los pedidos, el perfil y media docena de listas: todo servidor. Al migrarlo a una cache, el store baja de decenas de slices a dos o tres piezas de cliente puro. No es que Redux fuera pesado; es que cargaba con equipaje ajeno.

Menos estado global, menos bugs

La promesa menos bugs no es un eslogan, tiene un mecanismo. Los bugs más difíciles del estado global son de sincronización: dos copias del mismo dato que discrepan, una vista que muestra lo viejo porque nadie la avisó del cambio, un dato que quedó obsoleto sin que nada lo revalidara.

Y resulta que esa familia entera nace, casi siempre, de gestionar a mano una cache dentro de un store que no sabía que lo era. El bug no estaba en tu lógica; estaba en haber puesto un dato prestado donde solo caben los propios.

Cuando entregas el estado de servidor a una cache de verdad, esos bugs no se arreglan: dejan de ser posibles. La deduplicación, la revalidación al reenfocar y la invalidación tras escribir dejan de ser código tuyo que puede fallar y pasan a ser garantías de la librería. Reduces la superficie de estado global mutable —la fuente número uno de bugs de estado— y con ella desaparece la clase de errores que vivía en esa superficie.

El servidor que ni siquiera cruza

Hay un giro final que empuja el patrón aún más lejos: los componentes de servidor. Con los React Server Components y el hook use, buena parte del estado de servidor ni siquiera cruza al cliente como estado; se resuelve en el servidor y llega ya renderizado, o se pasa como promesa que el cliente consume con Suspense.

El estado de cliente encoge todavía más, porque datos que antes había que traer, cachear y pintar en el navegador ahora nunca salen del servidor. El modelo mental no cambia —sigue siendo una cache de una verdad remota—, solo se mueve dónde vive la cache. La dirección del viaje es inequívoca: cada año, menos estado en el cliente.

// Componente de servidor: el dato se resuelve aqui y nunca cruza como estado
async function Pedidos() {
  const pedidos = await traerPedidos();   // ocurre en el servidor
  return <Lista pedidos={pedidos} />;
}