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
Viendo ahora - 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
Servidor Express con TypeScript desde cero
Resumen
Montar un servidor con Express y TypeScript te permite combinar la rapidez de un framework minimalista con la seguridad de los tipos estáticos. Aquí aprendes a instalar dependencias, configurar variables de entorno y responder rutas dinámicas, ideal si vienes de Node.js y quieres un proyecto más robusto.
¿Cómo instalar Express con TypeScript en tu proyecto?
Después de tener listo webpack compilando tu código, el siguiente paso es sumar Express como dependencia de producción. La instalación se hace con tu gestor de paquetes y, además, conviene traer los tipados oficiales para aprovechar el autocompletado y la validación.
- Instala Express como dependencia principal con
yarn add express[01:05]. - Suma los tipos como dependencia de desarrollo:
yarn add -D @types/express @types/node[04:10]. - Importa en tu archivo
server.tstanto Express como los tiposRequestyResponse.
¿Por qué usar TypeScript con Express? Porque te avisa de errores antes de mandar el código a producción. Si declaras que tu app es una instancia de Express y le pasas un number, el compilador te detiene en seco.
¿Cómo se ve el código mínimo de un servidor Express en TypeScript?
El esqueleto es directo: importas, instancias, defines una ruta y escuchas en un puerto. Lo importante es tipar correctamente request y response para que el editor te guíe.
typescript import express, { Request, Response } from 'express';
const app: express.Application = express();
app.get('/', (req: Request, res: Response) => { res.send('Hola, mundo'); });
app.listen(3500, () => { console.log('Listening in port http://localhost:3500'); });
Al correr yarn dev y abrir localhost:3500, deberías ver tu mensaje en pantalla [03:30]. Ese es el primer indicador de que el servidor responde.
¿Cómo configurar variables de entorno con dotenv?
Dejar el puerto escrito directamente en el código es mala práctica. Lo correcto es centralizar esos valores en un archivo de configuración que lea las variables de entorno desde tu .env.
La dependencia dotenv se encarga de cargar esas variables al objeto process.env, para que tu aplicación las consuma sin exponerlas en el repositorio.
¿Dónde colocar el archivo de configuración?
La convención más limpia es crear una carpeta config con un index.ts que exporte un objeto con todos los valores que tu app necesita. Así, si mañana cambias un puerto o agregas una clave de API, modificas un solo lugar.
typescript import dotenv from 'dotenv'; dotenv.config();
export const config = { port: process.env.PORT, };
Luego, en tu servidor, reemplazas el número quemado por un template literal que use config.port [05:40]. Pequeño cambio, gran diferencia en mantenibilidad.
¿Qué hace dotenv exactamente? Lee tu archivo
.envy carga cada variable dentro deprocess.env, para que tu código acceda a ellas sin escribir secretos directamente en los archivos fuente.
¿Cómo responder rutas dinámicas con Express?
Un servidor real no responde solo en /. Necesitas capturar cualquier ruta y devolver contenido que cambie según la URL. Express permite hacerlo con el comodín * en el método get.
Dentro del callback, puedes leer req.url y construir una respuesta personalizada. Aquí entra el primer acercamiento al server-side rendering: enviar HTML desde el backend en lugar de solo texto plano.
typescript
app.get('*', (req: Request, res: Response) => {
res.send(<h1>Hola, mundo con ruta ${req.url}</h1>);
});
Si visitas localhost:3500/platzi, verás el H1 mostrando esa ruta. Si entras a /cursos, mostrará /cursos. La respuesta cambia dinámicamente según la petición [07:20].
¿Esto ya es server-side rendering?
Es la versión más primitiva. Devolver una etiqueta <h1> suelta no es suficiente: un SSR completo entrega un documento HTML estructurado, con <head>, <body> y contenido que varía según el estado de la aplicación.
La idea queda sembrada y es la base para construir un renderizado del lado del servidor funcional, donde cada ruta entrega un HTML completo listo para el navegador.
¿Ya probaste levantar tu primer servidor con esta estructura? Cuéntame en los comentarios qué puerto usaste y si te aparecieron errores con los tipos.