Tu motor SSR vs Next.js en práctica

Curso de Server Side Render o SSR con React.js

Contenido del curso

No sé dónde empezar

Fundamentos de SSR

Crea tu primer app con SSR

Bonus

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:008:49

Tu motor SSR vs Next.js en práctica

Curso de Server Side Render o SSR con React.js

Clase 16 de 17

Clase 16 / 17

Recursos

Construir tu propio motor de server-side rendering y compararlo con Next.js revela qué tan cerca puedes llegar de un framework profesional cuando entiendes los fundamentos. Esta comparación práctica está pensada para developers de React que quieren dominar SSR antes de adoptar un framework como Next.js.

¿En qué se diferencia el routing de tu motor SSR frente a Next.js?

El routing es la primera pieza que cambia drásticamente entre ambos enfoques.

En el motor propio, las rutas se sincronizan entre servidor y cliente dentro de Containers/App usando React Router DOM. Tú declaras explícitamente cada ruta y mantienes ambos lados alineados manualmente.

Next.js usa un sistema de file-based routing. Funciona así:

pages/index.tsx se convierte en la ruta home.
pages/galaxias.tsx genera automáticamente /galaxias.
pages/tienda.tsx crea la ruta /tienda.

No declaras rutas, las creas con archivos. Y aquí viene lo interesante: esa convención elimina código repetitivo y reduce errores de sincronización entre servidor y cliente [01:45].

¿Qué es file-based routing en Next.js? Es un sistema donde cada archivo dentro de la carpeta pages se convierte automáticamente en una ruta de la aplicación, sin necesidad de declararla manualmente.

¿Cómo se compara el custom document y el render entre ambos enfoques?

El custom document es donde inyectas estilos, HTML base y configuras el punto de entrada del servidor.

En tu motor, defines un template dentro de la función render del index.tsx. Ahí inyectas el router, recolectas estilos con sheet.collectStyles y devuelves el HTML como string al servidor.

Next.js sigue una filosofía parecida, aunque con su propia abstracción creada por el equipo de Vercel. Usa dos archivos clave:

_app.tsx funciona como tu App principal. Ahí declaras global styles, layouts por defecto, menús y componentes compartidos.
_document.tsx se ejecuta como tarea asíncrona en el servidor. Ahí recolectas estilos, inyectas estado inicial de Redux o haces fetch a una API antes de enviar el HTML al cliente [03:30].

La diferencia es que Next.js no genera el template como string explícito, sino que lo abstrae internamente. Aun así, los puntos de extensión existen y son accesibles cuando necesitas customizar.

¿Cómo manejan el prefetching tu motor SSR y Next.js?

El prefetching permite que la información llegue desde el servidor sin que el cliente espere a ejecutar JavaScript.

En el motor propio, cuando desactivas JavaScript en el navegador y entras a /galaxias, el servidor inyecta la data directamente como un script en el HTML. Hasta que JavaScript se reactiva, los datos quedan en el HTML pero la view no los renderiza completamente [05:10].

Next.js logra algo más sofisticado mediante inyección de código y técnicas de red. No necesitas un loader visible: la información aparece junto con el HTML inicial y los componentes de imagen incluso muestran un placeholder elegante mientras cargan.

¿Qué es prefetching en SSR? Es la técnica de obtener datos desde el servidor antes de enviar el HTML al cliente, de modo que la página llegue con la información ya integrada y no dependa de peticiones posteriores.

La función getInitialProps que implementamos en el motor cumple un rol equivalente al sistema de data fetching de Next.js, aunque con menos optimizaciones automáticas.

¿Qué tan parecida es la arquitectura del bundle generado?

Al revisar la carpeta .next que genera Next.js, encuentras una estructura sorprendentemente parecida a la del motor construido en el curso.

Next.js organiza su output así:

Una capa de caché para información generada dinámicamente.
Configuración de webpack con client development, assets y bundles del servidor.
Técnicas de code splitting avanzadas para reducir el peso enviado al cliente.

Tu motor genera una carpeta dist con bundles equivalentes para cliente y servidor. La diferencia está en el nivel de optimización: Next.js aplica code splitting más agresivo y caché inteligente, pero la arquitectura base es la misma [07:20].

Lograr una estructura tan similar en un solo curso demuestra que los fundamentos de SSR no son magia: son piezas concretas que cualquier developer puede entender y construir.

¿Por qué entender estos fundamentos te ayuda a usar Next.js mejor?

Dominar el motor propio te prepara para resolver problemas reales cuando trabajes con Next.js.

Cuando integres plugins, librerías de estilos o estado global en Next.js, vas a necesitar tocar _app.tsx o _document.tsx. Ahí es donde aplicas exactamente lo mismo que aprendiste construyendo tu motor:

Inyectar props iniciales al servidor.
Manejar peticiones asíncronas antes del render.
Usar el servidor como proxy para esconder endpoints o agregar autenticación.
Interceptar llamadas a nivel servidor para modificar headers o respuestas.
Diagnosticar errores comunes de hidratación o desincronización entre servidor y cliente.

Next.js es un framework recomendado para producción y tienes cursos completos sobre él en Platzi. Pero sin entender qué hace por debajo, cualquier configuración no estándar se vuelve un dolor de cabeza.

¿Has comparado tu propio motor SSR con algún framework? Cuéntame en los comentarios qué diferencias encontraste.

Resumen

¿En qué se diferencia el routing de tu motor SSR frente a Next.js?

El routing es la primera pieza que cambia drásticamente entre ambos enfoques.

Next.js usa un sistema de file-based routing. Funciona así:

pages/index.tsx se convierte en la ruta home.
pages/galaxias.tsx genera automáticamente /galaxias.
pages/tienda.tsx crea la ruta /tienda.

No declaras rutas, las creas con archivos. Y aquí viene lo interesante: esa convención elimina código repetitivo y reduce errores de sincronización entre servidor y cliente [01:45].

¿Qué es file-based routing en Next.js? Es un sistema donde cada archivo dentro de la carpeta pages se convierte automáticamente en una ruta de la aplicación, sin necesidad de declararla manualmente.

¿Cómo se compara el custom document y el render entre ambos enfoques?

El custom document es donde inyectas estilos, HTML base y configuras el punto de entrada del servidor.

En tu motor, defines un template dentro de la función render del index.tsx. Ahí inyectas el router, recolectas estilos con sheet.collectStyles y devuelves el HTML como string al servidor.

Next.js sigue una filosofía parecida, aunque con su propia abstracción creada por el equipo de Vercel. Usa dos archivos clave:

_app.tsx funciona como tu App principal. Ahí declaras global styles, layouts por defecto, menús y componentes compartidos.
_document.tsx se ejecuta como tarea asíncrona en el servidor. Ahí recolectas estilos, inyectas estado inicial de Redux o haces fetch a una API antes de enviar el HTML al cliente [03:30].

La diferencia es que Next.js no genera el template como string explícito, sino que lo abstrae internamente. Aun así, los puntos de extensión existen y son accesibles cuando necesitas customizar.

¿Cómo manejan el prefetching tu motor SSR y Next.js?

El prefetching permite que la información llegue desde el servidor sin que el cliente espere a ejecutar JavaScript.

¿Qué es prefetching en SSR? Es la técnica de obtener datos desde el servidor antes de enviar el HTML al cliente, de modo que la página llegue con la información ya integrada y no dependa de peticiones posteriores.

La función getInitialProps que implementamos en el motor cumple un rol equivalente al sistema de data fetching de Next.js, aunque con menos optimizaciones automáticas.

¿Qué tan parecida es la arquitectura del bundle generado?

Al revisar la carpeta .next que genera Next.js, encuentras una estructura sorprendentemente parecida a la del motor construido en el curso.

Next.js organiza su output así:

Una capa de caché para información generada dinámicamente.
Configuración de webpack con client development, assets y bundles del servidor.
Técnicas de code splitting avanzadas para reducir el peso enviado al cliente.

Lograr una estructura tan similar en un solo curso demuestra que los fundamentos de SSR no son magia: son piezas concretas que cualquier developer puede entender y construir.

¿Por qué entender estos fundamentos te ayuda a usar Next.js mejor?

Dominar el motor propio te prepara para resolver problemas reales cuando trabajes con Next.js.

Inyectar props iniciales al servidor.
Manejar peticiones asíncronas antes del render.
Usar el servidor como proxy para esconder endpoints o agregar autenticación.
Interceptar llamadas a nivel servidor para modificar headers o respuestas.
Diagnosticar errores comunes de hidratación o desincronización entre servidor y cliente.

¿Has comparado tu propio motor SSR con algún framework? Cuéntame en los comentarios qué diferencias encontraste.

Fundamentos de SSR

Por qué React necesita server-side rendering

Problemas reales de las SPAs con JavaScript

Creación y Funcionamiento de una SPA con Create React App

CSR vs SSR: cómo el servidor pinta primero

Ventajas y desventajas del server-side rendering

Crea tu primer app con SSR

Proyecto Helix Eye: de CSR a SSR

Webpack para servidor Node con TypeScript

Servidor Express con TypeScript desde cero

Función template HTML dinámica en TypeScript

renderToString y StaticRouter en el servidor

Hidratación de React con hydrateRoot en SSR

Prefetching de API en el servidor con Axios

Inyectando initialProps del servidor a React

Cómo inyectar estilos de SSR sin flickering

Bonus

Hot Module Replacement con Webpack y Express

Tu motor SSR vs Next.js en práctica

Helix Eye como proyecto de portafolio

Tu motor SSR vs Next.js en práctica

Progreso del curso

Fundamentos de SSR

Crea tu primer app con SSR

Bonus

Recursos

Recursos