Si sigues las noticias del mundo de React, probablemente hayas oído hablar de Server Components, una tecnología que está provocando un gran debate en la comunidad. Algunos lo llaman una revolución en el desarrollo de front-end, otros lo llaman una complicación innecesaria.
¿Qué son los componentes del servidor?
Server Components (componentes del servidor) es un nuevo tipo de componentes de React que se renderizan exclusivamente en el servidor y nunca llegan al navegador. ¿Suena raro?
Veamos un ejemplo sencillo:
// ServerComponent.js (componente del servidor)
async function BlogPost({ id }) {
// Este código se ejecuta SOLO en el servidor
const post = await db.posts.findById(id);
return (
<article>
<h1>{post.title}</h1>
<p>{post.content}</p>
</article>
);
}Ten en cuenta: ¡accedemos directamente a la base de datos en el componente! Antes esto era imposible: había que crear puntos finales de API, hacer solicitudes de búsqueda, procesar estados de carga... Ahora todo esto se puede hacer directamente en el componente.
¿En qué se diferencian los componentes del servidor de los componentes normales?
Comparemos tres tipos de componentes para entender la diferencia:
1. Componentes del cliente
Estos son los componentes habituales de React que ya conoces. Son:
Se ejecutan en el navegador
Pueden usar hooks (useState, useEffect, etc.)
Pueden procesar eventos (onClick, onChange)
Aumentan el tamaño del paquete JavaScript
'use client'; // Indicamos claramente que este es un componente del cliente
function Counter() {
const [count, setCount] = useState(0);
return (
<button onClick={() => setCount(count + 1)}>
Clicked {count} times
</button>
);
}2. Server Components (componentes del servidor)
Un nuevo tipo de componentes que:
Renderizado SOLO en el servidor
No se incluyen en el paquete JavaScript
Pueden trabajar directamente con bases de datos y el sistema de archivos
NO pueden usar ganchos de estado o API del navegador
NO pueden procesar eventos
// Por defecto, en Next.js 13+ todos los componentes son de servidor
async function UserProfile({ userId }) {
// ¡El acceso directo a la base de datos es el código del servidor!
const user = await db.users.findById(userId);
const posts = await db.posts.findByUser(userId);
return (
<div>
<h2>{user.name}</h2>
<p>{posts.length} постов</p>
</div>
);
}3. Server-Side Rendering (SSR)
¡No confundas Server Components con SSR! Son cosas diferentes:
SSR — renderiza HTML en el servidor, pero todo el JavaScript todavía se carga en el navegador para la "hidratación"
Server Components — no envían su JavaScript al navegador en absoluto, solo el resultado final
¿Por qué es necesario?
Problema n.º 1: paquetes JavaScript inflados
Imagina: estás mostrando una lista de productos con descripciones de markdown. Antes había que incluir una biblioteca para analizar el markdown en el paquete del cliente:
// El enfoque antiguo: la biblioteca se incluirá en el navegador
import { marked } from 'marked'; // ~50kb
function Product({ description }) {
return <div dangerouslySetInnerHTML={{ __html: marked(description) }} />;
}Con Server Components, la biblioteca permanece en el servidor:
// Nuevo enfoque: la biblioteca NO entra en el navegador
import { marked } from 'marked';
async function Product({ productId }) {
const product = await db.products.findById(productId);
const html = marked(product.description);
return <div dangerouslySetInnerHTML={{ __html: html }} />;
}Resultado: ¡el navegador recibe HTML listo sin 50 kb adicionales de JavaScript!
Problema n.º 2: Cascada de consultas
Problema clásico de las aplicaciones React:
// Mal: una cascada de consultas
function Dashboard() {
const { user } = useUser(); // Solicitud 1
if (!user) return <Loader />;
return <UserPosts userId={user.id} />; // La solicitud 2 solo comenzará después de la 1
}Con Server Components, las consultas se ejecutan en paralelo en el servidor:
async function Dashboard() {
// ¡Ambas solicitudes se ejecutarán en paralelo!
const [user, posts] = await Promise.all([
db.users.getCurrent(),
db.posts.getRecent()
]);
return (
<div>
<UserInfo user={user} />
<PostsList posts={posts} />
</div>
);
}Problema n.º 3: Seguridad
Los componentes del servidor le permiten almacenar secretos en el servidor:
// Seguro: la clave API nunca llegará al navegador
async function WeatherWidget({ city }) {
const response = await fetch(
`https://api.weather.com/data?key=${process.env.WEATHER_API_KEY}&city=${city}`
);
const data = await response.json();
return <div>Температура: {data.temp}°C</div>;
}Ejemplo práctico: plataforma de blog.
Veamos una aplicación real que combina ambos tipos de componentes:
// app/posts/[id]/page.js - componente del servidor
async function PostPage({ params }) {
// Los datos se cargan en el servidor
const post = await db.posts.findById(params.id);
const comments = await db.comments.findByPost(params.id);
return (
<article>
<h1>{post.title}</h1>
<PostContent content={post.content} />
{/* Клиентский компонент для интерактивности */}
<CommentForm postId={post.id} />
{/* Серверный компонент для отображения */}
<CommentsList comments={comments} />
</article>
);
}
// components/CommentForm.js - componente del cliente
'use client';
function CommentForm({ postId }) {
const [text, setText] = useState('');
const handleSubmit = async (e) => {
e.preventDefault();
await fetch('/api/comments', {
method: 'POST',
body: JSON.stringify({ postId, text })
});
setText('');
};
return (
<form onSubmit={handleSubmit}>
<textarea
value={text}
onChange={(e) => setText(e.target.value)}
/>
<button type="submit">Отправить</button>
</form>
);
}Ventajas de los componentes del servidor
✅ Menos JavaScript en el navegador
Solo las partes interactivas de la aplicación se cargan en el navegador. Todo lo demás está en el servidor.
✅ Acceso directo a los recursos del servidor
La base de datos, el sistema de archivos, las API internas: todo está disponible directamente desde los componentes.
✅ Mejor rendimiento
Los datos se cargan cerca de la fuente (servidor → base de datos más rápido que el navegador → API → base de datos).
✅ Separación automática de códigos
No es necesario pensar en la división de código: los componentes del servidor no se incluyen automáticamente en el paquete.
✅ Seguridad mejorada
Las claves API, los tokens y la lógica de los procesos empresariales permanecen en el servidor.
Desventajas y dificultades
❌ Curva de aprendizaje pronunciada
Es necesario entender qué componente se ejecuta en cada lugar. Los principiantes a menudo se confunden:
// ❌ Error: Server Component no puede usar useState
async function UserProfile() {
const [isOpen, setIsOpen] = useState(false); // ¡Ups!
// ...
}
// ✅ Correcto: llevamos la interactividad al Client Component
async function UserProfile() {
const user = await db.users.getCurrent();
return <ProfileCard user={user} />; // ProfileCard puede ser cliente
}❌ Ecosistema limitado
Por el momento, solo hay soporte completo en Next.js 13+. Otros marcos apenas están comenzando a adoptar esta tecnología.
❌ Dificultades con la depuración
Cuando parte del código se ejecuta en el servidor y parte en el navegador, la depuración se vuelve más difícil.
❌ Más carga en el servidor
Cada solicitud requiere renderización en el servidor. Hay que pensar en el almacenamiento en caché y el escalado.
¿Cuándo usar Server Components?
Ideal para:
Páginas con contenido dinámico — blogs, noticias, catálogos de productos
Paneles con una gran cantidad de datos — análisis, informes, estadísticas
Páginas críticas de SEO — todo el contenido se renderiza en el servidor y está disponible para los motores de búsqueda
Aplicaciones con dependencias pesadas — markdown, resaltado de código, procesamiento de imágenes
No apto para:
Interfaces altamente interactivas — editores, juegos, dibujos
Aplicaciones sin conexión — PWA que funcionan sin servidor
Aplicaciones con actualizaciones en tiempo real — chats, edición conjunta
¿Cómo empezar a experimentar?
La forma más fácil de probar Server Components es crear un nuevo proyecto en Next.js 13+:
npx create-next-app@latest my-app
cd my-app
npm run devEn Next.js 13+ con App Router, todos los componentes son del lado del servidor de forma predeterminada. Para hacer que el componente sea del lado del cliente, simplemente añade 'use client' al principio del archivo.
Consejos prácticos.
1. Empieza con los componentes del servidor
Haz que el componente sea cliente solo cuando sea realmente necesario (estado, eventos, API del navegador).
2. Utiliza «client boundary»
Divide la interactividad en pequeños componentes separados:
// Componente del servidor
async function ProductPage({ id }) {
const product = await db.products.findById(id);
return (
<div>
<h1>{product.name}</h1>
<p>{product.description}</p>
{/* Только кнопка клиентская */}
<AddToCartButton productId={product.id} />
</div>
);
}3. Almacena los datos en caché
Next.js almacena automáticamente en caché las solicitudes de fetch, pero puedes controlar esto:
// Almacenamiento en caché durante 1 hora
const data = await fetch('https://api.example.com/data', {
next: { revalidate: 3600 }
});¿Vale la pena estudiarlo? Definitivamente sí, especialmente si trabajas con Next.js o planeas hacerlo. Pero recuerda: un buen desarrollador sabe cuándo usar una nueva tecnología y cuándo atenerse a soluciones probadas.
Componentes del servidor, ganchos, rendimiento, arquitectura de aplicaciones: esto y mucho más se puede aprender en Codice¡Analizamos los temas en detalle, desde los conceptos básicos hasta los avanzados, y consolidamos los conocimientos con tareas prácticas!
💬 Y si necesitas ayuda o quieres hablar sobre el código, ya tenemos más de 2000 personas afines en activo canal de Telegram, donde se ayudan mutuamente, comparten experiencias y discuten las tecnologías actuales.
Únete a Kodik — ¡Aprende de forma eficaz, practica con regularidad y crece profesionalmente! 🎯
¡Buena suerte con el aprendizaje de Server Components! Recuerda: la mejor manera de entender la tecnología es probarla en la práctica. ¡Crea un pequeño proyecto y experimenta! 💻