Si trabajas con Next.js 15 y quieres entender cómo funcionan los React Server Components, aquí vas a ver cómo transformar un componente cliente típico en uno de servidor, mejorando performance y SEO desde el primer render. Es una pieza clave para desarrolladores que ya manejan React y buscan dar el siguiente salto.

Next.js fue el framework pionero en implementar esta funcionalidad gracias a su trabajo conjunto con los ingenieros de Facebook, creadores de React. Y aunque hoy varios frameworks la soportan, pocos la integran tan bien.

¿Qué necesitas para arrancar el proyecto del curso?

El proyecto base vive en el repositorio Curso Next.js 15 del GitHub de Platzi. Al abrirlo en tu editor, encontrarás un setup bastante estándar pero con algunas piezas interesantes que vale la pena revisar antes de tocar código [01:36].

Entre las dependencias destacadas están:

• Next.js en su última versión disponible.
• TypeScript, Prettier y Tailwind para el día a día.
• Postgres como base de datos durante todo el curso.
• Drizzle, un ORM que actúa como capa entre Postgres y el cliente.

El proyecto corre con pnpm y Turbopack viene habilitado por defecto, así que al levantarlo en localhost:3000 verás una interfaz con cartas independientes, cada una pensada para ilustrar un concepto distinto del curso.

¿Qué es Drizzle ORM? Es una capa de abstracción entre tu base de datos Postgres y tu cliente, que te permite escribir queries con TypeScript de forma tipada y segura.

¿Cómo poblar la base de datos con datos iniciales?

Dentro de app/bookmarks existe un script llamado populate que inserta autores y bookmarks de ejemplo. El flujo para dejar todo listo es así [03:14]:

1. Correr pnpm bookmarks:db push para crear las tablas en Postgres.
2. Ejecutar pnpx tsx app/bookmarks/populate para insertar la data semilla.
3. Verificar en pgweb que la información ya esté disponible.

Una vez hecho esto, la página de bookmarks empieza a mostrar contenido real traído desde la base de datos.

¿Cómo identificar si un componente es de cliente o de servidor?

Un truco rápido antes de mirar el código: abre la pestaña Network del navegador y revisa la primera respuesta HTML. Si el contenido dinámico (como una lista de bookmarks) no aparece en ese HTML inicial, sabes que se está cargando del lado del cliente [04:31].

En el código original, la página de bookmarks usa un patrón clásico de React: un componente con "use client", un useEffect que dispara un fetch a una API, un useState que guarda la respuesta y luego un render. Todos esos hooks solo funcionan en cliente, y el useEffect con array vacío garantiza que la carga ocurre únicamente cuando el componente se monta por primera vez.

¿Por qué useEffect solo funciona en el cliente? Porque depende del ciclo de vida del navegador (montaje, render, efectos). El servidor no tiene ese ciclo, así que React no puede ejecutar hooks como useEffect o useState durante el renderizado en servidor.

¿Cómo refactorizar un componente cliente a React Server Component?

La transformación es más sencilla de lo que parece. La idea central es que un Server Component puede ser una función async, lo que te permite hacer await directamente dentro del componente, sin necesidad de hooks [06:12].

Los pasos concretos son:

• Eliminar la directiva "use client" del archivo.
• Convertir el componente en una función async.
• Borrar el useEffect y el useState.
• Hacer el fetch con await y resolver el .json() también con await.
• Aplicar un casting con TypeScript para tipar la respuesta.

Un detalle importante: cuando el fetch sucede en el servidor, las rutas relativas no funcionan. Tienes que pasar la URL absoluta, por ejemplo http://localhost:3000/bookmarks/api, porque el servidor no tiene contexto del origin del navegador [08:45].

¿Cómo confirmar que ahora sí es un Server Component?

Vuelves a la pestaña Network, recargas la página y revisas el HTML de la primera respuesta. Esta vez vas a ver que toda la data de los bookmarks viene incluida desde el primer render, sin esperar a que JavaScript se hidrate y dispare un fetch adicional.

Eso es exactamente lo que hace tan poderosos a los React Server Components: el navegador recibe el HTML ya completo en la primera llamada.

¿Qué ventajas reales aportan los React Server Components?

Mover lógica al servidor no es solo una moda, tiene impacto medible en dos frentes que importan mucho hoy:

• Performance: el usuario ve contenido útil en el primer paint, sin esperar a que el cliente haga fetch después de hidratar.
• SEO y AEO: indexadores como Google, Yahoo y motores de IA generativa reciben el contenido directamente en el HTML, lo que mejora el posicionamiento y la posibilidad de ser citado en respuestas generativas.

Además, al evitar el ciclo de fetch en cliente, reduces waterfalls de red y simplificas el código: menos hooks, menos estados intermedios, menos puntos donde algo puede fallar.

Next.js no se detiene aquí. En la siguiente clase verás cómo conectar bases de datos directamente desde Server Components, sin pasar por una API intermedia. ¿Ya migraste algún componente cliente a servidor en tu proyecto? Cuéntame en los comentarios cómo te fue.