Componentes del servidor React: la arquitectura de Zero-Bundle

Durante 10 años, el ecosistema React se desvió hacia “Todo del lado del cliente”. Creamos aplicaciones masivas de una sola página (SPA). Obtuvimos datos en useEffect. Mostramos 10 hilanderos mientras se resolvían las cascadas. Y enviamos 500 KB de JavaScript a un usuario con una conexión 3G en Brasil, preguntándonos por qué la “Conversión” era baja.

React Server Components (RSC) es la corrección. No es sólo una característica. Es un cambio arquitectónico fundamental que mueve el centro de gravedad de regreso a donde pertenece: el centro de datos.

En Maison Code Paris, hemos migrado plataformas masivas de comercio electrónico a Next.js App Router. ¿El resultado? 40% menos JavaScript, Largest Contentful Paint (LCP) 2 veces más rápido y una experiencia de desarrollador que parece hacer trampa.

Por qué Maison Code habla de esto

En Maison Code Paris, actuamos como la conciencia arquitectónica de nuestros clientes. A menudo heredamos stacks “modernos” construidos sin una comprensión fundamental de la escala.

Discutimos este tema porque representa un punto de inflexión crítico en la madurez de la ingeniería. Implementarlo correctamente diferencia un MVP frágil de una plataforma resistente de nivel empresarial.

Por qué Maison Code apuesta por RSC

No perseguimos cada nuevo marco. Perseguimos LTV del cliente. RSC es la primera arquitectura que alinea el rendimiento técnico con los objetivos comerciales:

• SEO: entrega HTML perfecta para rastreadores (a Google Bot le encanta RSC).
• Conversión: Interacciones más rápidas para “Agregar al carrito” a través de la interfaz de usuario optimista.
• Sostenibilidad: Menor consumo de batería en los dispositivos de los usuarios al descargar la computación a la nube. Capacitamos a todas nuestras agencias asociadas en esta pila porque es el futuro del Comercio de Alto Rendimiento.

El modelo mental: el servidor como árbol de componentes

En el viejo mundo (Directorio de páginas o Create-React-App), el Servidor enviaba HTML y el Cliente “hidrataba” la funcionalidad clave. En el mundo RSC, React se ejecuta en el servidor.

Cuando un usuario solicita /producto/123:

1. El servidor muestra “ProductPage”.
2. Ejecuta await db.query().
3. Resuelve los datos.
4. Serializa el resultado en un formato especial (Protocolo de vuelo).
5. Transmite esto al navegador.
6. El navegador muestra la interfaz de usuario.

Fundamentalmente: El código del componente del servidor nunca sale del servidor. Si importa moment.js (200 KB) en un componente de servidor para formatear una fecha, el usuario descarga 0 KB del mismo. Simplemente ven el texto “23 de noviembre de 2025”.

Obtención de datos: Muerte de useEffect

La era de los “Loading Spinners” causados por la lógica del lado del cliente ha terminado. Ya no creamos rutas API solo para alimentar nuestra propia interfaz.

El patrón antiguo (búsqueda del cliente):

// Componente del cliente
función Producto() {
  const [datos, setData] = useState(nulo);
  utilizarEfecto(() => {
    fetch('/api/product').then(res => res.json()).then(setData);
  }, []);
  
  si (!datos) devuelve <Spinner />;
  devolver <div>{datos.nombre}</div>;
}

El nuevo patrón (RSC):

// Componente del servidor
importar {db} desde '@/lib/db';

exportar la función asíncrona predeterminada ProductPage() {
  // Acceso directo a la BD. Seguro. Rápido.
  datos constantes = esperar db.product.findFirst();
  
  devolver <div>{datos.nombre}</div>;
}

Esto se ejecuta en el backend. Los datos esperan al usuario, no al revés.

Interactividad: la directiva “Usar cliente”

Pero el HTML estático es aburrido. Necesitamos botones “Agregar al carrito”. Reintroducimos la interactividad utilizando Componentes del cliente. Marcas un archivo con 'usar cliente'. Esto le dice a Next.js: “Incluya este archivo en el paquete de JavaScript”.

Patrón de composición: La estrategia “Punto”. No convierta toda la página en un componente del cliente. Haga los hojas Componentes del Cliente.

// Componente del servidor (diseño)
exportar la función asíncrona predeterminada Page() {
  producto constante = esperar db.product.findFirst();
  
  regresar (
    <div>
      <h1>{product.title}</h1> {/* Tamaño del paquete cero */}
      <PriceDisplay value={product.price} /> {/* Tamaño del paquete cero */}
      <AddToCartButton id={product.id} /> {/* Componente del cliente (interactivo) */}
    </div>
  );
}

Acciones del servidor: mutaciones de tipo seguro

¿Cómo enviamos formularios? ¿Rutas API? ¿Axios? ¿DESCANSO? No. Acciones del servidor. Escribimos una función que se ejecuta en el servidor y la pasamos como accesorio al formulario.

// acciones.ts
'usar servidor'

exportar función asíncrona addToCart(formData: FormData) {
  const IdProducto = formData.get('IdProducto');
  espere db.cart.create({productId});
  // Dile al caché local que se actualice
  revalidatePath('/carro');
}

// Botón.tsx
importar { addToCart } desde './actions';

función de exportación AddToCartButton() {
  regresar (
    <formulario acción={addToCart}>
      <botón tipo="enviar">Agregar</botón>
    </formulario>
  )
}

Esto funciona sin JavaScript habilitado (mejora progresiva). Si se carga JS, Next.js intercepta el envío y efectivamente realiza una llamada API. Pero se siente como llamar a una función.

UI optimista: useOptimistic

Cuando el usuario hace clic en “Agregar”, queremos comentarios instantáneos. No queremos esperar el viaje de ida y vuelta del servidor. RSC presenta “useOptimistic”.

'usar cliente'
importar {useOptimistic} desde 'reaccionar';

función de exportación LikeButton({ likeCount, action }) {
  const [optimisticLikes, addOptimisticLike] = useOptimistic(
    como contar,
    (estado, nuevoMe gusta) => estado + 1
  );

  regresar (
    <botón al hacer clic={async() => {
        agregarOptimisticLike(1); // Actualización inmediata de la interfaz de usuario
        esperar acción(); // Sincronización en segundo plano del servidor
    }}>
       Me gusta: {optimisticLikes}
    </botón>
  );
}

La jerarquía de almacenamiento en caché

Next.js implementa un almacenamiento en caché agresivo para acelerar los RSC. Comprender esta jerarquía es la parte más difícil de la curva de aprendizaje.

1. Solicitar memorización: si llama a getUser() en el diseño y a getUser() en la página, Next.js lo deduplica. Sólo se ejecuta una vez por solicitud.
2. Caché de datos: el resultado de fetch se almacena en el disco del servidor. Persiste en todas las solicitudes. fetch('...', {siguiente: {etiquetas: ['productos'] } })
3. Caché de ruta completa: el HTML renderizado + la carga útil de vuelo se almacena en caché en el momento de la compilación (generación de sitio estático).
4. Caché del enrutador: el navegador almacena en caché las páginas visitadas en la memoria durante 30 segundos para una navegación instantánea hacia adelante y hacia atrás.

Invalidación: Cuando actualiza un producto, debe llamar a revalidateTag('products') en su acción del servidor. Esto purga la Capa 2 y la Capa 3 al instante.

10. Prerenderizado parcial (PPR)

Estático (SSG) es rápido pero obsoleto. Dynamic (SSR) es nuevo pero lento. Next.js 14 introdujo PPR. Es el patrón “Agujero en el Donut”. El Shell (encabezado, pie de página, barra lateral) se renderiza previamente en el momento de la compilación. El “Precio del Producto” es el agujero. Se carga dinámicamente. El usuario obtiene HTML instantáneo (The Shell) y las partes dinámicas se transmiten 100 ms después. Esto evita la “Pantalla Blanca de la Muerte” durante las consultas a la base de datos.

11. Límites de transmisión y suspenso

RSC divide la página en partes. return <Suspense fallback={<Esqueleto />}><SlowComponent /></Suspense> El servidor envía el encabezado HTTP Transfer-Encoding: fragmentado.

1. Parte 1: <html>...<nav>... <Esqueleto>
2. (DB termina)
3. Parte 2: <script>reemplazar(Esqueleto, RealContent)</script> Este Tiempo hasta el primer byte (TTFB) es fundamental para el SEO y el rendimiento percibido.

13. RSC vs Arquitectura insular (Astro)

Astro popularizó las “Islas” (HTML estático + pequeños agujeros de interactividad). RSC es similar pero diferente.

• Astro: envía 0 JS de forma predeterminada. Hidratar explícitamente <Cliente contador:cargar />.
• RSC: envía 0 JS de forma predeterminada. Hidratar los componentes marcados “usar cliente”. La diferencia es el Enrutador. Next.js tiene un enrutador del lado del cliente (sensación de SPA). Astro utiliza navegación multipágina (sensación clásica). Para el comercio electrónico (donde es vital mantener el estado del carrito a lo largo de la carga de la página), el modelo Next.js/RSC es generalmente superior al modelo MPA puro.

14. Gestión del Estado en un mundo RSC

¿A dónde va Redux? En ningún lugar. No lo necesitas. Si el estado es “Datos del servidor” (Productos, Perfil de usuario), se encuentra en el Componente del servidor (obtenido por solicitud). Si el estado es “Estado de UI” (Modal Abierto, Acordeón Expandido), se encuentra en “useState” dentro de una hoja de Componente del Cliente. Solo utilizamos Estado global (Zustand/Context) para datos de clientes verdaderamente globales: el Carrito y el Token de autenticación. Todo lo demás (90% de las antiguas tiendas Redux) se elimina.

15. Conclusión

Los componentes de React Server son el mayor cambio en el desarrollo frontend desde la introducción de AJAX. Nos permiten construir “MPA (Multi-Page Apps) con alma de SPA”. Obtenemos el SEO, el rendimiento y la simplicidad del renderizado del servidor. Obtenemos la rica interactividad de React.

Para el comercio electrónico a gran escala, donde cada milisegundo de latencia se correlaciona con los ingresos, RSC es la única arquitectura viable para los próximos cinco años.

---

¿Migrar a Next.js?

¿Estás atrapado en una aplicación Create-React-App lenta?

Diseñe su migración con RSC. Contrate a nuestros arquitectos.