Cuando Next.js lanzó App Router, hizo algo que parece técnico pero que es, en esencia, una decisión mental: invirtió el patrón. Antes, cada componente era propiedad del cliente hasta que usted dijera lo contrario. Ahora, cada componente está del lado del servidor hasta que verifique que debe estar del lado del cliente.
Esta inversión es pequeña en sintaxis y enorme en la práctica. Cambia la pregunta que el equipo hace a cada componente. En lugar de asumir que todo se ejecuta en el navegador, justifica por qué algo debería ejecutarse allí.
Para aquellos que vienen de React tradicional, App Router no es solo una carpeta nueva con un enrutador diferente. Es una invitación a repensar dónde debe residir cada pieza de la aplicación. Y esta invitación tiende a desorientar antes de que tenga sentido.
El patrón se ha invertido
En App Router, los diseños y las páginas son componentes del servidor de forma predeterminada. Esto significa que, cuando creas una nueva página, ésta comienza a ejecutarse en el servidor, sin que tú hagas nada. Su código no va al navegador y la búsqueda de datos puede realizarse allí mismo, antes de que salga la respuesta.
La consecuencia inmediata es que muchas cosas que enviarías al cliente ahora permanecen naturalmente en el servidor. La lista de productos, el contenido del artículo, el encabezado con los datos del usuario, todo esto se renderiza antes de llegar, sin costo de JavaScript en el dispositivo.
Cuando necesita interactividad, marca el componente con la directiva "use client". A partir de ese momento, ese componente y lo que representa comienzan a ejecutarse en el navegador, con estado y eventos. Es un límite explícito, no un accidente.
El efecto secundario saludable es que el cliente se convierte en una excepción consciente. No caes en él por inercia, tú eliges cuándo entrar. Si esto todavía suena abstracto, vale la pena revisar qué son los componentes 3 del servidor React antes de continuar.
Cuando el componente debe ser servidor
La pregunta correcta es sobre la naturaleza del trabajo. Si el componente sólo busca y muestra información, tiene todo para ser un servidor. Listados de páginas, contenido de blogs, detalles de pedidos, paneles que solo muestran números: nada de esto necesita que exista el navegador.
Los componentes del servidor destacan a la hora de recuperar datos. Usted consulta al banco directamente, llama a los servicios internos con la baja latencia de los que están dentro de la infraestructura y crea el resultado listo. No necesita una ruta API intermedia solo para que el navegador pueda solicitar los datos, porque el componente ya está en el lado derecho.
También existe la ventaja de mantener el peso fuera del cliente. Bibliotecas de formato pesado, procesamiento de rebajas, manipulación de fechas: si esto se ejecuta en el servidor, nunca ingresa al paquete que descarga el usuario. El paquete se reduce y el dispositivo del usuario te lo agradece.
La regla mental que funciona es la siguiente: empieza por hacerte cargo del servidor. Sólo acérquese al cliente cuando exista una necesidad concreta de interacción. Resistir la tentación de calificar todo como cliente es la mitad de la batalla.
Cuando el componente debe estar del lado del cliente
No todo cabe en el servidor y tratar de forzar esto genera frustración. Hay un conjunto claro de situaciones que requieren clientes, y reconocerlas rápidamente evita perder tiempo.
El primero es el estado que cambia en la pantalla. Un contador, una pestaña seleccionada, un menú que se abre y se cierra: cualquier cosa que necesite recordar algo entre interacciones vive en el cliente. El segundo es el evento de usuario. Hacer clic, escribir, arrastrar, cualquier manipulación directa ocurre en el navegador, porque ahí es donde está el usuario.
El tercero es el uso de los recursos del navegador. El acceso al almacenamiento local, la geolocalización, el tamaño de la ventana de lectura, cualquier cosa que solo exista en el entorno del navegador requiere que el componente esté del lado del cliente. No hay forma de ejecutar esto en el servidor, simplemente porque el servidor no tiene ventana ni mouse.
El detalle que abre la mente del equipo es entender que esto no es todo o nada. Puede tener una página de servidor que muestre un pequeño componente de cliente solo para el botón interactivo. El resto de la página sigue siendo ligera y representada en el servidor. La interactividad se aísla donde realmente importa, en lugar de contaminar toda la página.
La búsqueda de datos cambia de ubicación
En el modelo antiguo, la obtención de datos era un ritual bien conocido: el componente se ensamblaba, desencadenaba un efecto, llamado API, se ocupaba de los estados de carga y error, y actualizaba el estado cuando llegaba la respuesta. Funcionó, pero fue detallado y lleno de trampas.
Con los componentes del servidor, la obtención de datos vuelve a ser sencilla. Obtiene los datos durante el renderizado en el servidor, espera el resultado allí mismo y devuelve la interfaz lista para usar. Añade mucho del baile de los estados de carga al cliente, porque los datos ya llegan con la página.
Esto simplifica el código y mejora la experiencia al mismo tiempo, lo cual es poco común. El usuario recibe el contenido ya rellenado, sin esa secuencia de pantallas vacías parpadeando mientras se carga cada parte. Y cuando necesita una carga progresiva, el marco ofrece transmisión para entregar fragmentos a medida que estén listos, un tema en el que vale la pena profundizar almacenamiento en caché y transmisión en Next.js.
La mutación de datos sigue una lógica similar. En lugar de crear una API completa para cada formulario, puede utilizar Acciones del servidor, funciones que se ejecutan en el servidor y se llaman directamente desde la interfaz. Esto cierra el ciclo: lectura y escritura cerca de la fuente, sin capas que existieran solo para servir al navegador.
##El cambio de mentalidad que afronta el equipo
La parte difícil de App Router no es la sintaxis. Es desaprender el reflejo de que todo se ejecuta en el navegador. Los equipos con experiencia en React tienden a marcar componentes como cliente por costumbre, porque así es como aprendieron, y luego pierden gran parte de las ganancias.
El síntoma clásico es el "use client" en la parte superior de casi todos los archivos. Cuando esto sucede, la aplicación vuelve a ser un SPA disfrazado, con el peso de antes y la nueva complejidad encima. El equipo necesita interiorizar que cada cita con un cliente es una decisión que hay que justificar, no un patrón que hay que copiar.
También hay un ajuste mental sobre dónde se ejecuta el código. Pensar que parte del árbol se ejecuta en el servidor y parte en el navegador requiere prestar atención a lo que cada lado puede hacer. Intentar utilizar una función del navegador en un componente del servidor genera errores y estos tropiezos iniciales son una parte normal del aprendizaje.
Una vez que se reduce el dinero, el modelo se vuelve intuitivo. La pregunta de si esta necesidad de interacción se vuelve automática y el equipo comienza a diseñar interfaces livianas de forma predeterminada. Pero llegar allí requiere un liderazgo técnico dispuesto a revisar pacientemente el código y corregir viejos reflejos.
Si está considerando adoptar App Router en su equipo, trate la curva de aprendizaje como parte del proyecto, no como un detalle. Dé tiempo para que el equipo cometa errores, revise y ajuste la intuición. Para ubicar esta elección dentro de una decisión arquitectónica más amplia, pase a el movimiento del servidor primero como una decisión arquitectónica.
Lea también
- ¿Qué son los componentes del servidor React y por qué la lógica regresa al servidor?
- Caché y streaming en Next.js: el rendimiento se convirtió en una decisión arquitectónica
- Acciones del servidor en Next.js: mutaciones sin mantener una API solo para eso
- Servidor primero: la decisión arquitectónica para quitarle peso al navegador
- Buenas Prácticas de Internacionalización (i18n) en React y Next.js en 2025
- Microfrontends: cuándo y por qué adoptar en proyectos escalables