2e:I[551045,["/_next/static/chunks/37jzp1hshrgtb.js","/_next/static/chunks/1pama84ylxppg.js","/_next/static/chunks/3w2l5ufqtj8b3.js","/_next/static/chunks/3-wh-nchkz61t.js","/_next/static/chunks/07fglzm9mxkbu.js","/_next/static/chunks/1t51j92evd9j3.js"],"SearchCommand"] 37:I[697848,["/_next/static/chunks/37jzp1hshrgtb.js","/_next/static/chunks/1pama84ylxppg.js","/_next/static/chunks/3w2l5ufqtj8b3.js","/_next/static/chunks/3-wh-nchkz61t.js","/_next/static/chunks/07fglzm9mxkbu.js","/_next/static/chunks/1t51j92evd9j3.js"],"BlogSidebar"] 38:T2474,Hay decisiones en el desarrollo de software que parecen triviales hasta que te explotan en la cara. Qué package manager usar es una de esas. Yo las pagué todas: proyectos con node_modules de 4GB, deploys que fallaban por conflictos de versiones que "no deberían existir", monorepos que tardaban 8 minutos en instalarse en CI. Todo eso me hizo obsesionarme con este tema. Así que vamos directo al hueso: **pnpm vs npm vs yarn vs bun** — qué son, qué hacen diferente, cuándo usar cada uno, y cuál ganó mi corazón (y mi `.zshrc`). --- ## Un poco de historia para que entiendas por qué existe este caos npm llegó en 2010 pegado a Node.js. Era la única opción y, francamente, era un desastre. El `node_modules` flat que conocemos hoy ni existía — en las versiones viejas tenías árbol anidado infinito, carpetas dentro de carpetas que llegaban a rutas tan largas que Windows directamente se rendía. En serio. Yarn apareció en 2016, creado por Facebook (ahora Meta) en colaboración con Google y otros. Fue una bocanada de aire fresco: instalaciones paralelas, lockfile determinístico, cache local. npm tardó años en ponerse al día. pnpm llegó también por esa época pero tardó más en tomar tracción. Y Bun... Bun es el newcomer que llegó en 2023 a decir que todos los demás son lentos y tiene cierta razón. --- ## npm: el que ya tenés instalado **Lo bueno:** Viene con Node. Sin instalación extra, sin explicarle nada a nadie. Para un proyecto pequeño o para onboardear a alguien nuevo es imbatible en simplicidad. **Lo malo:** Sigue siendo el más lento de los cuatro en instalaciones en frío. El `node_modules` es un monstruo flat que duplica paquetes alegremente. En un monorepo mediano vi node_modules llegar a **3.8GB**. Eso no es normal. Eso es un problema. La versión 7 trajo workspaces, la 8 mejoró bastante el performance, y npm hoy en día es decente. Pero "decente" no es suficiente cuando existían mejores alternativas hace años. **Mi experiencia real:** En 2021 arranqué un proyecto con npm por defecto. A los tres meses el CI tardaba 6 minutos solo en el `npm install`. Migré a pnpm en un viernes a la tarde (error mío, nunca migrés nada importante un viernes) y el lunes el CI tardaba 90 segundos. Eso me marcó. **Cuándo usarlo:** Cuando el proyecto es chico, cuando el equipo no quiere fricción de setup, o cuando trabajás con herramientas que tienen bugs conocidos con pnpm (sí, existen, aunque cada vez menos). --- ## Yarn: el que prometía mucho y se complicó Yarn clásico (v1) fue revolucionario en su momento. Lockfile determinístico, caché que realmente funcionaba, parallelismo. npm tardó literalmente años en igualar esas features. Pero después llegó **Yarn Berry (v2 en adelante)** y todo se complicó. Introdujeron **Plug'n'Play (PnP)**: en lugar de node_modules, un sistema de resolución propio donde los paquetes están en archivos `.zip` y un loader los resuelve en runtime. La teoría es preciosa. La práctica es otro tema. Probé Yarn Berry en un proyecto Next.js y fue una tarde entera de debuggear por qué ciertos paquetes no levantaban. Algunos tools del ecosistema simplemente no entienden el modelo PnP. Terminé en `nodeLinker: node-modules` en el `.yarnrc.yml`, que básicamente es usar Yarn Berry actuando como Yarn clásico. ¿Para qué, entonces? **Lo bueno de Yarn:** La DX cuando funciona es muy linda. Los workspaces de Yarn son muy maduros. El equipo de Yarn lleva años puliendo esto. **Lo malo:** La fragmentación entre v1 y v2/v3/v4 es un quilombo. Si buscás un error en Stack Overflow, el 60% de las respuestas son para la versión equivocada. Y PnP, aunque brillante conceptualmente, genera fricción real. **Cuándo usarlo:** Yarn clásico (v1) en proyectos legados que ya lo usan y no vale la pena migrar. Yarn Berry si estás dispuesto a invertir tiempo en entender PnP y tu equipo está alineado. --- ## pnpm: mi favorito sin discusión Acá es donde me pongo intenso, así que aguantame. pnpm resuelve el problema fundamental del package management de Node de una manera elegante: **el content-addressable store**. En lugar de copiar paquetes en cada `node_modules`, usa **hard links** a un store global en tu máquina. `lodash` instalado en 47 proyectos distintos ocupa espacio de disco una sola vez. El `node_modules` de cada proyecto son mayormente symlinks y hard links. Esto tiene consecuencias reales: - **Velocidad:** Primera instalación comparable a npm/yarn. Segunda instalación y en adelante: ridículamente rápida. - **Espacio en disco:** Tengo quizás 200 proyectos en esta máquina. Si usara npm serían cientos de GB. Con pnpm el store global ocupa ~15GB para todo. - **Correctitud:** pnpm es **estricto con las dependencias**. No podés acceder a un paquete que no declaraste en tu `package.json`. Esto parece una molestia hasta que te das cuenta de que npm/yarn te dejan acceder a dependencias transitivas silenciosamente — una bomba de tiempo. **Los workspaces de pnpm** son los mejores del ecosistema, punto. El archivo `pnpm-workspace.yaml` es simple, el hoisting configurable, y el comando `pnpm -r` para correr scripts en todos los packages es una joya. **Mi experiencia real:** Hoy uso pnpm en absolutamente todos mis proyectos personales y profesionales. El comando que más escribo después de `git` es probablemente `pnpm install`. Tuve exactamente un problema de compatibilidad en dos años: una librería vieja que asumía hoisting de npm. Lo resolví en 10 minutos con `.npmrc` ajustado. **Lo malo de pnpm:** La instalación inicial es un paso extra. Algunos proyectos open source con configs de npm legacy pueden dar dolores de cabeza. Y el store global puede crecer mucho si no hacés `pnpm store prune` de vez en cuando (yo lo tengo en un cron). **Cuándo usarlo:** Casi siempre. Especialmente en monorepos. Especialmente si te importa el espacio en disco. Especialmente si querés que tus dependencias estén correctamente declaradas. --- ## Bun: el que llegó a romper todo Bun no es solo un package manager — es un runtime completo (reemplazo de Node), un bundler, un test runner, y un transpiler. Pero acá hablamos de su faceta como package manager. **Los números:** Bun install es absurdamente rápido. Hablo de instalaciones en frío de proyectos medianos en **2-3 segundos**. Lo que npm hace en 45 segundos, Bun lo hace en 3. Está escrito en Zig, usa su propio runtime, y tiene un caché binario que hace que las instalaciones repetidas sean casi instantáneas. **Lo probé en un proyecto Next.js** y funcionó perfecto. El lockfile (`bun.lockb`) es binario, lo cual es raro conceptualmente pero funciona. Los workspaces están soportados. La compatibilidad con el ecosistema npm es muy buena. **Pero acá viene mi hesitación:** Bun como runtime todavía tiene edge cases donde el comportamiento difiere de Node. Si usás Bun solo como package manager (con Node como runtime), eso desaparece — pero entonces estás instalando un tool enorme para usar solo una fracción. El ecosistema de Bun maduró muchísimo en 2024. Para 2025 es una opción real y seria. Pero yo todavía no migré mis proyectos productivos porque el riesgo/beneficio no cierra para mí. La velocidad de pnpm con caché es más que suficiente, y el modelo mental de Bun como "todo en uno" todavía me genera incertidumbre en deployments complejos. **Cuándo usarlo:** Si arrancás un proyecto nuevo y querés experimentar. Si el performance de instalación es crítico para vos (¿monorepo enorme en CI sin caché?). Si sos el tipo de persona que le gusta estar en la vanguardia y bancarse algún rough edge. --- ## La tabla que todos quieren | | npm | Yarn | pnpm | Bun | |---|---|---|---|---| | **Velocidad (frío)** | Lento | Medio | Rápido | Muy rápido | | **Velocidad (caché)** | Medio | Rápido | Muy rápido | Muy rápido | | **Espacio en disco** | Mucho | Mucho | Poco | Poco | | **Monorepos** | Básico | Bueno | Excelente | Bueno | | **Madurez** | Alta | Alta | Alta | Media | | **Compatibilidad** | Total | Alta | Alta | Alta | | **Strictness** | No | No | Sí | No | --- ## Mi recomendación final, sin rodeos **¿Proyecto nuevo, 2025?** → pnpm. Sin dudarlo. La curva de aprendizaje es mínima (es casi idéntico a npm en la interfaz), los beneficios son inmediatos y reales, y el soporte del ecosistema es excelente. **¿Monorepo?** → pnpm con workspaces. Es la mejor opción disponible hoy. **¿Querés vivir en el futuro?** → Bun. Pero sabé que vas a ser el beta tester de algunas cosas. **¿Proyecto legado que ya tiene yarn.lock o package-lock.json?** → No migrés por migrar. El lockfile es contrato. Si no tenés un motivo real de performance o correctitud, dejalo como está. **npm puro en 2025 sin una razón específica:** No. Ya no. Es como usar jQuery en un proyecto nuevo — funciona, pero hay mejores opciones y vos lo sabés. El ecosistema JavaScript tiene sus mil problemas, pero en package management llegamos a un punto donde tenemos opciones genuinamente buenas. Aprovechalo. Yo tardé demasiado en salir de npm por inercia, y esos 6 minutos de CI en 2021 me los voy a cobrar de alguna forma.39:T29f1,# Next.js App Router: la guía que me hubiera gustado tener cuando migré de Pages Router Era un martes a las 11 de la noche y tenía un cliente en producción con el carrito de compras roto. El problema: había migrado a App Router siguiendo la documentación oficial como si fuera un manual de IKEA — metódicamente, con fe ciega — y me había olvidado de entender *por qué* funcionaba lo que funcionaba. Cuando algo se rompió, no tenía idea de dónde buscar. Esta es la guía que me hubiera gustado tener. No la de Vercel. La mía. ## El cambio mental que nadie te dice que necesitás El error más grande que cometí fue tratar App Router como si fuera Pages Router con carpetas distintas. No lo es. Es un paradigma diferente. En Pages Router, todo componente es un Client Component por defecto. Podés usar `useState`, `useEffect`, fetch del lado del servidor con `getServerSideProps` — pero es todo explícito, separado, prolijo. En App Router, **todo componente es un Server Component por defecto**. Esto significa que se ejecuta en el servidor, nunca llega al bundle del cliente, puede hablar directo con la base de datos, y no tiene acceso a `window`, `localStorage`, ni hooks de React. Cuando migré mi primer proyecto, pasé tres horas debuggeando esto: ```tsx // app/dashboard/page.tsx export default function Dashboard() { const [count, setCount] = useState(0) // 💥 ERROR // TypeError: useState is not a function return

{count}

} ``` El fix no es "usar Pages Router". El fix es entender cuándo necesitás interactividad y marcar explícitamente ese componente: ```tsx 'use client' import { useState } from 'react' export default function Counter() { const [count, setCount] = useState(0) return ( ) } ``` La regla que me tatuaría en la mano: **Server Components por defecto, Client Components solo cuando necesitás interactividad, estado del browser, o eventos del DOM**. ## La estructura de carpetas que sí funciona El App Router vive en `/app`. Cada carpeta con un `page.tsx` se convierte en una ruta. Pero hay archivos especiales que cambian todo: ``` app/ ├── layout.tsx ← Layout raíz (obligatorio) ├── page.tsx ← Ruta / ├── loading.tsx ← UI mientras carga (streaming) ├── error.tsx ← Manejo de errores ├── not-found.tsx ← 404 ├── dashboard/ │ ├── layout.tsx ← Layout anidado │ ├── page.tsx ← Ruta /dashboard │ └── settings/ │ └── page.tsx ← Ruta /dashboard/settings └── api/ └── webhook/ └── route.ts ← API Route ``` Los layouts anidados son lo más poderoso y lo que más confunde. El `layout.tsx` de una carpeta envuelve a todos sus hijos *sin remontarse cuando navegás entre subrutas*. Esto es exactamente lo que siempre quisimos y nunca tuvimos limpio en Pages Router. ```tsx // app/dashboard/layout.tsx export default function DashboardLayout({ children, }: { children: React.ReactNode }) { return (

{/* Se renderiza UNA vez, no se destruye al navegar */}

{children}

) } ``` ## Fetch de datos: la parte donde casi todos la cagan Olvidate de `getServerSideProps`, `getStaticProps` y `getInitialProps`. En App Router, fetcheás datos directamente en el componente: ```tsx // app/products/page.tsx async function getProducts() { const res = await fetch('https://api.tudominio.com/products', { next: { revalidate: 60 } // Revalida cada 60 segundos }) if (!res.ok) throw new Error('No se pudo cargar products') return res.json() } export default async function ProductsPage() { const products = await getProducts() // async/await directo en el componente return (

{p.name}

) } ``` Sí, el componente es `async`. Sí, funciona. Sí, me pareció raro al principio también. ### El sistema de cache que me hizo perder dos horas Next.js cachea el `fetch` por defecto. Esto es un feature, no un bug. Pero si no lo entendés, te volvés loco. ```tsx // Cacheado indefinidamente (como getStaticProps) const data = await fetch('/api/data') // Sin cache (como getServerSideProps) const data = await fetch('/api/data', { cache: 'no-store' }) // Revalidación por tiempo const data = await fetch('/api/data', { next: { revalidate: 3600 } }) // Revalidación por tag (on-demand) const data = await fetch('/api/data', { next: { tags: ['products'] } }) ``` Ese último es el que me salvó cuando el cliente me preguntaba por qué los precios actualizados no aparecían. Con `tags` podés invalidar el cache cuando muta un dato: ```tsx // app/api/update-product/route.ts import { revalidateTag } from 'next/cache' export async function POST(request: Request) { const body = await request.json() await updateProductInDB(body) revalidateTag('products') // 🔥 Invalida todo lo que use este tag return Response.json({ ok: true }) } ``` ## Streaming y Suspense: la magia que justifica todo el dolor Esto es lo que más me enamoró del App Router y lo que hacía imposible Pages Router. El streaming te permite enviar partes de la página al browser mientras otras partes todavía se están computando en el servidor. El usuario ve contenido rápido en lugar de una pantalla en blanco. Combinado con Suspense, es una locura: ```tsx // app/dashboard/page.tsx import { Suspense } from 'react' import { UserStats } from './UserStats' // Query rápida import { SalesChart } from './SalesChart' // Query lenta (agrega datos) import { RecentOrders } from './RecentOrders' export default function Dashboard() { return (

Dashboard

{/* Se renderiza casi instantáneo */} }> {/* Llega cuando termina, sin bloquear lo demás */} }> }>

) } ``` Cada `Suspense` boundary se resuelve independientemente. Si `SalesChart` tarda 2 segundos y `UserStats` tarda 200ms, el usuario ve las stats antes y el chart aparece solo después. Sin JavaScript del cliente. Sin `useEffect`. Sin estado de loading manual. El archivo `loading.tsx` hace exactamente esto a nivel de ruta: ```tsx // app/dashboard/loading.tsx export default function Loading() { return } ``` ## Lo que rompe en producción (mi lista de traumas) ### 1. Los cookies y headers en Server Components Si necesitás leer una cookie en un Server Component, no usés `document.cookie`. Usá las funciones de Next.js: ```tsx import { cookies, headers } from 'next/headers' export default async function Page() { const cookieStore = await cookies() const token = cookieStore.get('auth-token') const headersList = await headers() const userAgent = headersList.get('user-agent') return

Token: {token?.value}

} ``` ### 2. Pasar funciones como props a Client Components Esto me rompió la cabeza al principio: ```tsx // ❌ NO podés pasar una función de un Server Component a un Client Component export default function ServerComponent() { const handleClick = () => console.log('click') return // Error en runtime } // ✅ La función tiene que vivir en el Client Component 'use client' export function ClientButton() { const handleClick = () => console.log('click') return } ``` La razón es simple: una función de JavaScript no se puede serializar para enviarla entre servidor y cliente. Tiene sentido cuando lo pensás, pero duele cuando lo descubrís a las 2am. ### 3. El router de navegación cambió Olvidate de `useRouter` de `next/router`. Ahora es `next/navigation`: ```tsx 'use client' import { useRouter, usePathname, useSearchParams } from 'next/navigation' export function NavComponent() { const router = useRouter() const pathname = usePathname() const searchParams = useSearchParams() return ( ) } ``` Importar de `next/router` en App Router simplemente no funciona. No te da error claro, solo se rompe en formas misteriosas. ### 4. Variables de entorno y el servidor En Pages Router, tenías `NEXT_PUBLIC_` para el cliente y sin prefijo para el servidor. Sigue siendo así, pero con un detalle: en Server Components podés usar variables de servidor directamente. En Client Components, solo las `NEXT_PUBLIC_`. ```tsx // Server Component - OK const secret = process.env.DATABASE_URL // ✅ // Client Component - NUNCA hagas esto const secret = process.env.DATABASE_URL // undefined, y si no fuera undefined, sería una filtración de seguridad brutal ``` ## La migración incremental que recomiendo No migrés todo de una. Next.js te deja tener `/pages` y `/app` coexistiendo. La estrategia que funcionó para mí: 1. **Primero los layouts** — reemplazá el `_app.tsx` y `_document.tsx` con el `layout.tsx` raíz 2. **Después las páginas estáticas** — las que no tienen data fetching complejo 3. **Luego las páginas con fetch** — migrá el data fetching a Server Components 4. **Al final la autenticación** — es lo más complicado, dejalo para cuando entendés bien el modelo Cada paso lo podés deployar. Cada paso lo podés testear. No intentés hacer todo de una noche para los lunes. ## ¿Vale la pena? Sí. Rotundamente. Mis métricas antes y después en el proyecto de e-commerce: el Time to First Byte bajó de 340ms a 89ms. El Largest Contentful Paint de 3.2s a 1.1s. El bundle de JavaScript del cliente se redujo un 60% porque la mayoría de los componentes de listado ahora son Server Components. El cliente ni sabe lo que es App Router, pero me escribió para decirme que la tienda "se siente más rápida". Eso vale todas las noches de debugging. La curva de aprendizaje es real y duele. Pero una vez que internalizás el modelo mental — servidor por defecto, cliente por excepción, datos cerca de donde se consumen — escribir aplicaciones React se vuelve más limpio que nunca. Ahora cuando arranco un proyecto nuevo, ya no me imagino volviendo a Pages Router. Es como volver a usar jQuery después de aprender React. Técnicamente funciona. Pero sabés que existe algo mejor. 3a:T29ee,Hay un momento específico en tu relación con TypeScript donde dejás de pelearle y empezás a entenderlo. Para mí fue a las 2AM de un martes, con un bug de producción que hubiera sido imposible con tipos bien definidos. Desde ese momento cambié cómo pienso el código. Esto no es un tutorial de introducción. Si todavía estás peleando con `interface` vs `type`, hay mil artículos para eso. Esto es lo que realmente tengo en mi cabeza cuando programo en TypeScript hoy — los patrones que uso sin pensar, los que me salvaron el culo más de una vez y los errores que cometí antes de entenderlos. ## Discriminated Unions: el patrón que más uso Si tuviera que quedarme con un solo patrón de TypeScript, es este. La idea es simple: tenés un tipo unión donde cada variante tiene una propiedad discriminante — generalmente `type` o `kind` — que le dice a TypeScript exactamente con qué estás trabajando. ```typescript type ApiResponse = | { status: 'loading' } | { status: 'error'; error: string; code: number } | { status: 'success'; data: T; timestamp: Date }; function renderUser(response: ApiResponse) { switch (response.status) { case 'loading': return ; case 'error': // TypeScript sabe que acá existe response.error y response.code return ; case 'success': // TypeScript sabe que acá existe response.data y response.timestamp return ; } } ``` Lo que me encanta de esto es que TypeScript te avisa si te olvidás un caso. Agregás `'cancelled'` a la unión y de repente el compilador te dice exactamente dónde tenés que manejar esa situación. Es como tener un colega que revisa tu código sin ser molesto. Lo uso en eventos de dominio, estados de UI, resultados de operaciones asíncronas. En un proyecto de e-commerce que hice el año pasado, modelé todos los estados de un pedido así: ```typescript type OrderState = | { kind: 'draft'; items: CartItem[] } | { kind: 'pending_payment'; orderId: string; total: Money } | { kind: 'paid'; orderId: string; paymentId: string; paidAt: Date } | { kind: 'shipped'; orderId: string; trackingCode: string } | { kind: 'delivered'; orderId: string; deliveredAt: Date } | { kind: 'cancelled'; orderId: string; reason: string }; ``` Cada estado tiene exactamente la información que tiene sentido para ese estado. No hay campos opcionales raros, no hay `trackingCode: string | null` que no sabés si es null porque no fue enviado o porque es un pedido viejo. La forma del tipo *es* la documentación. ## Branded Types: cuando `string` no alcanza Este me costó más entenderlo pero hoy no puedo vivir sin él. El problema es simple: `userId: string` y `productId: string` son el mismo tipo para TypeScript, pero no para tu negocio. Mezclarlos es un bug. ```typescript // Sin branded types — TypeScript no se queja de esto: function getUser(id: string) { /* ... */ } function getProduct(id: string) { /* ... */ } const productId = '123'; getUser(productId); // TypeScript dice que está bien. Está mal. ``` La solución con branded types: ```typescript type Brand = T & { readonly __brand: B }; type UserId = Brand; type ProductId = Brand; type OrderId = Brand; // Funciones constructoras que validan y brandean function createUserId(id: string): UserId { if (!id.match(/^usr_[a-z0-9]+$/)) { throw new Error(`Invalid user ID format: ${id}`); } return id as UserId; } function getUser(id: UserId): Promise { /* ... */ } function getProduct(id: ProductId): Promise { /* ... */ } const userId = createUserId('usr_abc123'); const productId = 'prod_xyz789' as ProductId; getUser(productId); // TS Error: Argument of type 'ProductId' is not assignable to parameter of type 'UserId' getUser(userId); // OK ``` El `__brand` nunca existe en runtime — es solo una ficción para el type checker. El costo es cero en producción, el beneficio es enorme en desarrollo. Lo uso también para valores primitivos con semántica específica: ```typescript type Percentage = Brand; type Milliseconds = Brand; type USD = Brand; function calculateDiscount(price: USD, discount: Percentage): USD { return (price * (1 - discount / 100)) as USD; } // No podés accidentalmente pasar milisegundos como precio const delay: Milliseconds = 5000 as Milliseconds; const price: USD = 99.99 as USD; calculateDiscount(delay, price); // Error en compilación, no en producción ``` ## Generics avanzados: más allá de `Array` Generics es donde TypeScript se pone realmente poderoso y donde la gente se pierde. Yo me perdí muchas veces. Voy a mostrar los patrones que quedaron en mi toolbelt. ### Conditional Types ```typescript type Awaited = T extends Promise ? U : T; // Uso real: cuando tenés que manejar valores que pueden ser async o sync type MaybeAsync = T | Promise; type Resolved = T extends Promise ? U : T; // Unwrap nested arrays type Flatten = T extends Array ? U : T; type StringOrNumber = Flatten; // string type JustString = Flatten; // string ``` ### Template Literal Types Este me voló la cabeza cuando lo descubrí. Podés hacer aritmética de strings en el type system: ```typescript type HttpMethod = 'GET' | 'POST' | 'PUT' | 'DELETE' | 'PATCH'; type ApiEndpoint = '/users' | '/products' | '/orders'; type ApiRoute = `${HttpMethod} ${ApiEndpoint}`; // = 'GET /users' | 'GET /products' | 'GET /orders' | 'POST /users' | ... // Esto lo uso para event names en sistemas de eventos type EntityName = 'user' | 'product' | 'order'; type CrudAction = 'created' | 'updated' | 'deleted'; type DomainEvent = `${EntityName}.${CrudAction}`; // = 'user.created' | 'user.updated' | 'user.deleted' | 'product.created' | ... type EventHandler = (event: T) => void; function on(event: T, handler: EventHandler) { // registro el handler } on('user.created', (event) => { /* event es 'user.created' */ }); on('invalid.event', () => {}); // Error de compilación ``` ### Mapped Types con modificadores ```typescript // El clásico DeepReadonly que no viene en la stdlib type DeepReadonly = { readonly [K in keyof T]: T[K] extends object ? DeepReadonly : T[K]; }; // DeepPartial para formularios type DeepPartial = { [K in keyof T]?: T[K] extends object ? DeepPartial : T[K]; }; // Pick con dot notation — lo escribí para un form builder type PathsToString = T extends string | number | boolean ? never : { [K in keyof T & string]: K | `${K}.${PathsToString}`; }[keyof T & string]; ``` ## Cómo pienso en tipos: el cambio mental Antes pensaba en tipos como anotaciones — escribía el código y después le ponía tipos encima. Error conceptual enorme. Ahora pienso en tipos primero, especialmente en el dominio. **Los tipos son tu modelo de negocio.** Si el tipo compila, las invariantes del negocio se cumplen — o deberían. Si podés construir un estado inválido con tus tipos, los tipos están mal. Un ejemplo concreto: un carrito de compras no puede tener cantidad negativa de items. Si tenés `quantity: number`, estás mintiendo. Tenés `quantity: PositiveInteger` o tenés un bug esperando pasar. ```typescript type PositiveInteger = Brand; function toPositiveInteger(n: number): PositiveInteger { if (!Number.isInteger(n) || n <= 0) { throw new Error(`Expected positive integer, got: ${n}`); } return n as PositiveInteger; } interface CartItem { productId: ProductId; quantity: PositiveInteger; unitPrice: USD; } ``` Ahora es imposible tener un CartItem con cantidad cero o negativa sin pasar por la función que valida. La validación vive en un solo lugar. ## El patrón Result que reemplazó mis try/catch Esto lo tomé prestado de Rust y cambió cómo manejo errores: ```typescript type Result = | { ok: true; value: T } | { ok: false; error: E }; function ok(value: T): Result { return { ok: true, value }; } function err(error: E): Result { return { ok: false, error }; } // En vez de throw: async function fetchUser(id: UserId): Promise> { try { const user = await db.users.findById(id); if (!user) return err('NOT_FOUND'); return ok(user); } catch { return err('NETWORK_ERROR'); } } // En el caller, TypeScript me fuerza a manejar ambos casos: const result = await fetchUser(userId); if (!result.ok) { switch (result.error) { case 'NOT_FOUND': return redirect('/404'); case 'NETWORK_ERROR': return showRetryButton(); } } // Acá TypeScript sabe que result.value existe y es User console.log(result.value.name); ``` Los errores posibles están en la firma de la función. No tenés que leer la implementación para saber qué puede fallar. Es la diferencia entre documentación que se desactualiza y tipos que son verdad por construcción. ## Lo que no uso Serío con esto: no uso `any` salvo para interop con librerías viejas y siempre lo encapsulo. `unknown` es casi siempre la respuesta correcta cuando no sabés el tipo. No uso `as` salvo en las funciones constructoras de branded types y cuando sé exactamente lo que estoy haciendo. Si encontrás que usás `as` seguido para que el código compile, los tipos están mal — no el compilador. También evito tipos demasiado complejos que nadie puede leer. Un tipo que necesita comentarios para explicarse falló en su trabajo principal. Si llegás a cuatro niveles de condicional genérico, parateé un segundo y pensá si no hay una abstracción más simple. ## El viaje vale la pena Me acuerdo perfectamente de cuando TypeScript me parecía burocracia innecesaria. "¿Para qué poner tipos si JavaScript igual funciona?" — esa es la pregunta de alguien que todavía no tuvo el bug de producción suficientemente doloroso. Hoy no concibo escribir una aplicación seria sin él. No porque sea una regla, sino porque cuando los tipos están bien, el código te habla. Refactorizás con confianza porque el compilador te dice exactamente qué rompiste. Entrás a un codebase de otra persona y los tipos te cuentan el modelo de negocio sin que tengas que leer comentarios desactualizados. Empieza con discriminated unions. Ese es mi consejo. Es el patrón con mejor ratio de complejidad/valor y una vez que lo internalizás, empezás a ver oportunidades para usarlo en todos lados.3b:T24f0,## La primera vez que Docker me rompió producción Era 2021. Tenía una app Node.js corriendo en un VPS de DigitalOcean, funcionaba perfecto en mi máquina (sí, esa frase maldita), y decidí 'modernizar' el deploy metiéndole Docker. Resultado: tres horas de downtime, un cliente furioso y yo a las 3 de la mañana leyendo logs que no entendía. Hoy, con todo ese dolor convertido en experiencia, puedo decirte que Docker con Node.js es una de las mejores decisiones que podés tomar para tu stack — siempre y cuando lo hagas bien. Y 'bien' implica entender qué está pasando, no copiar un Dockerfile de Stack Overflow y rezar. Vamos de cero. En serio, de cero. ## ¿Por qué Docker y Node.js se llevan tan bien? Node.js tiene un problema histórico: el entorno. La versión de Node en tu máquina, la del servidor de staging, la del servidor de producción — si no las controlás, te esperan bugs que aparecen solo en producción y te hacen dudar de tu cordura. Docker resuelve esto con contenedores. Un contenedor es básicamente un proceso aislado que lleva su propio sistema de archivos, sus propias dependencias, su propia versión de Node. Vos definís todo eso en un `Dockerfile`, y ese archivo viaja con tu código. Si funciona en tu contenedor, funciona en cualquier lado. Eso es la promesa. Ahora veamos cómo no arruinarla. ## Tu primer Dockerfile para Node.js Empezamos con lo básico. Supongamos que tenés una app Express simple: ```dockerfile FROM node:20-alpine WORKDIR /app COPY package*.json ./ RUN npm ci --only=production COPY . . EXPOSE 3000 CMD ["node", "src/index.js"] ``` Este Dockerfile hace cosas específicas por razones específicas. Te las explico porque cuando entendés el *por qué*, dejás de copiar a ciegas: **`FROM node:20-alpine`**: Uso Alpine Linux, que pesa unos 50MB contra los 300MB+ de la imagen Debian/Ubuntu. Para producción, menos superficie = menos vulnerabilidades potenciales. Para desarrollo, a veces Alpine te rompe dependencias nativas (te miro a vos, `bcrypt`). En esos casos usá `node:20-slim`. **`WORKDIR /app`**: Definís un directorio de trabajo limpio. Sin esto, Docker tira los archivos en la raíz del contenedor y el caos reina. **`COPY package*.json ./` antes del `COPY . .`**: Esto es crítico para el sistema de caché de Docker. Las capas de Docker se cachean. Si copiás primero los `package.json` y corrés `npm ci`, Docker va a reusar esa capa mientras los `package.json` no cambien. O sea: en cada rebuild, si solo tocaste código, Docker no reinstala todas las dependencias. Esto te ahorra minutos reales. **`npm ci` en lugar de `npm install`**: `ci` usa exactamente el `package-lock.json`. Reproducible, determinístico, lo que querés en producción. ## El .dockerignore que nadie te enseña Antes de buildear nada, creá un `.dockerignore`. Esto es lo que más gente olvida y lo que más me quemó al principio: ``` node_modules .git .gitignore *.log .env .env.local .env.*.local dist build .next Dockerfile docker-compose*.yml README.md .DS_Store coverage ``` Sin `.dockerignore`, estás copiando `node_modules` (que puede pesar gigabytes) al contexto de build, y potencialmente metiendo tus variables de entorno secretas en la imagen. Sí, como suena. El `.env` adentro de una imagen Docker pública es una pesadilla de seguridad que vi pasar en repos reales. ## Docker Compose: el compañero inseparable Ninguna app vive sola. La tuya necesita una base de datos, quizás Redis, quizás un servicio de cola. Docker Compose te permite orquestar todo eso localmente con un solo archivo: ```yaml version: '3.8' services: app: build: context: . dockerfile: Dockerfile ports: - "3000:3000" environment: - NODE_ENV=development - DATABASE_URL=postgresql://postgres:password@db:5432/myapp - REDIS_URL=redis://cache:6379 depends_on: db: condition: service_healthy cache: condition: service_started volumes: - .:/app - /app/node_modules db: image: postgres:16-alpine environment: POSTGRES_PASSWORD: password POSTGRES_DB: myapp volumes: - postgres_data:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 5s timeout: 5s retries: 5 cache: image: redis:7-alpine volumes: - redis_data:/data volumes: postgres_data: redis_data: ``` Notá el `depends_on` con `condition: service_healthy`. Esto fue otro de mis errores históricos: arrancar la app antes de que Postgres termine de inicializar. Sin el healthcheck, tu app arranca, intenta conectarse a la base de datos que todavía está bootando, y explota. Con el healthcheck, Docker espera a que Postgres realmente esté listo. El volumen doble en `app`: ```yaml volumes: - .:/app - /app/node_modules ``` Monta tu código local adentro del contenedor (hot reload en desarrollo) pero preserva el `node_modules` del contenedor. Sin la segunda línea, tu `node_modules` local pisaría el del contenedor, y si estás en Mac o Windows corriendo Alpine, los binarios compilados son incompatibles. Esta sutileza me hizo perder dos horas una tarde. ## Multi-stage builds: el paso de adulto Cuando empecés a trabajar con TypeScript (y vas a trabajar con TypeScript), necesitás compilar antes de correr. Un Dockerfile naive instalaría todas las devDependencies, compilaría, y dejaría todo ese peso en la imagen final. Multi-stage builds resuelven eso: ```dockerfile # Stage 1: Builder FROM node:20-alpine AS builder WORKDIR /app COPY package*.json tsconfig.json ./ RUN npm ci COPY src ./src RUN npm run build # Stage 2: Production FROM node:20-alpine AS production WORKDIR /app RUN addgroup -g 1001 -S nodejs && \ adduser -S nodeuser -u 1001 COPY package*.json ./ RUN npm ci --only=production && npm cache clean --force COPY --from=builder /app/dist ./dist USER nodeuser EXPOSE 3000 CMD ["node", "dist/index.js"] ``` Esto hace dos cosas importantes: 1. La imagen final solo tiene el código compilado y las dependencias de producción. Sin TypeScript, sin ts-node, sin ninguna devDependency. Imágenes más chicas, más seguras, más rápidas de deployar. 2. `USER nodeuser`: No corrás tu app como root adentro del contenedor. Es un principio básico de seguridad que mucha gente ignora hasta que tiene un problema. ## Variables de entorno: hacelo bien o no lo hagas Nunca hardcodees secretos en el Dockerfile ni en el docker-compose.yml que commitás. La forma correcta: Para desarrollo, usá un `.env` local (que está en tu `.dockerignore` y `.gitignore`) y referencialo en compose: ```yaml services: app: env_file: - .env ``` Para producción, usás los secrets de tu plataforma: Railway, Render, Fly.io, o las variables de entorno de tu CI/CD. Docker Swarm y Kubernetes tienen sus propios sistemas de secrets. Lo importante es que el secreto nunca viva en el código ni en la imagen. ## El workflow que uso hoy Después de todos los tropiezos, mi flujo actual es: ```bash # Desarrollo con hot reload docker compose up # Rebuild forzado cuando cambio dependencias docker compose up --build # Correr en background docker compose up -d # Ver logs en tiempo real docker compose logs -f app # Entrar al contenedor a debuggear docker compose exec app sh # Limpiar todo y empezar de cero docker compose down -v ``` El `docker compose exec app sh` es tu mejor amigo para debuggear. Entrás al contenedor vivo, podés correr comandos, verificar que las variables de entorno están como esperás, ver si los archivos están donde tienen que estar. ## Producción: lo que nadie te dice Para producción real, algunas cosas que aprendí caro: **Health checks en el Dockerfile**: ```dockerfile HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD node -e "require('http').get('http://localhost:3000/health', (r) => { process.exit(r.statusCode === 200 ? 0 : 1) })" ``` Tu orquestador (sea Compose, Swarm o Kubernetes) necesita saber si tu app está viva. Sin health check, puede estar sirviendo errores 500 y el orquestador sigue creyendo que todo está bien. **NODE_ENV=production**: Setéalo siempre. Express, entre otros frameworks, tiene optimizaciones específicas para este modo. **Manejo de señales**: Node.js adentro de Docker necesita manejar `SIGTERM` para hacer graceful shutdown. Si no lo implementás, Docker mata el proceso después del timeout y podés perder requests en vuelo. Es un tema que da para otro post entero. ## Conclusión: el dolor vale la pena Docker con Node.js tiene una curva de aprendizaje real. Te va a romper cosas. Vas a tener imágenes que pesan 2GB cuando deberían pesar 200MB. Vas a tener contenedores que no arrancan por problemas de permisos a las 2 de la mañana. Pero cuando lo tenés aceitado, la sensación de `docker compose up` y tener todo tu stack corriendo en 30 segundos, en cualquier máquina, con exactamente las mismas versiones de todo, es difícil de superar. El día que un compañero clonó mi repo y tuvo el proyecto corriendo en 5 minutos sin instalar nada más que Docker, entendí por qué vale el dolor inicial. El Dockerfile de producción bien hecho es uno de los activos más valiosos de tu proyecto. Tratálo como código, evoluciónalos, revisalos en code review. No es solo infraestructura — es la receta de cómo vive tu app en el mundo.3c:T3a27,Si hoy tenés un sistema que firma digitalmente algo — un documento, un JWT, un certificado, un binario — y ese sistema usa RSA o ECDSA, NIST te está diciendo que ese sistema tiene fecha de vencimiento. No es FUD. No es "en el futuro". Los estándares finales ya están publicados desde agosto de 2024. La migración ya arrancó en las organizaciones serias. Y el reloj corre porque hay ataques que se están ejecutando *ahora mismo* — aunque el resultado lo van a ver recién cuando tengan la computadora cuántica. Voy a explicarte qué publicó NIST, qué rompe exactamente, cómo impacta a los HSMs, y qué podés hacer desde hoy. --- ## Por qué esto es urgente aunque la computadora cuántica no exista todavía El ataque se llama *harvest now, decrypt later*. Actores estatales están capturando tráfico TLS cifrado y datos firmados digitalmente *hoy*, los están almacenando, y esperan a tener acceso a un quantum computer suficientemente potente para romperlos. Para el cifrado simétrico (AES, HMAC), el impacto es manejable: duplicás el tamaño de clave y listo. Para la criptografía asimétrica — RSA, ECDSA, EdDSA — **Shor's algorithm la rompe completamente**. No hay parche de tamaño de clave que alcance. Si firmás documentos que tienen que ser válidos en 10 o 15 años, el problema ya es tuyo. --- ## Qué publicó NIST en agosto de 2024 Tres estándares finales y uno en borrador. Para firma digital son relevantes tres: **FIPS 204 — ML-DSA** (Module-Lattice-Based Digital Signature Algorithm) El sucesor directo de ECDSA. Basado en CRYSTALS-Dilithium, que resistió varios años de criptoanálisis en la competencia de NIST. Es el que vas a usar en la práctica. Tiene tres niveles de seguridad: | Variante | Seguridad equivalente | Clave pública | Firma | |----------|----------------------|---------------|-------| | ML-DSA-44 | ~Level 2 (128 bits clásico) | 1.312 bytes | 2.420 bytes | | ML-DSA-65 | ~Level 3 | 1.952 bytes | 3.309 bytes | | ML-DSA-87 | ~Level 5 | 2.592 bytes | 4.595 bytes | Para comparar: una firma ECDSA P-256 ocupa 64 bytes. Una firma ML-DSA-44 ocupa 2.420 bytes — casi 38 veces más. Esto importa mucho cuando firmás en volumen o cuando el tamaño del certificado tiene restricciones. **FIPS 205 — SLH-DSA** (Stateless Hash-Based Digital Signature) Basado en SPHINCS+. Su seguridad se basa únicamente en funciones de hash — si SHA-3 resiste, SLH-DSA resiste. Es el backup conservador para escenarios donde querés la menor cantidad posible de supuestos matemáticos. Firmas más grandes, operaciones más lentas, pero el argumento de seguridad es el más sólido de los tres. **FIPS 206 (borrador) — FN-DSA** (Fast Fourier Transform-based Digital Signature) Basado en FALCON. Firmas más compactas que ML-DSA, pero la implementación en tiempo constante es notoriamente difícil — especialmente en hardware con operaciones de punto flotante. Por ahora, a menos que tengas una necesidad muy específica de tamaño, ML-DSA es la elección práctica. --- ## Lo que cambia en tu HSM Acá está el problema concreto para la mayoría de las implementaciones de firma digital en producción. **El tamaño de las claves explotó.** Una clave privada RSA-2048 tiene 256 bytes. Una clave privada ML-DSA-44 tiene dos representaciones: el *seed* compacto (32 bytes) y la clave expandida para operaciones (2.528 bytes para ML-DSA-44, 4.032 bytes para ML-DSA-65). Los HSMs están diseñados para almacenar y operar con claves RSA y ECDSA — las restricciones de memoria interna y los buffers de transferencia no necesariamente soportan estas dimensiones sin cambios. **PKCS#11 necesita actualizarse.** El estándar PKCS#11 que usan virtualmente todos los HSMs para exponer sus operaciones criptográficas no tenía OIDs ni tipos de clave para ML-DSA. Las actualizaciones de firmware de los vendors incluyen extensiones a PKCS#11 para soportar los nuevos algoritmos. Pero eso significa que tu middleware — tu librería que habla con el HSM — también tiene que actualizarse. **No todos los HSMs tienen el mismo camino.** Utimaco lanzó *Quantum Protect*, un paquete de aplicación que se activa en-field sobre su línea Se-Series, sin reemplazar el hardware. Se entrega vía PKCS#11 actualizado y soporta ML-KEM y ML-DSA más las firmas hash-based stateful (LMS, XMSS). Esto es buena noticia: si tenés hardware Utimaco moderno, probablemente no necesitás reemplazarlo. Thales tiene sus HSEs (High Speed Encryptors) construidos sobre FPGAs reprogramables, lo que les da flexibilidad similar. Su línea de Luna Network HSM también está recibiendo soporte PQC. El YubiHSM 2, que muchos usan para development o deployments pequeños, tiene restricciones de memoria que limitan su escalabilidad con claves ML-DSA expandidas. Ahí el camino puede ser reemplazo. **La validación FIPS 140-3 todavía está al día.** Un HSM que soporta ML-DSA via firmware update no tiene automáticamente la validación FIPS 140-3 para esos algoritmos. La validación requiere un proceso con laboratorio acreditado que puede tomar 12-18 meses. Si tu compliance requiere FIPS 140-3 validado para el módulo, chequeá el estado de validación de tu vendor específicamente para PQC — no asumas que el firmware update lo cubre. --- ## El enfoque híbrido: cómo migrar sin romper nada La recomendación práctica tanto de NIST como de los vendors es migrar en modo híbrido: firmar con el algoritmo clásico *y* con el algoritmo PQC simultáneamente durante el período de transición. Esto significa: ``` Firma del documento = ECDSA(hash) || ML-DSA(hash) ``` El verificador que no soporta PQC sigue verificando con ECDSA. El verificador que sí soporta PQC puede verificar con ML-DSA. Cuando todos los participantes del sistema migraron, sacás el ECDSA. Para certificados X.509, el IETF está trabajando en el borrador para certificados híbridos (draft-ietf-lamps-pq-composite-sigs). Ya hay implementaciones experimentales en algunos stacks. Para JWTs y otros formatos de token, el grupo de trabajo todavía está finalizando los algoritmos. El algoritmo identifier para ML-DSA en JWA va a ser `ML-DSA-44`, `ML-DSA-65` y `ML-DSA-87` (o con el prefijo `id-` dependiendo del RFC final). --- ## Lo que cambia en el código Si hoy usás OpenSSL o una librería similar para verificar firmas, el cambio a nivel de código es más chico de lo que parece — si la librería ya soporta los nuevos algoritmos. OpenSSL 3.x ya tiene soporte experimental para ML-DSA via el *Open Quantum Safe provider*. En la práctica: ```bash # Instalar el proveedor OQS para OpenSSL 3 # (disponible en oqs-provider: https://github.com/open-quantum-safe/oqs-provider) # Generar un par de claves ML-DSA-65 openssl genpkey -algorithm mldsa65 -out private.pem # Generar el certificado autofirmado openssl req -new -x509 -key private.pem -out cert.pem -days 365 \ -subj "/CN=test/O=JuanchiDev" # Ver el certificado — la clave pública va a ser de 1952 bytes openssl x509 -in cert.pem -text -noout | grep "Public Key" # Public Key Size: 1952 bytes (ML-DSA-65) ``` En Node.js, la librería `node-forge` todavía no soporta ML-DSA de forma nativa. Para producción hoy, el camino es: 1. El HSM firma via PKCS#11 con ML-DSA (cuando el vendor actualice el firmware) 2. Tu aplicación usa el binding PKCS#11 (`pkcs11js` en Node.js o equivalente) sin necesidad de que la librería de crypto del runtime soporte ML-DSA directamente 3. La verificación puede hacerse con `liboqs` via binding nativo ```typescript // Ejemplo conceptual — firma via PKCS#11 hacia HSM con ML-DSA import { PKCS11 } from "pkcs11js" const pkcs11 = new PKCS11() pkcs11.load("/usr/lib/softhsm/libsofthsm2.so") // o el driver de tu HSM // El HSM expone ML-DSA como CKM_ML_DSA (nuevo mecanismo en PKCS#11 v3.x) const mechanism = { mechanism: pkcs11.CKM_ML_DSA } // La API de firma es la misma que con ECDSA // El cambio está en el mecanismo y en los handles de clave const signature = pkcs11.C_Sign(session, data, mechanism) // La firma va a tener 3309 bytes para ML-DSA-65 // vs 64 bytes para ECDSA P-256 console.log(`Tamaño de firma: ${signature.length} bytes`) ``` El punto importante: si tu arquitectura ya pasa toda la criptografía por el HSM (que es como debería ser), el cambio en el código de aplicación es mínimo. El quilombo está en actualizar el HSM, el middleware, y los certificados — no en reescribir la lógica de negocio. --- ## El demo funcional: SoftwareHSM con ML-DSA en TypeScript Para acompañar este post construí un proyecto que implementa todo lo que describí arriba: un HSM en software que nunca expone las claves privadas, con soporte real para ML-DSA y SLH-DSA usando `@noble/post-quantum` — la implementación TypeScript pura de los nuevos estándares NIST. El repo: **[JuanTorchia/pq-signing-demo](https://github.com/JuanTorchia/pq-signing-demo)** ```bash git clone https://github.com/JuanTorchia/pq-signing-demo npm install npm run demo # demo interactivo completo npm run benchmark # comparativa de tamaños y tiempos ``` Lo que hace el demo: **1. SoftwareHSM con 6 algoritmos** Toda la lógica de clave privada está encapsulada. El exterior solo recibe `KeyPair` (con la clave pública) y `SignatureResult` (solo la firma). Mismo modelo de seguridad que un HSM de hardware, sin el hardware. ```typescript interface HSMProvider { generateKeyPair(algorithm: Algorithm, label: string): Promise sign(keyId: string, data: Uint8Array): Promise verify(keyId: string, data: Uint8Array, signature: Uint8Array): Promise } ``` Cuando llegue el firmware de tu vendor, reemplazás la implementación. El resto del código no cambia — eso es crypto-agility en la práctica. **2. Firma de documentos** ```typescript const doc = "Acuerdo de servicios — Abril 2026" const ecdsaDoc = await signDocument(doc, "ecdsa-p256") // 64 bytes const mldsaDoc = await signDocument(doc, "ml-dsa-65") // 3309 bytes const valid = await verifyDocument(mldsaDoc) // ✅ ``` **3. JWT con ML-DSA-65** El demo implementa el formato del borrador IETF `draft-ietf-cose-dilithium`, con `alg: "ML-DSA-65"` en el header. El token resultante tiene ~4.600 chars vs ~250 de un JWT ES256 típico. La implicancia práctica: para tokens de larga vida o firma de documentos, perfecto. Para millones de access tokens de corta vida por día, vas a querer esperar a que salga ML-DSA-44 o FN-DSA. **4. El benchmark muestra los trade-offs reales** ``` ── Tamaño de Firma ───────────────────────────────── ecdsa-p256 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 64 bytes (1x) ml-dsa-44 █████████░░░░░░░░░░░░░░░░░░░░░ 2420 bytes (38x) ml-dsa-65 █████████████░░░░░░░░░░░░░░░░░ 3309 bytes (52x) slh-dsa-sha2-128s ██████████████████████████████ 7856 bytes (123x) ── Tiempo de Firma (promedio 20 iteraciones) ─────── ecdsa-p256 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0.99 ms ml-dsa-65 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 4.64 ms slh-dsa-sha2-128s ██████████████████████████████ 3806.09 ms ``` SLH-DSA tiene firmas grandes Y es lento — está ahí como backup de máxima seguridad, no como reemplazo práctico de ECDSA. ML-DSA-65 a 4.6ms de firma es completamente viable en producción. --- ## Qué hacer ahora mismo **1. Inventariá tu superficie criptográfica.** Mapeá dónde firmás digitalmente hoy: certificados TLS, firma de documentos, JWTs, firma de código, certificados de CA intermedias. Para cada uno, anotá: qué algoritmo usa, qué HSM lo respalda, y cuánto tiempo tiene que seguir siendo válida esa firma. Los documentos firmados con ECDSA que tienen que ser válidos en 2035 son los primeros en la lista. **2. Consultá con tu vendor de HSM.** Las preguntas concretas: - ¿Tu modelo de HSM tiene soporte ML-DSA planificado vía firmware? - ¿En qué timeline? - ¿El update mantiene la validación FIPS 140-3 para ML-DSA? - ¿Cómo migran las claves existentes? **3. Empezá a probar con el stack OQS.** El proyecto *Open Quantum Safe* (liboqs + oqs-provider para OpenSSL) te deja experimentar con ML-DSA hoy, sin hardware real. Es el ambiente para entender cómo cambian los tamaños, los tiempos, y qué impacto tiene en tu infraestructura de certificados. ```bash docker run -it openquantumsafe/oqs-ossl3-img # Ya tiene OpenSSL 3 + oqs-provider instalados openssl list -signature-algorithms | grep mldsa ``` **4. Revisá el tamaño de firma en tus protocolos.** Si tenés un protocolo que asume firmas ECDSA de 64 bytes y vas a mover a ML-DSA-65 de 3.309 bytes, hay implicancias en MTU, en buffers, en validación de tamaño de payload. Mejor descubrirlo en staging. **5. Para sistemas nuevos: arrancá con crypto-agility desde el diseño.** Crypto-agility significa que el algoritmo de firma es configurable, no hardcodeado. La abstracción correcta: ```typescript interface SigningProvider { algorithm: "ecdsa-p256" | "ml-dsa-65" | "hybrid-ecdsa-mldsa65" sign(data: Buffer): Promise verify(data: Buffer, signature: Buffer, publicKey: Buffer): Promise publicKey(): Promise } ``` Cuando llegue el momento de migrar, cambiás la implementación, no la arquitectura. --- ## El deadline real La NSA requiere que todos los sistemas de seguridad nacional (NSS) completen la migración a PQC antes de 2030. NIST IR 8547 establece que los algoritmos vulnerables a quantum (RSA, ECDSA, ECDH, DH) van a ser **deprecados y removidos de los estándares NIST antes de 2035**. La Comisión Europea espera que todos los estados miembro tengan un plan de migración completo implementado para fin de 2026. No es ciencia ficción. Es un calendario de compliance que ya está corriendo. El problema no es que la computadora cuántica exista hoy. El problema es que la infraestructura de clave pública tarda años en migrar, los certificados tienen vidas largas, y los documentos firmados hoy tienen que seguir siendo verificables en 2035. Ese tiempo ya está consumiendo. --- *El código de ejemplo de OpenSSL y PKCS#11 asume OpenSSL 3.x con oqs-provider y PKCS#11 v3.x con soporte ML-DSA del vendor. Para firmé digital en producción, chequeá el estado de soporte de tu HSM antes de commitear a una implementación.* 13:["$","main",null,{"className":"min-h-screen bg-paper","children":[["$","script",null,{"type":"application/ld+json","dangerouslySetInnerHTML":{"__html":"{\"@context\":\"https://schema.org\",\"@type\":\"BreadcrumbList\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https://juanchi.dev/en\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Blog\",\"item\":\"https://juanchi.dev/en/blog\"}]}"}}],["$","script",null,{"type":"application/ld+json","dangerouslySetInnerHTML":{"__html":"{\"@context\":\"https://schema.org\",\"@type\":\"CollectionPage\",\"@id\":\"https://juanchi.dev/en/blog#webpage\",\"url\":\"https://juanchi.dev/en/blog\",\"name\":\"Blog | Juanchi.dev\",\"description\":\"Articles on software architecture, performance, Next.js, TypeScript, Java, AI engineering and more.\",\"inLanguage\":\"en-US\",\"isPartOf\":{\"@id\":\"https://juanchi.dev/en#website\"},\"about\":{\"@id\":\"https://juanchi.dev/#person\"},\"mainEntity\":{\"@type\":\"ItemList\",\"numberOfItems\":0,\"itemListElement\":[]}}"}}],["$","a",null,{"href":"#main-content","className":"sr-only focus:not-sr-only focus:absolute focus:top-4 focus:left-4 focus:z-50 focus:rounded-input focus:bg-brand focus:px-4 focus:py-2 focus:text-brand-ink","children":"Skip to content"}],["$","$L7",null,{}],["$","div",null,{"id":"main-content","className":"pt-20 md:pt-28","children":["$L2d",["$","div",null,{"className":"max-w-7xl mx-auto px-4 pb-24","children":[["$","div",null,{"className":"pt-8","children":["$","$15",null,{"fallback":["$","div",null,{"className":"h-10 w-full max-w-md rounded-input bg-paper-2"}],"children":["$","$L2e",null,{}]}]}],["$","nav",null,{"aria-label":"Categories","className":"lg:hidden mt-6 mb-8 flex flex-wrap gap-x-4 gap-y-2","children":["$L2f",["$L30","$L31","$L32","$L33","$L34","$L35"]]}],null,["$","div",null,{"className":"grid lg:grid-cols-[minmax(0,1fr)_280px] gap-x-12 gap-y-16","children":[["$","section",null,{"aria-labelledby":"posts-heading","children":[["$","div",null,{"className":"mb-4 flex items-baseline justify-between gap-4","children":[["$","h2",null,{"id":"posts-heading","className":"font-mono text-2xs uppercase tracking-wide text-ink-3","children":"Results for “dependencias”"}],["$","span",null,{"className":"tabular font-mono text-2xs text-ink-3","children":0}]]}],["$","div",null,{"className":"border-t border-rule py-20","children":[["$","p",null,{"className":"text-ink-2","children":"No results"}],"$L36"]}]]}],["$","div",null,{"className":"hidden lg:block","children":["$","$15",null,{"fallback":["$","div",null,{"className":"h-[500px] rounded-card bg-paper-2"}],"children":["$","$L37",null,{"currentTag":"$undefined","currentCategory":"$undefined","categories":[{"id":"cmo2conzs0005hjg6pxsda5wu","name":"Experiments","slug":"experiments","description":"Proofs of concept and technical demos.","color":"bg-purple-500","icon":null,"createdAt":"$D2026-04-17T03:30:24.761Z","updatedAt":"$D2026-04-17T03:30:24.761Z","_count":{"posts":99},"categoryId":"cmkkjqwsp00031bxgyau6zmfe","locale":"en"},{"id":"cmo2conve0003hjg6d4x12z9o","name":"Tutorials","slug":"tutorials","description":"Step-by-step guides to learn new tech.","color":"bg-green-500","icon":null,"createdAt":"$D2026-04-17T03:30:24.602Z","updatedAt":"$D2026-04-17T03:30:24.602Z","_count":{"posts":96},"categoryId":"cmkkjqw6t00021bxgyx2wwxmo","locale":"en"},{"id":"cmo2coocx000bhjg6q15qkumz","name":"Opinion","slug":"opinion","description":"Personal takes on the ecosystem.","color":"bg-red-500","icon":null,"createdAt":"$D2026-04-17T03:30:25.233Z","updatedAt":"$D2026-04-17T03:30:25.233Z","_count":{"posts":44},"categoryId":"cmkkjqykd00061bxgmlcmrqcn","locale":"en"},{"id":"cmo2conmp0001hjg6gwz2b0uw","name":"Reflections","slug":"reflections","description":"Thoughts on the industry and the dev life.","color":"bg-blue-500","icon":null,"createdAt":"$D2026-04-17T03:30:24.289Z","updatedAt":"$D2026-04-17T03:30:24.289Z","_count":{"posts":18},"categoryId":"cmkkjqv8h00011bxgocvx2lpt","locale":"en"},{"id":"cmo2coo8i0009hjg6dpdn95ym","name":"Technology","slug":"technology","description":"News and analysis of tools.","color":"bg-cyan-500","icon":null,"createdAt":"$D2026-04-17T03:30:25.074Z","updatedAt":"$D2026-04-17T03:30:25.074Z","_count":{"posts":8},"categoryId":"cmkkjqxz500051bxgiqawn0mp","locale":"en"},{"id":"cmo2coo440007hjg61faznxd1","name":"History","slug":"history","description":"Stories from the tech past.","color":"bg-yellow-500","icon":null,"createdAt":"$D2026-04-17T03:30:24.917Z","updatedAt":"$D2026-04-17T03:30:24.917Z","_count":{"posts":6},"categoryId":"cmkkjqxe400041bxgteily965","locale":"en"}],"tags":[{"id":"cmkkjsdj1000tgws60e5p0ud4","name":"TypeScript","slug":"typescript","createdAt":"$D2026-01-19T02:30:16.958Z","updatedAt":"$D2026-01-19T02:30:16.958Z","_count":{"posts":110}},{"id":"cmnrbcj8z0011am2v25r8j1fw","name":"arquitectura","slug":"arquitectura","createdAt":"$D2026-04-09T10:07:31.187Z","updatedAt":"$D2026-04-09T10:07:31.187Z","_count":{"posts":62}},{"id":"cmnngs4z40007134w8t5y7eyu","name":"nextjs","slug":"nextjs","createdAt":"$D2026-04-06T17:28:32.561Z","updatedAt":"$D2026-04-06T17:28:32.561Z","_count":{"posts":44}},{"id":"cmnngu0zr000j134wd2vnxdma","name":"railway","slug":"railway","createdAt":"$D2026-04-06T17:30:00.711Z","updatedAt":"$D2026-04-06T17:30:00.711Z","_count":{"posts":42}},{"id":"cmoykeywx0006js4vnpyvapa0","name":"java","slug":"java","createdAt":"$D2026-05-09T16:35:26.913Z","updatedAt":"$D2026-05-09T16:35:26.913Z","_count":{"posts":38}},{"id":"cmnnunbue000bokqrq0uxgeqd","name":"LLM","slug":"llm","createdAt":"$D2026-04-06T23:56:42.806Z","updatedAt":"$D2026-04-06T23:56:42.806Z","_count":{"posts":43}},{"id":"cmnngxhrr0010134wv66ig0pu","name":"postgresql","slug":"postgresql","createdAt":"$D2026-04-06T17:32:42.423Z","updatedAt":"$D2026-04-06T17:32:42.423Z","_count":{"posts":27}},{"id":"cmnnup3s2000tokqrr89xctng","name":"ia","slug":"ia","createdAt":"$D2026-04-06T23:58:05.667Z","updatedAt":"$D2026-04-06T23:58:05.667Z","_count":{"posts":17}},{"id":"cmoykip41000mjs4vyxhgjrcd","name":"prisma","slug":"prisma","createdAt":"$D2026-05-09T16:38:20.833Z","updatedAt":"$D2026-05-09T16:38:20.833Z","_count":{"posts":10}},{"id":"cmoo6fheq000m5gtmywa04l8z","name":"software-architecture","slug":"software-architecture","createdAt":"$D2026-05-02T10:06:14.498Z","updatedAt":"$D2026-05-02T10:06:14.498Z","_count":{"posts":1}},{"id":"cmpqrkqgk003hdtn8p695grkl","name":"firma-digital","slug":"firma-digital","createdAt":"$D2026-05-29T10:13:26.133Z","updatedAt":"$D2026-05-29T10:13:26.133Z","_count":{"posts":5}},{"id":"cmnogdcas000211t4s0lqkqj7","name":"AI","slug":"ai","createdAt":"$D2026-04-07T10:04:48.389Z","updatedAt":"$D2026-04-07T10:04:48.389Z","_count":{"posts":3}}],"popularPosts":[{"id":"cmnn796ir00013bk0ynnhe1n2","title":"pnpm vs npm vs yarn vs bun: The Real Comparison Nobody Gives You in 2025","slug":"pnpm-vs-npm-vs-yarn-vs-bun-definitive-comparison-2025","excerpt":"I used all four in real projects. One wrecked a monorepo at 3am. Another saved my ass in production. Here's the unfiltered truth about every major package manager in 2025.","content":"$38","coverImage":"https://images.unsplash.com/photo-1593720218365-b2076cfdefee?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&q=80&w=1080","readTime":8,"views":1507,"likes":0,"published":true,"featured":false,"metaTitle":"npm vs pnpm vs yarn vs bun: the honest comparison","metaDescription":"Install times, disk usage, monorepo support and CI behaviour compared across npm, pnpm, yarn and bun. Which one to pick, and when it does not matter.","ogImage":null,"devToUrl":"https://dev.to/juantorchia/pnpm-vs-npm-vs-yarn-vs-bun-la-comparativa-definitiva-que-nadie-te-va-a-dar-en-2025-4nlf","devToId":3462712,"publishedAt":"$D2026-04-06T13:01:51.536Z","createdAt":"$D2026-04-06T13:01:51.536Z","updatedAt":"$D2026-09-21T19:21:32.937Z","authorId":"cmkkjqu9m00001bxglhj96p5d","seriesId":null,"seriesOrder":null,"categoryId":"cmkkjqxz500051bxgiqawn0mp","author":{"name":"Juanchi Torchia","avatar":"/avatar-placeholder.png"},"category":{"id":"cmo2coo8i0009hjg6dpdn95ym","name":"Technology","slug":"technology","description":"News and analysis of tools.","color":"bg-cyan-500","icon":null,"createdAt":"$D2026-04-17T03:30:25.074Z","updatedAt":"$D2026-04-17T03:30:25.074Z","categoryId":"cmkkjqxz500051bxgiqawn0mp","locale":"en"},"tags":[{"id":"cmnn796rw00023bk01cts8jt4","name":"pnpm","slug":"pnpm","createdAt":"$D2026-04-06T13:01:51.885Z","updatedAt":"$D2026-04-06T13:01:51.885Z"},{"id":"cmnn798wr00033bk0epw8rd9q","name":"npm","slug":"npm","createdAt":"$D2026-04-06T13:01:54.652Z","updatedAt":"$D2026-04-06T13:01:54.652Z"},{"id":"cmnn79a7k00043bk0z8fq0mgs","name":"yarn","slug":"yarn","createdAt":"$D2026-04-06T13:01:56.337Z","updatedAt":"$D2026-04-06T13:01:56.337Z"},{"id":"cmnn79bi600053bk0aa7stg06","name":"bun","slug":"bun","createdAt":"$D2026-04-06T13:01:58.014Z","updatedAt":"$D2026-04-06T13:01:58.014Z"},{"id":"cmnn79csw00063bk06o7m9y8b","name":"package manager","slug":"package-manager","createdAt":"$D2026-04-06T13:01:59.696Z","updatedAt":"$D2026-04-06T13:01:59.696Z"},{"id":"cmnn79e3e00073bk0889iwzb3","name":"javascript","slug":"javascript","createdAt":"$D2026-04-06T13:02:01.370Z","updatedAt":"$D2026-04-06T13:02:01.370Z"},{"id":"cmnn79fdo00083bk0yuu6hjyv","name":"node.js","slug":"nodejs","createdAt":"$D2026-04-06T13:02:03.036Z","updatedAt":"$D2026-04-06T13:02:03.036Z"},{"id":"cmnn79go200093bk0nevuz3ih","name":"monorepo","slug":"monorepo","createdAt":"$D2026-04-06T13:02:04.706Z","updatedAt":"$D2026-04-06T13:02:04.706Z"},{"id":"cmnn79i37000a3bk0caq72ink","name":"frontend","slug":"frontend","createdAt":"$D2026-04-06T13:02:06.398Z","updatedAt":"$D2026-04-06T13:02:06.398Z"},{"id":"cmnn79jdr000b3bk0c5xo34qp","name":"tooling","slug":"tooling","createdAt":"$D2026-04-06T13:02:08.223Z","updatedAt":"$D2026-04-06T13:02:08.223Z"}],"_count":{"comments":0},"tldr":"pnpm wins as the best all-around package manager in 2025. npm is slow and bloated but frictionless for small projects, Yarn Berry's PnP creates real ecosystem pain, and Bun is fast but still maturing. pnpm's content-addressable store and strict dependency resolution make it the clear choice for monorepos and production work.","reviewedByAuthor":false,"reviewedAt":null},{"id":"cmnngs4ul0006134wip46nhvm","title":"Next.js App Router: The Guide I Wish I Had When I Migrated from Pages Router","slug":"nextjs-app-router-migration-guide-from-pages-router","excerpt":"I migrated three production projects from Pages Router to App Router and broke everything twice before I truly understood how it works. Server Components, streaming, cache, nested layouts — here's everything nobody tells you.","content":"$39","coverImage":"https://images.unsplash.com/photo-1750711158632-5273ec9b9b86?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3w5MTc1Mjd8MHwxfHNlYXJjaHw0fHxuZXh0JTIwcm91dGVyJTIwZ3UlQzMlQURhfGVufDF8MHx8fDE3NzU1MTUxOTV8MA&ixlib=rb-4.1.0&q=80&w=1080","readTime":11,"views":1106,"likes":0,"published":true,"featured":false,"metaTitle":"Next.js App Router: Migration Guide from Pages Router (2024)","metaDescription":"I migrated 3 production projects to Next.js App Router and broke everything twice. The real guide: Server Components, streaming, cache, common mistakes, and what nobody explains.","ogImage":null,"devToUrl":"https://dev.to/juantorchia/nextjs-app-router-la-guia-que-me-hubiera-gustado-tener-cuando-migre-de-pages-router-5cef","devToId":3462710,"publishedAt":"$D2026-04-06T17:28:32.396Z","createdAt":"$D2026-04-06T17:28:32.398Z","updatedAt":"$D2026-08-22T01:31:04.164Z","authorId":"cmkkjqu9m00001bxglhj96p5d","seriesId":null,"seriesOrder":null,"categoryId":"cmkkjqw6t00021bxgyx2wwxmo","author":{"name":"Juanchi Torchia","avatar":"/avatar-placeholder.png"},"category":{"id":"cmo2conve0003hjg6d4x12z9o","name":"Tutorials","slug":"tutorials","description":"Step-by-step guides to learn new tech.","color":"bg-green-500","icon":null,"createdAt":"$D2026-04-17T03:30:24.602Z","updatedAt":"$D2026-04-17T03:30:24.602Z","categoryId":"cmkkjqw6t00021bxgyx2wwxmo","locale":"en"},"tags":[{"id":"cmkkjs9pr000fgws6maov1sph","name":"Tutorial","slug":"tutorial","createdAt":"$D2026-01-19T02:30:12.016Z","updatedAt":"$D2026-01-19T02:30:12.016Z"},{"id":"cmkkjs9pr000hgws65yj0azlv","name":"React","slug":"react","createdAt":"$D2026-01-19T02:30:12.016Z","updatedAt":"$D2026-01-19T02:30:12.016Z"},{"id":"cmkkjsdj1000tgws60e5p0ud4","name":"TypeScript","slug":"typescript","createdAt":"$D2026-01-19T02:30:16.958Z","updatedAt":"$D2026-01-19T02:30:16.958Z"},{"id":"cmnngs4z40007134w8t5y7eyu","name":"nextjs","slug":"nextjs","createdAt":"$D2026-04-06T17:28:32.561Z","updatedAt":"$D2026-04-06T17:28:32.561Z"},{"id":"cmnngs69z0008134w9ss8ghpq","name":"app-router","slug":"app-router","createdAt":"$D2026-04-06T17:28:34.247Z","updatedAt":"$D2026-04-06T17:28:34.247Z"},{"id":"cmnngs8z6000a134wll5rzfsu","name":"server-components","slug":"server-components","createdAt":"$D2026-04-06T17:28:37.746Z","updatedAt":"$D2026-04-06T17:28:37.746Z"},{"id":"cmnngsbk3000c134wmh5oc7nq","name":"web-development","slug":"web-development","createdAt":"$D2026-04-06T17:28:41.091Z","updatedAt":"$D2026-04-06T17:28:41.091Z"}],"_count":{"comments":0},"tldr":"Migrating from Pages Router to App Router requires a full mental model reset, not just a folder restructure. Every component is a Server Component by default; use `'use client'` only for interactivity or browser APIs. Data fetching moves directly into async components, nested layouts persist across navigation, and Next.js caches fetch calls by default.","reviewedByAuthor":false,"reviewedAt":null},{"id":"cmnngvnp0000p134w89l56aga","title":"TypeScript: The Patterns I Actually Use Every Single Day","slug":"typescript-patterns-i-actually-use-every-day","excerpt":"Discriminated unions, branded types, advanced generics, and how I actually think about types when I code. Not an academic tutorial — this is what I use in production after years of fighting TypeScript.","content":"$3a","coverImage":"https://images.unsplash.com/photo-1699885960867-56d5f5262d38?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3w5MTc1Mjd8MHwxfHNlYXJjaHwxfHx0eXBlc2NyaXB0JTIwcGF0cm9uZXMlMjByZWFsbWVudGV8ZW58MXwwfHx8MTc3NTUxNTE5Mnww&ixlib=rb-4.1.0&q=80&w=1080","readTime":10,"views":1101,"likes":0,"published":true,"featured":false,"metaTitle":"TypeScript Advanced Patterns: Discriminated Unions, Branded Types","metaDescription":"TypeScript patterns I actually use in production: discriminated unions, branded types, advanced generics, and domain-first thinking. Real examples, no fluff.","ogImage":null,"devToUrl":"https://dev.to/juantorchia/typescript-los-patrones-que-realmente-uso-todos-los-dias-lc5","devToId":3462691,"publishedAt":"$D2026-04-06T17:31:16.787Z","createdAt":"$D2026-04-06T17:31:16.789Z","updatedAt":"$D2026-09-18T12:13:59.289Z","authorId":"cmkkjqu9m00001bxglhj96p5d","seriesId":null,"seriesOrder":null,"categoryId":"cmkkjqw6t00021bxgyx2wwxmo","author":{"name":"Juanchi Torchia","avatar":"/avatar-placeholder.png"},"category":{"id":"cmo2conve0003hjg6d4x12z9o","name":"Tutorials","slug":"tutorials","description":"Step-by-step guides to learn new tech.","color":"bg-green-500","icon":null,"createdAt":"$D2026-04-17T03:30:24.602Z","updatedAt":"$D2026-04-17T03:30:24.602Z","categoryId":"cmkkjqw6t00021bxgyx2wwxmo","locale":"en"},"tags":[{"id":"cmkkjsdj1000tgws60e5p0ud4","name":"TypeScript","slug":"typescript","createdAt":"$D2026-01-19T02:30:16.958Z","updatedAt":"$D2026-01-19T02:30:16.958Z"},{"id":"cmnn79e3e00073bk0889iwzb3","name":"javascript","slug":"javascript","createdAt":"$D2026-04-06T13:02:01.370Z","updatedAt":"$D2026-04-06T13:02:01.370Z"},{"id":"cmnngvq5r000r134weevvfllb","name":"Patrones de diseño","slug":"patrones-de-diseo","createdAt":"$D2026-04-06T17:31:19.983Z","updatedAt":"$D2026-04-06T17:31:19.983Z"},{"id":"cmnngvrmf000s134wcm0riuhd","name":"Full Stack","slug":"full-stack","createdAt":"$D2026-04-06T17:31:21.879Z","updatedAt":"$D2026-04-06T17:31:21.879Z"},{"id":"cmnngvubm000u134w8k5bp6uz","name":"Programación","slug":"programacin","createdAt":"$D2026-04-06T17:31:25.378Z","updatedAt":"$D2026-04-06T17:31:25.378Z"}],"_count":{"comments":0},"tldr":"Discriminated unions and branded types are the two TypeScript patterns worth internalizing first. Discriminated unions model state with zero ambiguity and exhaustiveness checking; branded types prevent mixing structurally identical primitives like UserId and ProductId. Both eliminate entire bug categories that unit tests routinely miss.","reviewedByAuthor":false,"reviewedAt":null},{"id":"cmnnf3b7x00012vuon71zio75","title":"Docker for Node.js Developers: From Zero to Production Without Losing Your Mind","slug":"docker-for-nodejs-developers-zero-to-production","excerpt":"Three broken Dockerfiles, two production outages, and one sleepless night — that's what it cost me to really understand Docker with Node.js. Here's everything I learned so you don't have to pay the same price.","content":"$3b","coverImage":"https://images.unsplash.com/photo-1666576005530-7f99559bbd79?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3w5MTc1Mjd8MHwxfHNlYXJjaHw1fHxkb2NrZXIlMjBkZXNhcnJvbGxhZG9yZXMlMjBub2RlfGVufDF8MHx8fDE3NzU1MTUxOTl8MA&ixlib=rb-4.1.0&q=80&w=1080","readTime":9,"views":1075,"likes":0,"published":true,"featured":false,"metaTitle":"Docker for Node.js: Complete Zero to Production Guide | Juanchi Torchia","metaDescription":"Dockerfile, Docker Compose, multi-stage builds and environment variables for Node.js in production. Real-world tutorial with actual mistakes, hard lessons, and proven solutions.","ogImage":null,"devToUrl":"https://dev.to/juantorchia/docker-para-desarrolladores-nodejs-de-cero-a-produccion-sin-morir-en-el-intento-428p","devToId":3462689,"publishedAt":"$D2026-04-06T16:41:14.635Z","createdAt":"$D2026-04-06T16:41:14.638Z","updatedAt":"$D2026-09-14T07:40:17.040Z","authorId":"cmkkjqu9m00001bxglhj96p5d","seriesId":null,"seriesOrder":null,"categoryId":"cmkkjqw6t00021bxgyx2wwxmo","author":{"name":"Juanchi Torchia","avatar":"/avatar-placeholder.png"},"category":{"id":"cmo2conve0003hjg6d4x12z9o","name":"Tutorials","slug":"tutorials","description":"Step-by-step guides to learn new tech.","color":"bg-green-500","icon":null,"createdAt":"$D2026-04-17T03:30:24.602Z","updatedAt":"$D2026-04-17T03:30:24.602Z","categoryId":"cmkkjqw6t00021bxgyx2wwxmo","locale":"en"},"tags":[{"id":"cmkkjs9pr000fgws6maov1sph","name":"Tutorial","slug":"tutorial","createdAt":"$D2026-01-19T02:30:12.016Z","updatedAt":"$D2026-01-19T02:30:12.016Z"},{"id":"cmkkjsdj1000tgws60e5p0ud4","name":"TypeScript","slug":"typescript","createdAt":"$D2026-01-19T02:30:16.958Z","updatedAt":"$D2026-01-19T02:30:16.958Z"},{"id":"cmnn79fdo00083bk0yuu6hjyv","name":"node.js","slug":"nodejs","createdAt":"$D2026-04-06T13:02:03.036Z","updatedAt":"$D2026-04-06T13:02:03.036Z"},{"id":"cmnnf3bgv00022vuo22k4amnl","name":"docker","slug":"docker","createdAt":"$D2026-04-06T16:41:14.959Z","updatedAt":"$D2026-04-06T16:41:14.959Z"},{"id":"cmnnf3f4e00042vuoqqiybwbv","name":"devops","slug":"devops","createdAt":"$D2026-04-06T16:41:19.695Z","updatedAt":"$D2026-04-06T16:41:19.695Z"},{"id":"cmnnf3hsc00062vuorpdf2mn7","name":"backend","slug":"backend","createdAt":"$D2026-04-06T16:41:23.149Z","updatedAt":"$D2026-04-06T16:41:23.149Z"},{"id":"cmnnf3kg000082vuo7kix5l0f","name":"docker-compose","slug":"docker-compose","createdAt":"$D2026-04-06T16:41:26.592Z","updatedAt":"$D2026-04-06T16:41:26.592Z"},{"id":"cmnnf3ns900092vuo3fxtkcr6","name":"produccion","slug":"produccion","createdAt":"$D2026-04-06T16:41:30.759Z","updatedAt":"$D2026-04-06T16:41:30.759Z"}],"_count":{"comments":0},"tldr":"Docker and Node.js pair well, but only if you get the details right. Use Alpine images, always write a .dockerignore to avoid leaking secrets or bloating the build context, copy package.json before source files to exploit layer caching, and use npm ci for deterministic installs. Docker Compose handles the rest locally.","reviewedByAuthor":false,"reviewedAt":null},{"id":"cmnsx2riz0001u2rzhmtn0a3f","title":"Your Digital Signing Cryptography Has an Expiration Date: What NIST Published and How to Migrate Your HSM","slug":"nist-post-quantum-digital-signing-hsm-migration-ml-dsa-fips-204","excerpt":"NIST finalized post-quantum standards in August 2024. RSA and ECDSA have a 2035 deadline. If you're signing documents, JWTs, or certificates with an HSM, this affects you right now — here's ML-DSA, what it means for your hardware, and what to do this week.","content":"$3c","coverImage":"https://images.unsplash.com/photo-1555066931-78c471f0d4ea?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3w5MTc1Mjd8MHwxfHNlYXJjaHwzfHxUeXBlU2NyaXB0JTIwZGV2b3BzJTIwc2VndXJpZGFkfGVufDF8MHx8fDE3NzU4NDI1NDh8MA&ixlib=rb-4.1.0&q=80&w=1080","readTime":16,"views":1033,"likes":0,"published":true,"featured":false,"metaTitle":"NIST post-quantum: migrate signing & HSM to ML-DSA (FIPS 204)","metaDescription":"NIST published FIPS 204 (ML-DSA) in August 2024. RSA and ECDSA have a 2035 deadline. Practical guide to migrating digital signature infrastructure and HSMs to post-quantum cryptography.","ogImage":null,"devToUrl":null,"devToId":null,"publishedAt":"$D2026-04-10T13:04:42.400Z","createdAt":"$D2026-04-10T13:03:33.084Z","updatedAt":"$D2026-09-08T21:30:31.416Z","authorId":"cmkkjqu9m00001bxglhj96p5d","seriesId":null,"seriesOrder":null,"categoryId":null,"author":{"name":"Juanchi Torchia","avatar":"/avatar-placeholder.png"},"category":null,"tags":[{"id":"cmkkjsdj1000tgws60e5p0ud4","name":"TypeScript","slug":"typescript","createdAt":"$D2026-01-19T02:30:16.958Z","updatedAt":"$D2026-01-19T02:30:16.958Z"},{"id":"cmnnf3f4e00042vuoqqiybwbv","name":"devops","slug":"devops","createdAt":"$D2026-04-06T16:41:19.695Z","updatedAt":"$D2026-04-06T16:41:19.695Z"},{"id":"cmnnup3pr000qokqr62uxzkkw","name":"seguridad","slug":"seguridad","createdAt":"$D2026-04-06T23:58:05.583Z","updatedAt":"$D2026-04-06T23:58:05.583Z"},{"id":"cmnsx2tx70003u2rzxe2p1zs8","name":"criptografia","slug":"criptografia","createdAt":"$D2026-04-10T13:03:36.188Z","updatedAt":"$D2026-04-10T13:03:36.188Z"}],"_count":{"comments":0},"tldr":"NIST finalized post-quantum signature standards in August 2024, giving RSA and ECDSA a hard 2035 deadline. ML-DSA (FIPS 204) is the practical ECDSA replacement, but its 38x larger signatures and expanded key sizes require HSM firmware updates, PKCS#11 patches, and middleware changes you should start planning now.","reviewedByAuthor":false,"reviewedAt":null}],"series":[{"id":"cmo2fcs4g0007oxspzwip0qlx","name":"Java Champion Journey","slug":"java-champion-journey","description":"My road to Java Champion: JVM architecture, Spring Boot in production, enterprise patterns, and honest opinions about the Java ecosystem.","coverImage":null,"createdAt":"$D2026-04-17T04:45:09.089Z","updatedAt":"$D2026-04-17T04:45:09.089Z","_count":{"posts":0},"seriesId":"cmo28f9v70001mocaam3mtklu","locale":"en"},{"id":"cmo2fcnxf0005oxspb2i9vezg","name":"Open Data and Creativity","slug":"open-data-and-creativity","description":"A series of experiments turning Argentine public data into sensory experiences. How to think like an architect when the ideal data doesn't exist — and when it does.","coverImage":null,"createdAt":"$D2026-04-17T04:45:03.498Z","updatedAt":"$D2026-04-17T04:45:03.498Z","_count":{"posts":2},"seriesId":"cmny1a43l00002jkaaw7gx4gk","locale":"en"},{"id":"cmo2fcjhg0003oxspxh123sfe","name":"Awesome Curated: The Tools","slug":"awesome-curated-tools","description":"Deep dives into the tools that pass our automated curation system's filter. Each post breaks down a specific tool: why it made the list, when to use it, when not to.","coverImage":null,"createdAt":"$D2026-04-17T04:44:57.893Z","updatedAt":"$D2026-04-17T04:44:57.893Z","_count":{"posts":11},"seriesId":"cmnx8agrp0000550v79w0qnzy","locale":"en"},{"id":"cmo2fceg10001oxspzmthr00g","name":"Awesome Curated","slug":"awesome-curated","description":"Building a self-regulating curation system for awesome lists. Weekly GitHub harvesting, cross-source deduplication, Claude-powered classification, and human verdict. Engineering diary.","coverImage":null,"createdAt":"$D2026-04-17T04:44:51.362Z","updatedAt":"$D2026-04-17T04:44:51.362Z","_count":{"posts":1},"seriesId":"cmnwopugq0000n97675wworwp","locale":"en"}]}]}]}]]}],"$L3d"]}]]}],"$L3e"]}]