El 90% de los Developers Trata Resend Como SendGrid v2. Ese Es el Error.
Si estás llamando a resend.emails.send() desde una ruta de Next.js con un string HTML concatenado, no estás usando Resend.
Estás usando SendGrid con una API más bonita.
Has cambiado el logo pero no el patrón. Sigue siendo email-as-string-template, solo que con un SDK nuevo. El problema no es que funcione — es que podría funcionar mucho mejor y no lo sabes porque nadie te ha enseñado el salto mental.
Resend, lanzado en 2023 por Zeno Rocha, no es "un servicio de email más". Su innovación real es forzarte a repensar el email como un primitivo tipado, type-safe y SDK-first. La pregunta no es "¿puede enviar emails?" — cualquier API puede. La pregunta es: ¿tu setup te hace más o menos propenso a enviar emails rotos en producción?
Este tutorial no es "cómo configurar Resend en 5 minutos". Eso ya lo cubrimos en artículos anteriores. Esto es cómo configurarlo bien — y por qué la mayoría lo está haciendo mal.
---
Por Qué el Patrón Tradicional de Email Está Roto
El Problema de las Cadenas de Texto
El enfoque clásico de email templating es concatenar strings. Coges un template HTML, interpolas variables con ${} o {{}}, y envías.
❌ Patrón roto (lo que hace el 90%):
¿Qué pasa si user.name es undefined? ¿Si user.code es un número y esperabas un string? ¿Si la estructura del HTML se rompe porque una variable contiene HTML sin escapar?
No lo sabes hasta que el email llega al cliente y lo ves en producción.
Eso no es development. Es debugging reactivo.
✅ Patrón correcto (React Email + TypeScript):
Cada prop está tipada. Si olvidas pasar verificationCode, TypeScript te lo dice antes de hacer deploy. No en producción. No en un ticket de soporte. En tu editor.
El Mito del 'SMTP Es Suficiente'
Los desarrolladores seniors suelen decir: "no necesitas una API, usa nodemailer con SMTP".
Eso ignora cuatro realidades:
- Las credenciales SMTP son estáticas — contraseñas planas en variables de entorno, sin rotación automática
- SMTP es stateful — conexiones lentas, handshakes TCP, timeouts
- SMTP no da observabilidad — sin analytics, sin webhooks, sin tracking de entregas
- SMTP no funciona en edge runtimes — ni Cloudflare Workers, ni Vercel Edge, ni Deno Deploy. Todos necesitan módulos
net/tlsde Node.js que no existen ahí
Resend resuelve esto con una API HTTP que funciona donde sea que fetch() funcione. Eso no es una feature — es un requisito arquitectónico si trabajas con serverless moderno.
---
La Evidencia: Resend No Es un Commodity
El API Más Simple del Mercado
Compara el endpoint de envío de Resend con el de SendGrid.
Resend: un solo POST /emails con tres campos obligatorios: from, to, y subject + html o react.
SendGrid: múltiples endpoints, categorías, plantillas, subsections, asm groups, sandbox mode, validaciones pre-envio...
Resend tiene aproximadamente un 70% menos de campos obligatorios que el endpoint Mail Send de SendGrid.
Eso no es casualidad. Es una decisión de diseño: quitar todo lo que no sea estrictamente necesario para que el developer no tenga que pensar.
React Email: 14.000+ Estrellas en GitHub
React Email (mantenido por Resend) tiene más de 14.000 estrellas en GitHub. No es un side project — es el estándar de facto para email templating en el ecosistema React/Next.js.
¿Qué hace diferente? Los emails son componentes React que se renderizan a HTML en tiempo de build o envío. Esto significa:
- Componentes reutilizables — creas un
Button, unHeader, unFooteruna vez y los usas en todos tus emails - Validación de props — cada componente sabe qué datos espera
- Renderizado condicional —
{showBanner && <Banner />}sin concatenar strings - Bucles tipados —
{items.map(item => <Item key={item.id} {...item} />)}con type-checking - Responsive automático — React Email maneja layouts que funcionan en Outlook, Gmail, Apple Mail
Los bugs de email que antes llegaban a producción (variables faltantes, layouts rotos, espaciados inconsistentes) ahora se capturan en tu editor o en tu pipeline de CI.
---
Análisis: Lo Que el Mercado No Está Viendo
La Trampa de la Comparación con Mailchimp
Muchos desarrolladores evalúan Resend esperando que compita con Mailchimp o Customer.io en features de marketing.
Error de categoría.
Resend es una API de email transaccional con capacidades básicas de broadcast — no un CRM de marketing. Está diseñado para:
- ✅ Reset de contraseñas
- ✅ Notificaciones de sistema
- ✅ Confirmaciones de pedido
- ✅ Verificaciones de email
- ❌ Drip campaigns con A/B testing
- ❌ Segmentación avanzada de audiencias
- ❌ Automatización multicanal
Los equipos que intentan usar Resend como plataforma de marketing completa se frustran. Los equipos que lo usan para lo que fue construido descubren que es dramáticamente más simple que las alternativas.
El Argumento Greenfield vs. Migración
Si ya usas SendGrid, Mailgun o SES y funciona — ¿por qué cambiar?
*No deberías, necesariamente. *
El argumento no es "Resend es mejor" en términos absolutos. Es: si estás empezando un proyecto nuevo hoy, pregúntate si quieres email-as-typed-SDK o email-as-SMTP-string-template. Es un argumento de fundación, no de migración.
Pero si empiezas con el patrón correcto desde el día uno, te ahorras la deuda técnica de tener que refactorizar todo cuando tu primer email de producción llegue con un [object Object] en medio del HTML.
---
El Patrón de 5 Capas para Email Tipado con Resend
Aquí está el framework. No es teoría — es lo que uso en cada proyecto que despliego.
Cap 1: Componentes de Email como React Components
Crea un directorio components/emails/ con todos tus templates como componentes React tipados.
Cada componente es reutilizable, tipado y testeable de forma independiente.
Cap 2: Types Compartidos para Payloads
Define interfaces para cada tipo de email transaccional. El compilador te avisará si te falta un campo antes de enviar nada.
Cap 3: Función Helper Unificada para Envíos
Nunca llames a resend.emails.send() directamente desde rutas, server actions o API routes. Crea una sola función tipada que centralice toda la lógica de envío, reintentos y logs.
Usarlo en cualquier parte de tu app:
¿Qué has ganado? TypeScript te avisa si WelcomeEmail espera un campo que no pasaste. El error se captura en local o en CI. No llega a producción.
Cap 4: Edge Runtime + Resend
Aquí es donde Resend gana por goleada. En un Edge Function o Server Action de Next.js, los módulos SMTP no funcionan. Resend funciona porque solo necesita fetch().
Cap 5: Preview Local con Hot-Reload
React Email incluye un servidor de preview con hot-reload. Puedes ver tus emails en tiempo real mientras los desarrollas, en varios clientes (Gmail, Outlook, Apple Mail).
Esto abre localhost:3001 con todos tus componentes de email renderizados. Cambias el código, el navegador se actualiza. Sin hacer deploy. Sin enviar emails reales.
El loop de desarrollo pasa de:
- Escribir HTML ➡️ subir a producción ➡️ rezar que funcione
A:
- Escribir componente ➡️ ver preview en local ➡️ compilar TypeScript ➡️ desplegar sabiendo que funciona
---
Lo Que No Hacemos en Este Tutorial
- No vamos a configurar webhooks de bounce y complaint — eso lo cubrimos en un artículo anterior
- No vamos a hablar de costes ni planes de precios.
- No vamos a comparar métricas de deliverability entre proveedores.
Este tutorial es sobre el patrón de desarrollo. El resto son detalles de configuración.
---
Conclusión: El Email No Es un String. Es un Componente.
Resend no va a salvar tu stack de email por sí solo. Puedes usarlo mal exactamente igual que SendGrid o Mailgun.
*La diferencia no está en el servicio. Está en el patrón que elijas. *
Si concatenas strings HTML, estás escribiendo código que ya era malo en 2015. Si usas React Email con TypeScript y una capa de abstracción tipada, estás construyendo un sistema donde los bugs de email se capturan antes de llegar al cliente.
El cambio no es difícil. Es un directorio components/emails/, una interfaz TypeScript, y una función helper. Una hora de configuración que te ahorra semanas de debugging.
La próxima vez que te sientes a escribir un email en tu app, pregúntate: ¿esto es un string o es un componente?
Tu yo del futuro — y tus usuarios — te lo agradecerán.
Artículos relacionados
- Resend en Producción: Patrones Avanzados que el Tutorial Básico No Te Enseña
- Resend en Producción: Monitorización, Analíticas y Gestión de Bounces que Nadie Te Explica
- React Email Components: El Patrón que Funciona en el 100% de Clientes de Correo
- Resend Email API Tutorial: El Único Setup que Necesitas en Producción
- Template Design con React Email y Resend: El Sistema de Capas que Previene el Caos en Producción
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
