DEV Community: Eduardo Fuentes

Arquitectura Cloud Moderna para Aplicaciones Web en AWS

Eduardo Fuentes — Sun, 01 Mar 2026 22:21:28 +0000

Cuando aprendemos AWS, solemos estudiar los servicios por separado:
EC2, RDS, S3, VPC…

Pero la verdadera ingeniería comienza cuando entendemos cómo se conectan entre sí para formar una arquitectura escalable, segura y lista para producción.

En este artículo explico una arquitectura moderna para aplicaciones web basada en buenas prácticas.

Objetivo de la arquitectura

Diseñar una infraestructura que sea:

Altamente disponible
Escalable
Segura
Optimizada en costos
Preparada para producción

Punto de Entrada: Route 53 + CloudFront

Cuando un usuario escribe el dominio en su navegador, el flujo correcto es:

Route 53 resuelve el dominio.
El dominio apunta a CloudFront.
CloudFront verifica si el contenido está cacheado en una Edge Location cercana.
Si está cacheado, lo entrega inmediatamente.
Si no está cacheado, consulta al origin.

Nota: No todo el tráfico entra a la VPC. CloudFront actúa como primera capa de optimización y protección.

Contenido Estático: S3 como Origin

Para contenido estático como:

HTML
CSS
JavaScript
Imágenes
Assets del frontend

CloudFront usa Amazon S3 como origin.

Esto permite:

Baja latencia global
Reducción de carga en backend
Menor costo operativo
Mejor experiencia de usuario

Nota: En muchos casos, el frontend completo puede servirse desde S3 + CloudFront sin tocar la VPC.

Contenido Dinámico: ALB como Origin

Cuando la petición requiere lógica de negocio (API, autenticación, base de datos):

CloudFront redirige la solicitud hacia el Application Load Balancer (ALB).

Flujo dinámico:

Usuario → Route 53 → CloudFront → ALB → EC2 → RDS

Aquí recién entramos a la VPC.

VPC: Nuestra Red Privada

La VPC define:

Rango de IPs
Subnets públicas
Subnets privadas
Tablas de ruteo
Gateways

Nota: Es el entorno aislado donde vive nuestra aplicación.

Subnets Públicas

En las subnets públicas normalmente encontramos:

Application Load Balancer
NAT Gateway
Internet Gateway (a nivel VPC)

Nota: El ALB recibe tráfico desde CloudFront. No desde usuarios directamente.

Subnets Privadas (Capa de Aplicación)

Aquí viven las instancias:

EC2 con nuestro backend
Auto Scaling Group (recomendado)

Características:

No tienen IP pública.
Solo reciben tráfico desde el ALB.
Pueden salir a Internet mediante NAT Gateway.

Nota: Esto reduce significativamente la superficie de ataque.

Subnets Privadas (Capa de Datos)

La base de datos (Amazon RDS) se ubica en subnets privadas separadas.

Buenas prácticas aplicadas:

Multi-AZ para alta disponibilidad
Sin acceso público
Security Groups restringidos
Backups automáticos

Nota: Separar aplicación y datos mejora seguridad y organización.

NAT Gateway

Las instancias en subnets privadas pueden necesitar acceso externo para:

Descargar dependencias
Consumir APIs externas
Actualizaciones

Nota: El NAT Gateway permite salida controlada a Internet sin exponer las instancias.

Seguridad por Capas

Esta arquitectura aplica principios clave:

CDN como primera barrera
Separación por capas
Principio de mínimo privilegio
Base de datos no expuesta
Instancias privadas
Balanceo multi-AZ

Nota: La seguridad no es un componente. Es un diseño.

Escalabilidad

La arquitectura permite crecer fácilmente:

Auto Scaling en EC2
Read replicas en RDS
Cacheo en CloudFront
Separación frontend/backend
Migración futura a contenedores (ECS/EKS)

Optimización de Costos

CloudFront reduce tráfico al backend.

S3 es más barato que servir estáticos desde EC2.

Auto Scaling evita sobreaprovisionamiento.

Arquitectura moderna no es solo técnica. También es financiera.

¿Por qué esta es una buena base?

Porque:

Desacopla estático de dinámico
Reduce latencia global
Aumenta seguridad
Aplica buenas prácticas reales
Te obliga a entender networking, disponibilidad y diseño

Conclusión

Entender cómo diseñar un sistema completo, pensando en rendimiento, seguridad y escalabilidad desde el inicio.

La diferencia entre saber usar servicios y saber diseñar arquitectura es lo que realmente eleva tu carrera como ingeniero.

Feliz codeo gente!

@eduuu.dev

Implementación segura de CORS y validación de peticiones en arquitecturas de microservicios

Eduardo Fuentes — Fri, 24 Oct 2025 15:17:28 +0000

1. Introducción

Cuando diseñamos una API que será consumida por diferentes clientes como aplicaciones web, móviles o microservicios internos, es esencial controlar quién puede acceder a ella y bajo qué condiciones.
Uno de los mecanismos más importantes para proteger los endpoints expuestos en la web es CORS (Cross-Origin Resource Sharing).

¿Qué es CORS?
CORS es una política de seguridad implementada por los navegadores que impide que un sitio web en un dominio (https://app.com) realice solicitudes a otro dominio (https://api.com) a menos que el servidor lo autorice explícitamente.

Esto evita ataques como el Cross-Site Request Forgery (CSRF) o el data leakage entre orígenes no relacionados.

Por qué es importante
Una configuración incorrecta de CORS puede dejar una API abierta a solicitudes desde cualquier origen, exponiendo datos sensibles.
Ejemplo:

Access-Control-Allow-Origin: *

Esta cabecera, usada sin control, permite que cualquier sitio del mundo interactúe con tu API.

Diferencia entre peticiones desde navegador y server-to-server

Tipo	¿Incluye Origin?	¿Requiere CORS?	Ejemplo
Navegador (frontend)	Sí	Sí	Petición desde React, Angular, etc.
Microservicio interno	No	No	Comunicación entre APIs internas
Cliente CLI	No	No	curl, Postman, etc.

2. El problema

Muchas configuraciones por defecto o ejemplos en internet aplican soluciones genéricas, como permitir todos los orígenes o usar comodines.
Aunque simplifican las pruebas, en producción pueden generar vulnerabilidades serias.

Riesgos comunes:

Permitir todos los orígenes (*): Ideal para desarrollo, peligroso en producción.
Validar con endsWith() o expresiones débiles: Permite subdominios falsos: evil.miapp.com.
No diferenciar entre navegadores y servicios: Se aplican políticas de CORS incluso a peticiones internas que no las requieren.
Omitir la validación de tokens: APIs que aceptan cualquier Origin pero no exigen autenticación válida.

3. Estrategia de seguridad dual

La forma más segura de abordar el problema es combinar dos niveles de validación complementarios:

Validación de origen (CORS) para peticiones que provienen de navegadores.
Validación de autorización (token o clave API) para peticiones que provienen de otros servidores o servicios internos.

En otras palabras:
Los navegadores se validan por quiénes son (su dominio).
Los servicios se validan por lo que saben (sus credenciales).

4. Lógica de validación recomendada

1. Validar el origen (CORS)

Solo permitir dominios conocidos (no comodines).
Verificar que el esquema sea HTTPS.
Evitar comparaciones simples como endsWith(), usar validaciones exactas o listas blancas.
Incluir una lista explícita de orígenes confiables: https://app.miempresa.com, https://admin.miempresa.com

2. Validar autorización

Aceptar tokens JWT o API Keys solo en canales seguros (HTTPS).
Rechazar peticiones sin credenciales válidas.
Permitir excepciones únicamente para endpoints públicos documentados.

3. Lógica de decisión (resumen)

Tipo de petición	Cabecera `Origin`	Token/API Key	Resultado	Uso típico
Navegador confiable	Válido	-	Permitir + CORS	Frontend web
Navegador no permitido	Inválido	-	Rechazar 403	Sitio externo
Microservicio interno	Null	Válido	Permitir	Comunicación interna
Petición anónima	Null	Null	Rechazar 403	Postman/curl sin token
Preflight OPTIONS	Válido	-	Permitir 200	Verificación previa de navegador

5. Conclusión

La seguridad en APIs modernas no depende solo de la autenticación, sino también del control del contexto desde donde se realizan las peticiones.
Implementar una política de CORS estricta y validación de tokens sólida garantiza que:

Solo los clientes autorizados puedan interactuar con los endpoints.
Las comunicaciones internas permanezcan seguras y verificadas.
Se evite el acceso indebido desde sitios externos o maliciosos.

En cualquier lenguaje o framework, la clave es aplicar una estrategia dual coherente y auditable, en lugar de confiar en configuraciones genéricas o atajos.

El principio de menor sorpresa y cómo el vibe coding puede romperlo

Eduardo Fuentes — Sat, 19 Jul 2025 22:56:29 +0000

El mejor código es el que no te sorprende.

Cuando hablamos de buenas prácticas en desarrollo de software, uno de los principios más importantes y a veces ignorado, es el Principio de Menor Sorpresa. Este principio establece que el comportamiento del código debería ser el que cualquier desarrollador razonable esperaría.

Es decir: tu código debería comportarse de forma predecible.

¿Qué significa esto en la práctica?
Veamos un ejemplo sencillo:

// ¿Qué hace esta función?
function getUser(id: string): any {
  return fetch(`/api/users/${id}`);
}

Si lees este código por primera vez, podrías pensar que getUser devuelve un usuario. Pero en realidad devuelve una promesa, no un objeto User.

Un enfoque más alineado con el principio de menor sorpresa sería:

async function getUser(id: string): Promise<User> {
  const response = await fetch(`/api/users/${id}`);
  return await response.json();
}

O incluso nombrar la función como fetchUser o getUserAsync, si se desea enfatizar aún más el comportamiento asíncrono.

Romper este principio genera fricción entre el desarrollador y el sistema. Cuando te topas con código que no hace lo que esperas, te obliga a perder tiempo leyendo la implementación en lugar de enfocarte en resolver el problema de negocio.

Esto se puede convertir en un efecto dominó: pérdida de tiempo, bugs difíciles de encontrar, o peor aún… errores en producción.

¿Qué tiene que ver el vibe coding?

Con el interés de herramientas de inteligencia artificial que pueden generar código de forma automática a partir de prompts o ideas generales, muchos desarrolladores están adoptando una nueva forma de programar: escribir por impulso, sin pensar demasiado en la intención o el diseño, dejando que la IA tome decisiones por ellos.

Esta forma de trabajar puede resultar productiva en el corto plazo, pero también puede romper completamente el Principio de Menor Sorpresa.

¿Por qué el código generado impulsivamente por IA puede sorprender?

Inconsistencia de estilo o paradigmas:
A veces la IA genera código funcional, otras veces imperativo, otras veces reactivo... todo en el mismo proyecto. Esto confunde a quien lee o mantiene el código después.
Decisiones mágicas que no se documentan:
El desarrollador que usa IA puede no entender del todo lo que se generó. El código funciona, pero su intención y contexto quedan ocultos.
Abstracciones que no se alinean con el dominio del problema:
Es común ver clases, funciones o estructuras que no tienen un nombre claro o una responsabilidad definida, simplemente porque la IA respondió a un prompt mal planteado.
Pérdida de convenciones del equipo o del lenguaje:
Lo que antes era una convención interna del equipo, ahora puede romperse con un simple "copiar y pegar" desde la IA.

¿Cómo respetar el Principio de Menor Sorpresa usando IA?

No se trata de no usar IA. Al contrario, es una herramienta poderosa. Pero debemos usarla con intención, con criterio y con responsabilidad:
Sé el diseñador, no solo el consumidor: guía a la IA con prompts claros y evalúa críticamente lo que produce.
Refactoriza lo generado: dale tu toque, adáptalo al estilo de tu equipo y asegúrate de que no sorprenda a quien lo lea.
Prefiere estructuras familiares: nombres de variables, funciones y clases que reflejen el dominio del problema.
Evita la magia: si algo parece funcionar "porque sí", probablemente merezca una revisión.

Conclusión

El código que sorprende es difícil de mantener, probar y escalar. Y eso es lo que queremos evitar.

Por muy avanzado que sea el código generado por inteligencia artificial, sigue siendo nuestra responsabilidad garantizar su claridad, coherencia y previsibilidad.

Así que la próxima vez que generes código con ayuda de una IA, recuerda:
El mejor código no es el más creativo… es el que menos sorprende.

Código Limpio: Fechas (TimeZone)

Eduardo Fuentes — Tue, 15 Jul 2025 02:24:54 +0000

Porque sí, las fechas son más complejas de lo que parece…
Como desarrolladores, tarde o temprano nos encontramos con el dilema de manejar fechas correctamente. Lo que comienza como un simple new Date() puede escalar a problemas de zonas horarias, inconsistencias entre frontend y backend, y bugs que aparecen en el camino.

Por eso, en este artículo te muestro cómo estructurar el manejo de fechas de forma profesional, limpia y reutilizable.

Regla de oro: encapsula las operaciones de fecha

Uno de los mejores consejos que puedo darte es que no trabajes con fechas directamente en cada parte de tu código. En lugar de eso, crea una clase o módulo que se encargue exclusivamente del manejo de fechas.

Esto te dará:

Código más limpio
Operaciones reutilizables
Menos bugs en producción
Mejor manejo de zonas horarias
Más facilidad para testear

Además, si en algún momento decides cambiar la librería que usas (Date, Luxon, Day.js, etc.), solo tienes que cambiarlo en un solo lugar.

Guardar en UTC, mostrar en zona local

MongoDB
MongoDB guarda fechas en formato UTC si usas new Date() desde Node.js.


await db.collection('users').insertOne({
  createdAt: new Date()
});

PostgreSQL
Usa el tipo de columna timestamp with time zone. Aunque el nombre suene confuso, guarda la fecha en UTC.

created_at TIMESTAMP WITH TIME ZONE DEFAULT now()

En ambos casos, el dato se guarda en UTC, y la conversión a la zona del usuario debe hacerse solo cuando se va a mostrar.

Clase TypeScript para encapsular fechas

import { DateTime } from "luxon";

export class DateHelper {
  private date: DateTime;

  constructor(input?: Date | string) {
    this.date = input
      ? DateTime.fromJSDate(new Date(input)).toUTC()
      : DateTime.utc();
  }

  static now(): DateHelper {
    return new DateHelper();
  }

  toUTC(): string {
    return this.date.toUTC().toISO();
  }

  toLocal(zone: string): string {
    return this.date.setZone(zone).toFormat("dd/MM/yyyy HH:mm");
  }

  isAfter(other: DateHelper): boolean {
    return this.date.toMillis() > other.date.toMillis();
  }

  isBefore(other: DateHelper): boolean {
    return this.date.toMillis() < other.date.toMillis();
  }

  isSameDay(other: DateHelper): boolean {
    return this.date.hasSame(other.date, 'day');
  }

  static compare(a: DateHelper, b: DateHelper): number {
    return a.date.toMillis() - b.date.toMillis();
  }

  static fromLocal(dateString: string, zone: string): DateHelper {
    return new DateHelper(DateTime.fromFormat(dateString, "dd/MM/yyyy HH:mm", { zone }).toJSDate());
  }

  toJSDate(): Date {
    return this.date.toJSDate();
  }
}

Este módulo te permitirá:

Comparar fechas
Convertir a zona local
Convertir a UTC
Crear fechas desde strings localizados
Exportarlas como Date para persistirlas

Controla los formatos

Es una buena práctica definir formatos únicos para mostrar las fechas en toda la aplicación.

export enum TimeFormats {
  HH_MM = "HH:mm",
  HH_MM_SS = "HH:mm:ss",
}

export enum DateFormats {
  DD_MM_YYYY = "dd/MM/yyyy",
  YYYY_MM_DD = "yyyy-MM-dd",
  FULL_DATE = "dddd dd MMMM yyyy",
}

Así evitas inconsistencias visuales y puedes modificar todos los formatos desde un solo lugar.

Conclusión

Encapsular tu lógica de fechas y trabajar siempre en UTC es una de las mejores inversiones que puedes hacer, te ahorarás dolores de cabeza.

🧠 Caso real: cuando .populate() no es suficiente (y lo que aprendí integrando MongoDB con Oracle)

Eduardo Fuentes — Thu, 29 May 2025 00:42:18 +0000

Hace un tiempo me tocó un desafío interesante como backend developer.

Un cliente necesitaba extender su sistema. Era una especie de migración evolutiva: querían crear un nuevo módulo clave para el negocio, pero conservando algunos datos críticos en su base de datos legacy (Oracle).

El stack
Para el nuevo módulo se decidió trabajar con MongoDB, lo cual nos forzaba a diseñar una lógica de integración para que ambas bases pudieran coexistir mientras se realizaba la transición. El problema vino cuando uno de los requerimientos fue:

"Para los datos que vengan de Oracle, queremos mantener el mismo id como identificador en Mongo."

Parece simple, ¿no? Pero aquí es donde entra Mongoose.

¿Qué es Mongoose?

Para quienes no lo conocen, Mongoose es un ODM (Object Document Mapper) para MongoDB en el ecosistema de Node.js. Sirve para estructurar tus colecciones como si fueran modelos en un ORM, con schemas, validaciones, middlewares, y sí, relaciones entre documentos.

Es justamente ahí donde aparece .populate(), una función que simula los joins del mundo SQL, permitiéndote relacionar documentos entre colecciones.

El problema real
Cuando quisimos relacionar documentos por un campo que no era el _id de Mongo, comenzaron los problemas.

Mongoose por defecto hace .populate() usando el campo _id. Pero en este caso, queríamos hacer .populate() usando un campo llamado id que venía desde Oracle y que debíamos conservar.

Intentamos cosas como:

js
Copy
Edit
ref: 'User',
localField: 'userId',
foreignField: 'id',
justOne: true

Y aunque eso nos llevó a una solución parcial usando populate virtuales, se empezó a complicar la lectura del código y la mantenibilidad.

La solución (de compromiso)
Optamos por construir los documentos en Mongo usando ambos campos:

json
Copy
Edit
{
  "_id": "valor-id-legacy",
  "id": "valor-id-legacy",
  "otrosCampos": "..."
}

Esto nos permitió mantener compatibilidad con Mongoose sin modificar demasiadas partes del sistema, y respetar el requerimiento de mantener el mismo identificador del sistema legacy.

Conclusiones

💡 Este tipo de casos son un buen ejemplo de cuando se habla de que MongoDB no está hecho para relaciones complejas. A veces es fácil subestimar estos detalles hasta que necesitas hacer cosas como .populate() con condiciones especiales.

👀 Mongoose ofrece herramientas potentes, pero también tiene sus limitaciones cuando queremos salirnos de lo estándar.

⚠️ Es importante pensar bien la estructura de los datos antes de migrar o integrar con sistemas existentes. Mongo te da flexibilidad, pero esa flexibilidad puede jugarte en contra cuando empiezas a crecer o te toca convivir con sistemas relacionales.

Solución

¿Y entonces?
En nuestro caso, mantener ambos campos (_id e id) fue un compromiso aceptable. ¿Ideal? No. ¿Pragmático? Totalmente.

🔧 Si te encuentras en una situación parecida:

Evalúa si puedes mapear los datos antes de guardarlos.

Considera los límites de .populate() con campos no convencionales.

Usa virtuales con cuidado, y documenta bien su propósito.

Y si empiezas a escribir muchos .aggregate() para solucionar estos problemas… quizá Mongo no es el lugar.

¿Te ha pasado algo similar? ¿Has tenido que hacer convivir Mongo con sistemas legacy?

Déjamelo saber en los comentarios o comparte tu experiencia. 🙌

Puede la IA reemplazar los trabajos de desarrollo? Vamos a hablar de ello!

Eduardo Fuentes — Mon, 30 Dec 2024 13:50:44 +0000

El pánico por la IA es real. Adondequiera que vayas, alguien grita: "¡La IA nos va a quitar el trabajo!". Y si trabajas en el sector tecnológico (sobre todo si eres desarrollador), probablemente lo hayas oído más veces de las que has tenido que depurar esa molesta línea de código. (No mientas: todos tenemos ese error que nos persigue).

Pero dejemos de lado el ruido por un segundo. ¿Realmente corres el riesgo de ser reemplazado por una IA? Alerta de spoiler: no, a menos que estés flojeando. Analicemos esto en detalle.

Si te preocupa que te reemplacen, tal vez deberías hacer algo al respecto

Este es el asunto: solo te reemplazan en un trabajo, en cualquier trabajo, si no eres lo suficientemente bueno en él. Piénsalo. Si estás escribiendo código de espagueti que haría que un plato de tallarines se vea organizado, sí, tal vez sea hora de subir de nivel. Con IA o sin IA, el lugar de trabajo nunca ha sido amable con la mediocridad.

En lugar de sudar la gota gorda porque la IA te quite el trabajo, ¿qué tal si haces las cosas que te hacen irreemplazable?

¿Qué puedes hacer?

Aprende nuevos lenguajes: explora ese marco del que todos hablan maravillas.
Contribuye al código abierto: es como un gimnasio para tus habilidades de codificación.
Crea proyectos secundarios: porque nada grita "contrátame" como un repositorio genial de GitHub.
ePiénsalo como un videojuego: no pierdes en la pelea con el jefe si superas el nivel. (¿Y si no lo eres? Bueno, tienes mucho trabajo por hacer, amigo mío.)

Las herramientas de IA son geniales, pero no son varitas mágicas

He trabajado con muchas herramientas de IA. Estoy usando algunas de ellas ahora mismo. Y déjame decirte que son geniales. Agilizan tu flujo de trabajo, te ayudan a solucionar problemas de sintaxis que normalmente pasarías horas buscando en Google e incluso generan código repetitivo para que no tengas que hacer las cosas aburridas. (Más sobre eso más adelante).

Pero aquí está la cuestión: son solo herramientas.

¿Recuerdas cuando los IDE comenzaron a agregar autocompletar y la gente pensó que eso reemplazaría a los desarrolladores? Sí, no sucedió. La misma historia aquí.

Entonces, ¿qué no puede hacer la IA?

Entiende el contexto de tu proyecto: no sabes por qué elegiste esa extraña lógica de caso extremo.
Establece objetivos: la IA no conoce las necesidades comerciales de tu cliente.
Piensa de manera creativa: claro, puede generar una función, pero ¿puede diseñar una arquitectura completa? En realidad, no.

Piénsalo de esta manera: un taladro eléctrico hace que construir una casa sea más fácil, pero eso no significa que de repente puedas convertirte en arquitecto o contratista sin ninguna habilidad.

La IA solo hace que las cosas aburridas sean más fáciles

Seamos honestos: a nadie le gusta escribir código repetitivo.

Es como pelar papas antes de hacer un plato gourmet. ¿Necesario? Seguro. ¿Divertido? Absolutamente no. Y ahí es donde la IA realmente brilla.

En el pasado (hace como dos años), comenzar un proyecto significaba construir todo desde cero o al menos a partir de un código repetitivo viejo y cansado que encontrabas en GitHub. Ahora, con la IA, escribes algunas indicaciones y ¡boom! Te genera una base bonita, brillante y personalizada para tu proyecto. No es perfecta, pero te ahorra tiempo y te permite concentrarte en las cosas divertidas: la resolución de problemas y la creación de funciones.

¿Qué hay que aprender?

La IA es como ese pasante que hace las partes tediosas de tu trabajo para que puedas concentrarte en las cosas interesantes.

Tú sigues siendo el que está a cargo.
Sigues siendo el cerebro creativo detrás del proyecto.
Y sigues siendo… bueno, un programador. Solo que ahora eres más rápido. (Lo siento, autónomos por horas. Parece que los contratos con ofertas fijas te están llamando).
La IA no depurará ese código de pesadilla que escribiste a las 3 a. m.
Aquí hay otra cosa que debes tener en cuenta: la IA es excelente para seguir patrones y reglas, pero ¿depurar? Eso sigue siendo cosa tuya, amigo.

La IA puede decirte qué está mal en tu código, pero ¿averiguar por qué está mal y cómo solucionarlo de una manera que no arruine todo el proyecto? Eso requiere la capacidad intelectual de un desarrollador.

El elemento humano

El código no consiste solo en escribir líneas que funcionen.

Se trata de colaborar con tu equipo.
Entender las necesidades del cliente.
Crear algo que no solo sea funcional, sino también elegante y escalable.
La IA no hace eso. Al menos, no todavía.

Lo que deberías hacer en lugar de entrar en pánico

Si aún te preocupa la IA, te damos un consejo: deja de preocuparte y empieza a aprender.

Prepárate para el futuro

Aprenda a trabajar con IA: estas herramientas no desaparecerán, así que más vale que se familiarice con ellas. Trátelas como las extensiones de sus habilidades que son.
Concéntrese en la resolución de problemas: la IA puede escribir código, pero no puede descifrar lógicas empresariales complejas ni diseñar arquitecturas escalables. Ese es su trabajo.
Manténgase actualizado: la tecnología cambia rápidamente. Si todavía está escribiendo aplicaciones jQuery en 2024, eso es culpa suya, no de la IA. Manténgase al día con las tendencias, aprenda nuevas herramientas y manténgase adaptable.
Crea cosas: proyectos paralelos, contribuciones de código abierto, trabajos independientes, lo que sea que mantenga sus habilidades en forma y su cartera en crecimiento.
Colabora: el trabajo en equipo es una parte importante de ser un desarrollador. La IA no está reemplazando su capacidad para comunicarse con su equipo o comprender la visión de un cliente.

En conclusión: relájate, no te reemplazarán (a menos que tú lo permitas)

La IA no vendrá a ocupar su trabajo.

Al menos no si eres bueno en eso. Es una herramienta, no una amenaza. Úsala a tu favor, sigue mejorando y deja de permitir que los titulares te asusten.

La única forma en que la IA te va a reemplazar es si te quedas estancado en el pasado, negándote a adaptarte o crecer.

Pero si estás ahí afuera aprendiendo, experimentando y manteniendo la curiosidad, estás bien.

Ahora, vuelve a codificar. Y tal vez deja que la IA se encargue del código estándar por ti mientras lo haces. ¡Saludos!

Servidor NodeJs + Typescript + ExpressJs

Eduardo Fuentes — Mon, 07 Oct 2024 20:07:01 +0000

Express es un framework web minimalista popular para Node.js. Permite crear aplicaciones web de manera sencilla y rápida, tiene una documentación bastante completa que puedes revisar aquí.

En este tutorial, te explico cómo puedes crear tú primer servidor Express en TypeScript.

Paso 1: Configuración del entorno de desarrollo

Asegúrate de tener Node.js y npm instalados en tú máquina. Para instalar estas tecnologías, puedes seguir los pasos de sus sitios oficiales.

NodeJs
NPM

Luego, debes dirigirte a la ubicación donde quieres guardar tú proyecto, y crear una carpeta con el nombre que prefieras. En mi caso utilizaré ts-server.

mkdir ts-server
cd ts-server

Para iniciar el proyecto node con configuraciones por defecto, debes utilizar el siguiente comando.

npm init -y

Para iniciar un repositorio git, debes utilizar el siguiente comando.

git init

Luego, debes crear un archivo .gitignore en la raíz del directorio, este archivo sirve, para ignorar ciertos directorios o archivos, que no son necesarios subir al repositorio remoto.

Al crear .gitignore, puedes entrar al siguiente link, donde para este caso, puedes sumar las siguientes restricciones.

Esto generará el contenido necesario para el .gitignore, por lo que lo debes copiar y pegar en el archivo que creaste.

A continuación, debes agregar un archivo .editorconfig en la raíz del directorio, que su objetivo, es tener un estandar en el editor que utilices, así si otros desarrolladores quieren aportar en el proyecto, estará esta configuración centralizada.

root = true

[*]
charset = utf-8
indent_style = space
indent_size = 2
insert_final_newline = true
trim_trailing_whitespace = true

[*.js]
quote_type = single

[*.md]
max_line_length = off
trim_trailing_whitespace = false

También es necesario configurar un linter, para seguir un estándar de código, por lo que debes crear un .eslintrc.json en la raíz del directorio con una configuración similar a esta.

{
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaVersion": 2018,
    "sourceType": "module"
  },
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier"
  ],
  "env": {
    "es6": true,
    "node": true,
    "jest": true
  },
  "plugins": ["@typescript-eslint"],
  "rules": {
    "no-console": "warn"
  }
}

Con esto, tienes la configuración principal de tú proyecto.

Paso 2: Instalación de dependencias

Para continuar con el proyecto, es necesario que instalemos las dependencias que necesitamos en nuestro proyecto.

Estas serían las dependencias que se necesitan en un entorno de desarrollo, esto quiere decir que no son necesarias cuando el servidor esté en producción.

@types/express --> Proporciona definiciones de tipo para el framework Express.
@typescript-eslint/eslint-plugin --> Un plugin de ESLint que contiene un conjunto de reglas específicas para TypeScript.
@typescript-eslint/parser --> Un parser que permite a ESLint entender TypeScript. Es necesario para que ESLint pueda analizar y aplicar reglas a los archivos TypeScript.
eslint --> Es una herramienta de análisis de código estático para identificar patrones problemáticos en el código JavaScript.
eslint-config-prettier --> Desactiva las reglas EsLint que son innevesarias.
eslint-plugin-prettier --> Integra Prettier con ESLint, permitiendo que Prettier formatee el código como parte del proceso de linting.
nodemon --> Es una herramienta que ayuda a desarrollar aplicaciones basadas en Node.js al reiniciar automáticamente la aplicación cuando se detectan cambios en los archivos del directorio.
prettier --> Es un formateador de código que asegura que todo el código tenga un estilo consistente.
ts-node --> Permite ejecutar archivos TypeScript directamente en Node.js sin necesidad de compilarlos previamente a JavaScript.
typescript --> Es un superconjunto de JavaScript que añade tipos estáticos opcionales

La dependencia necesaria para producción, para este caso.

express --> Framework web minimalista

Para instalar estas dependencias, ocuparemos los siguientes comandos.

npm i express
npm i @types/express @typescript-eslint/eslint-plugin @typescript-eslint/parser eslint eslint-config-prettier eslint-plugin-prettier nodemon prettier ts-node typescript -D

Paso 3: Archivos de configuración

Para crear el archivo de configuración de typescript puedes utilizar el siguiente comando.

npx tsc --init

y debe contener algo así.

{
  "compilerOptions": {
    "target": "es6",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "outDir": "./dist",
    "rootDir": "./src"
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules", "dist", "src/tests/**/*"]
}

El package.json hay que modificarlo, para que utilice nodemon y cosas por el estilo, por lo que quedaría algo como esto.

{
  "name": "curso-platzi",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "nodemonConfig": {
    "watch": [
      "src"
    ],
    "ext": "ts",
    "ignore": [
      "*.test.ts"
    ],
    "execMap": {
      "ts": "ts-node"
    }
  },
  "scripts": {
    "dev": "nodemon src/index.ts",
    "start": "node dist/index.js",
    "lint": "eslint src --ext .ts"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "@types/express": "^5.0.0",
    "@typescript-eslint/eslint-plugin": "^8.8.0",
    "@typescript-eslint/parser": "^8.8.0",
    "eslint": "^9.12.0",
    "eslint-config-prettier": "^9.1.0",
    "eslint-plugin-prettier": "^5.2.1",
    "nodemon": "^3.1.7",
    "prettier": "^3.3.3",
    "ts-node": "^10.9.2",
    "typescript": "^5.6.2"
  },
  "dependencies": {
    "express": "^4.21.0"
  }
}

Paso 4: Levantar servidor

Finalmente en el directorio src/ agregamos el archivo index.ts, donde podremos levantar el servidor que necesitamos de la siguiente manera.

import express, { NextFunction, Request, Response } from "express";
// Se define lo necesario para el servidor
const app = express();
const port = 3000;
// Se define un middleware, para que se puedan manejar peticiones y respuestas en formato json
app.use(express.json());
// Se define el endpoint raiz, para obtener un recurso
app.get("/", (req: Request, res: Response) => {
  res.send({ message: "Hello World" });
});

//Manejo de errores
app.use((err: Error, req: Request, res: Response, next: NextFunction) => {
  res.status(500).send("Algo salió mal");
});

// Se levanta el servidor y escucha en el puerto 3000
app.listen(port, () => {
  console.log(`Server is running on port ${port}`);
});

La estructura del código queda de esta forma.

Conclusión

Y eso es gente, espero que haya sido un buen punto de partida para aprender a crear servidores web con Express, TypeScript y Node.

Chau!