NUCBA - Formación profesional digital

El problema con React Server Components

React Server Components llegó con la promesa de mejorar todo: performance, SEO, experiencia de usuario. Pero después de trabajar con RSC en varios proyectos, la realidad es más compleja.

Vi equipos que refactorizaron aplicaciones completas para usar RSC y terminaron con más problemas que beneficios. También vi casos donde RSC resolvió problemas reales de manera elegante.

La diferencia está en saber cuándo aplicarlo.

Cuándo RSC realmente vale la pena

Apps con mucho contenido estático

Si tu app muestra principalmente contenido que no cambia por usuario - blogs, documentación, landing pages - RSC es oro puro.

// Perfecto para RSC
async function BlogPost({ slug }) {
  const post = await fetchBlogPost(slug);
  
  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );
}

El contenido se renderiza en el servidor, llega al browser ya listo, y el SEO es perfecto sin configuración extra.

Dashboards con datos pesados

Tenés un dashboard que muestra métricas, reportes, tablas con miles de filas. En lugar de mostrar un spinner mientras se cargan los datos, RSC puede enviar la página ya renderizada.

// Dashboard que se beneficia de RSC
async function MetricsDashboard() {
  const [users, sales, traffic] = await Promise.all([
    fetchUsers(),
    fetchSales(),
    fetchTraffic()
  ]);
  
  return (
    <div className="dashboard">
      <MetricCard title="Users" value={users.count} />
      <MetricCard title="Sales" value={sales.total} />
      <SalesChart data={sales.chart} />
      <TrafficTable data={traffic.data} />
    </div>
  );
}

Apps con navegación compleja

Cuando tenés múltiples niveles de navegación y querés que cada página cargue rápido sin perder el estado de la navegación.

Cuándo RSC es overkill (y te va a traer problemas)

SPAs interactivas

Si tu app es principalmente interactiva - editores, herramientas de diseño, juegos - RSC no te aporta nada.

// MAL uso de RSC - esto debería ser client-side
function TextEditor() {
  const [content, setContent] = useState('');
  
  return (
    <textarea 
      value={content}
      onChange={(e) => setContent(e.target.value)}
    />
  );
}

En estos casos, el round-trip al servidor para cada interacción mata la experiencia.

Apps con estado complejo del lado cliente

Si manejás mucho estado local, contextos globales, o integrás con muchas APIs client-side, RSC va a ser más problema que solución.

// Complejo de manejar con RSC
function ShoppingCart() {
  const [items, setItems] = useContext(CartContext);
  const [user] = useAuth();
  const [preferences] = useUserPreferences();
  
  // Lógica compleja de estado cliente
  return <CartUI items={items} />;
}

Equipos sin experiencia en SSR

Si tu equipo nunca trabajó con server-side rendering, empezar con RSC va a ser frustrante. Primero dominá Next.js tradicional con getServerSideProps.

Señales de que estás usando RSC mal

Tenés que usar 'use client' en todos lados Si la mayoría de tus componentes necesitan esa directiva, probablemente RSC no era la solución.

Los tiempos de respuesta empeoraron Si las páginas tardan más en cargar que antes, revisá si no estás haciendo demasiado trabajo en el servidor.

Debugging se volvió un infierno Cuando no sabés si un error viene del servidor o del cliente, algo está mal.

El bundle size no se redujo Uno de los beneficios de RSC es enviar menos JavaScript al cliente. Si tu bundle sigue igual de pesado, no lo estás aprovechando.

Migración gradual: la estrategia que funciona

No refactorices toda tu app de una. Empezá con páginas específicas:

Identificá páginas estáticas: páginas de contenido, landing pages
Convertí una página por vez: empezá con la más simple
Medí el impacto: tiempo de carga, métricas de usuario
Expandí gradualmente: solo si los resultados son positivos

Herramientas que te van a ayudar

# Para medir performance
npm install @vercel/speed-insights

# Para debugging RSC
npm install @next/bundle-analyzer

React Developer Tools: la extensión ahora muestra qué componentes son server vs client

Vercel Analytics: si desplegás en Vercel, te muestra métricas reales de performance

Lighthouse: seguí midiendo Core Web Vitals antes y después de implementar RSC

El costo real de RSC

RSC no es gratis. Viene con:

Complejidad de debugging: errores que pueden venir del server o client
Restricciones de desarrollo: no podés usar hooks en server components
Curva de aprendizaje: tu equipo necesita tiempo para adaptarse
Overhead de infraestructura: necesitás un servidor que maneje el rendering

Antes de implementar RSC, preguntate: ¿los beneficios justifican estos costos para tu caso específico?

Preguntas frecuentes

¿RSC reemplaza a Next.js tradicional? No. RSC es una evolución que se integra con Next.js. Podés usar ambos enfoques en la misma app.

¿Puedo usar RSC con otras librerías de estado? Sí, pero con limitaciones. Redux, Zustand y similares funcionan solo en client components.

¿RSC mejora automáticamente el SEO? Sí, porque el contenido se renderiza en el servidor. Pero si tu app ya tenía buen SSR, el impacto va a ser mínimo.

React Server Components: cuándo usarlos sin arruinar tu app