Contenido del curso
Crea tu primer app con SSR
- 6

Proyecto Helix Eye: de CSR a SSR
14:50 min - 7

Webpack para servidor Node con TypeScript
16:19 min - 8

Servidor Express con TypeScript desde cero
08:48 min - 9

Función template HTML dinámica en TypeScript
06:52 min - 10

renderToString y StaticRouter en el servidor
10:35 min - 11

Hidratación de React con hydrateRoot en SSR
11:38 min - 12

Prefetching de API en el servidor con Axios
13:00 min - 13

Inyectando initialProps del servidor a React
09:19 min - 14

Cómo inyectar estilos de SSR sin flickering
09:56 min
Bonus
Hot Module Replacement con Webpack y Express
Resumen
Activar Hot Module Replacement con Webpack en un servidor Express te permite recargar tu aplicación React al instante mientras desarrollas, sin sacrificar el server-side rendering. Es la pieza que convierte tu motor casero en algo parecido a Create React App o Next.js, ideal si estás construyendo tu propio stack de SSR.
La idea es simple: inyectamos el compilador de Webpack dentro de Express usando middlewares, y dejamos que detecte cambios en caliente. Así obtienes una recarga rápida en desarrollo y un build optimizado en producción, todo desde el mismo servidor.
¿Qué dependencias necesitas para configurar Hot Module Replacement?
Antes de tocar código, instala las piezas que conectan Webpack con Express. Cada una cumple un rol específico dentro del flujo de desarrollo.
- webpack-hot-middleware: habilita el Hot Module Replacement y mantiene la conexión viva con el navegador [02:15].
- webpack-dev-middleware: activa el servidor en modo desarrollo usando el compilador de Webpack directamente.
- react-dev-utils: añade una capa de error visible en el navegador y permite abrir el navegador automáticamente al iniciar.
Instálalas como dependencias de desarrollo y ya tienes la base para construir el middleware que orquesta todo.
¿Qué es un middleware en Express? Es una función que intercepta una petición antes de que llegue a tu servidor. Se ejecuta primero y puede modificar la respuesta, redirigir o, como en este caso, inyectar el compilador de Webpack.
¿Cómo crear el middleware de Webpack para tu servidor?
Dentro de tu carpeta server, crea un directorio middlewares y un archivo webpack-middleware.ts. Ahí vas a importar Webpack, el hot middleware (renombrado como WHM por brevedad), el dev middleware, el ErrorOverlayMiddleware y openBrowser, ambos de react-dev-utils [04:30].
La función que exportes debe hacer tres cosas en orden:
- Abrir el navegador en la URL del servidor usando template strings con el puerto que viene de tu archivo de configuración.
- Crear el compilador de Webpack pasándole la configuración del cliente (
webpack.config.client). - Devolver un arreglo de middlewares listos para que Express los aplique.
El compilador de Webpack es clave porque expone hooks que te permiten reaccionar cuando termina de compilar o cuando falla. Es la misma pieza que usan internamente herramientas como Create React App.
¿Qué opciones lleva el Hot Module Replacement?
Al WHM le pasas el compilador y un objeto de opciones. Estas son las que importan:
log: usaconsole.logpara que veas los eventos en la terminal.path: define la ruta donde se expone el servicio, típicamente/__webpack-hmr.heartbeat: cada cuántos milisegundos el servidor escucha cambios. Un valor de 200 ms funciona bien.
El webpack-dev-middleware recibe el compilador con dos opciones extra: serverSideRender en true y writeToDisk en true, para que los archivos se escriban a disco y la lectura sea más rápida [07:50].
¿Cómo ajustar la configuración de Webpack del cliente?
El middleware solo funciona si tu webpack.config.client.js está preparado para recibir actualizaciones en caliente. Hay dos ajustes obligatorios.
El primero es activar el HotModuleReplacementPlugin que viene incluido en Webpack. Lo declaras solo cuando estás en modo desarrollo, usando una condición sobre process.env.NODE_ENV. Si no es producción, haces plugins.push(new webpack.HotModuleReplacementPlugin()).
El segundo ajuste toca las entries. Webpack necesita saber qué script cliente debe inyectar para escuchar los cambios. Tomas el arreglo de entradas y usas entries.shift() con el string del cliente del hot middleware (que apunta al mismo path que configuraste, por ejemplo /__webpack-hmr con opciones de timeout y reload).
¿Por qué usar shift y no push para las entries? Porque el cliente del Hot Module Replacement debe cargarse antes que el bundle de tu app.
shiftlo coloca al inicio del arreglo y garantiza que la conexión se establezca primero.
También deja configurado el devServer con hot: true, port, y historyApiFallback: true por si manejas routing en el cliente.
¿Cómo diferenciar desarrollo y producción en el servidor?
En el index de tu servidor, importa el webpackMiddleware y crea una variable isDev basada en process.env.NODE_ENV !== 'production'. Con eso decides qué hacer:
- Si
isDevestrue: aplicasapp.use(webpackMiddleware())y dejas que Webpack maneje todo desde memoria y disco. - Si
isDevesfalse: expones la carpetabuildestática como lo hacías antes.
La diferencia es enorme. En producción tú haces el build del cliente manualmente y el servidor lo sirve. En desarrollo, Webpack lo compila al vuelo y lo recarga sin reiniciar nada [12:40].
¿Cómo confirmar que el Hot Module Replacement funciona?
Corre yarn dev, espera a que abra el navegador y revisa la consola. Debe aparecer el mensaje Hot Module Replacement Connected. Para probarlo, edita un componente, por ejemplo cambia el texto de un Hero de "Helix Eye" a "Helix", guarda y observa cómo el cambio aparece sin recargar la página completa.
Con esto cierras el ciclo del Platzi Engine: arrancaste enviando HTML como template, agregaste JavaScript y prefetching, y terminaste con un servidor de desarrollo que recarga al instante. Es, básicamente, un mini clon de Next.js construido pieza por pieza.
¿Ya intentaste integrar Hot Module Replacement en tu propio motor de SSR? Cuéntame en los comentarios qué dependencias usaste y dónde te trabaste.