Base de datosAPI REST
Portafolio Profesional
Portafolio profesional desarrollado para centralizar experiencia, habilidades, proyectos, servicios y contenido técnico en una plataforma moderna y escalable.
Herman Enrique Primo Escobar
|
Backend Developer | Desarrollo de APIs seguras, automatización y soluciones backend escalables | Python • PHP • NestJs • NextJs • React • MySQL • PostgreSQL • AWS • Git • Linux | Divulgando conocimiento para todos
Villahermosa, Tabasco, México
Experiencia y Skills
Tecnología aplicada en proyectos reales.
Experiencia profesional, formación académica y habilidades técnicas conectadas con soluciones backend, APIs e infraestructura.
PrimoTec
Profesional independiente · Híbrido
Desarrollador full stack
jul 2024 - actualidad · 2 años
Villahermosa, Tabasco, México
Desde 2024 he trabajado de manera independiente desarrollando solucion...
Desarrollo Full StackInfraestructura de softwarePythonDjango
Servicios de Mantenimiento y Soporte Técnico
sep 2018 - actualidad · 7 años 10 meses
Villahermosa, Tabasco, México
Desde 2018, brindo servicios tecnológicos y soporte técnico especializ...
Soporte TécnicoInfraestructuraLinuxUbuntu Server
1/5
Skills
Backend
1/5
Backend
Python
90%Django
90%Django REST Framework
90%PHP
80%NestJS
70%Golang
60%Sobre mí
Diseño la lógica que mantiene funcionando los sistemas.
Backend, APIs, automatización e infraestructura pensada para resolver problemas reales.
Backend Developer enfocado en el desarrollo de APIs seguras, automatización de procesos y soluciones escalables. Me apasiona construir sistemas eficientes, desde la lógica del servidor y la arquitectura backend hasta la integración con bases de datos y servicios en la nube.
He participado en proyectos académicos y tecnológicos relacionados con plataformas digitales, marketplaces y soluciones orientadas a innovación y tecnología. Además, disfruto compartir contenido técnico sobre backend, bases de datos, APIs y arquitectura de software. Actualmente continúo fortaleciendo mis conocimientos y desarrollando soluciones modernas y escalables.
Cliente
API
Backend
DB
Cloud
Paso 1
Cliente
Una persona entra a tu sitio, inicia sesión o realiza una acción.
Servicios
Soluciones tecnológicas para construir, integrar y escalar.
Servicios enfocados en backend, APIs, bases de datos, infraestructura cloud y mantenimiento de aplicaciones.
Proyectos
Soluciones construidas con enfoque real.
Una selección de proyectos donde aplico backend, APIs, bases de datos, infraestructura y desarrollo full stack.
Blog
Ideas, backend y tecnología explicados con claridad.
Publicaciones técnicas sobre backend, APIs, bases de datos, seguridad, arquitectura y desarrollo de software.
Seguridad
¿Qué es el Rate Limiting y cómo protege una API?
Imagina que acabas de publicar una API. Los primeros días todo funciona perfectamente. Recibe unas cuantas peticiones por segundo. Los usuarios pueden consultar información sin problemas. Pero conforme tu aplicación crece... las solicitudes comienzan a aumentar. 10 peticiones por segundo. Luego 100. Después 1,000. Y de repente... un solo usuario, un bot o incluso un atacante empieza a enviar miles de solicitudes en cuestión de segundos. 😵 El servidor comienza a consumir toda su CPU. 😵 La memoria aumenta. 😵 Las respuestas se vuelven lentas. 😵 Los demás usuarios dejan de recibir servicio. ¿Cómo evitar que una sola persona afecte a todos los demás? La respuesta está en un mecanismo conocido como Rate Limiting . Aunque suele pasar desapercibido, es una de las primeras líneas de defensa que utilizan las APIs modernas para proteger su infraestructura. 🧠 ¿Qué es el Rate Limiting? El Rate Limiting es un mecanismo que limita la cantidad de peticiones que un usuario, una dirección IP, un dispositivo o una aplicación puede realizar durante un periodo determinado. Su funcionamiento es muy sencillo. La API establece una regla. Por ejemplo: 👉 100 peticiones por minuto. Mientras el cliente permanezca dentro de ese límite... la API responderá normalmente. Pero si intenta superar esa cantidad... el servidor comenzará a rechazar temporalmente las solicitudes. De esta forma evita que un solo cliente consuma todos los recursos disponibles. 🌍 ¿Por qué existe? Internet está lleno de aplicaciones públicas. Muchas de ellas reciben miles o incluso millones de peticiones todos los días. Sin ningún tipo de control podrían ocurrir situaciones como: 🤖 Bots realizando consultas masivas. 🔓 Ataques de fuerza bruta contra formularios de inicio de sesión. 📈 Aplicaciones mal programadas enviando miles de peticiones por error. 💥 Usuarios consumiendo recursos de forma excesiva. El resultado sería el mismo. El servidor tendría que dedicar gran parte de su capacidad a atender unas pocas solicitudes abusivas. Y los usuarios legítimos terminarían siendo los más afectados. El Rate Limiting existe precisamente para evitar ese escenario. ⚙️ ¿Cómo funciona? Imaginemos que una API establece la siguiente política. 100 solicitudes por minuto. El proceso podría verse así. 1️⃣ El cliente realiza una petición. 2️⃣ El servidor identifica quién la envió. 3️⃣ Incrementa un contador. 4️⃣ Verifica si el límite fue alcanzado. Si todavía quedan solicitudes disponibles: ✅ La petición continúa normalmente. Pero cuando el contador supera el límite establecido: ❌ La API rechaza temporalmente las nuevas solicitudes. Después de que transcurre el tiempo definido... el contador vuelve a comenzar desde cero. Y el cliente puede seguir utilizando el servicio. 🚀 ¿Qué responde la API? Cuando un cliente supera el límite permitido, normalmente recibe el código HTTP: 429 Too Many Requests Este código indica que el problema no está en la API. El problema es que el cliente ha realizado demasiadas solicitudes en un periodo muy corto. En muchos casos la respuesta también incluye encabezados como: Retry-After: 60 Indicando cuántos segundos debe esperar antes de volver a intentarlo. 💡 Un ejemplo cotidiano Imagina un restaurante. Solo hay diez mesas disponibles. Si cien personas intentan entrar al mismo tiempo... el restaurante no puede atenderlas a todas. Lo más razonable sería formar una fila y permitir el acceso poco a poco. Las APIs hacen algo muy parecido. No bloquean a los usuarios porque sí. Simplemente controlan el ritmo con el que reciben solicitudes para mantener el servicio estable. 🔥 ¿Por qué es tan importante? El Rate Limiting aporta muchos beneficios. Entre ellos: ✅ Evita abusos. ✅ Protege la infraestructura. ✅ Reduce la posibilidad de ataques automatizados. ✅ Distribuye mejor los recursos. ✅ Garantiza una experiencia más estable para todos los usuarios. Sin este mecanismo, una API pública sería mucho más vulnerable. 🛡️ Rate Limiting y seguridad Muchas personas piensan que el Rate Limiting únicamente sirve para mejorar el rendimiento. En realidad también es una herramienta muy importante de seguridad. Por ejemplo. Supongamos que un atacante intenta descubrir la contraseña de un usuario. Sin límites podría realizar: 1,000. 10,000. O incluso millones de intentos. Con Rate Limiting... después de unos pocos intentos la API comenzará a bloquear temporalmente nuevas solicitudes. Esto hace mucho más difícil ejecutar ataques de fuerza bruta. 🌐 ¿Cómo sabe la API a quién limitar? Existen diferentes estrategias. Las más utilizadas son: 🌍 Dirección IP. 👤 Usuario autenticado. 🔑 API Key. 📱 Identificador del dispositivo. 🍪 Sesión. Dependiendo del tipo de aplicación puede utilizarse una sola estrategia o combinar varias. Por ejemplo. Una API pública podría limitar por dirección IP. Mientras que una API privada podría hacerlo utilizando el usuario autenticado. ⚡ Algoritmos utilizados Detrás del Rate Limiting existen distintos algoritmos. Los más conocidos son: 🪣 Token Bucket El sistema dispone de una cantidad limitada de "tokens". Cada petición consume uno. Cuando se agotan... las nuevas solicitudes deben esperar. 🪣 Leaky Bucket Las peticiones entran en una especie de cubeta. Van saliendo poco a poco a una velocidad constante. Si llegan demasiadas... las sobrantes son rechazadas. ⏱️ Fixed Window Cuenta cuántas solicitudes se realizaron durante un intervalo fijo. Por ejemplo: 100 peticiones entre las 10:00 y las 10:01. Al comenzar el siguiente minuto... el contador vuelve a cero. 🔄 Sliding Window Es una versión más precisa. En lugar de trabajar con intervalos fijos... analiza continuamente el tiempo transcurrido. Esto evita algunos problemas presentes en el método anterior. 🌐 ¿Dónde suele implementarse? Una ventaja del Rate Limiting es que no necesariamente debe ejecutarse dentro del backend. Muchas veces se implementa antes de que la petición llegue a la aplicación. Por ejemplo mediante: 🟢 Nginx. ☁️ Cloudflare. 🌐 API Gateway. 🛡️ Kong. 🚀 Traefik. ⚡ Middlewares de Express. 🐍 Django. ⚡ Laravel. De esta forma muchas solicitudes abusivas se bloquean incluso antes de consumir recursos del servidor de aplicaciones. ⚠️ Un error muy común Algunos desarrolladores piensan que basta con aumentar la capacidad del servidor. Más CPU. Más memoria. Más servidores. Pero si una API permite solicitudes ilimitadas... el problema tarde o temprano volverá a aparecer. La solución no consiste únicamente en tener más recursos. También consiste en administrar inteligentemente cómo se utilizan. Y ahí es donde el Rate Limiting juega un papel fundamental. 🛠️ Buenas prácticas Cuando implementes Rate Limiting es recomendable: ✅ Definir límites razonables según el tipo de endpoint. ✅ Utilizar diferentes límites para usuarios autenticados y anónimos. ✅ Informar claramente cuándo un cliente superó el límite. ✅ Registrar intentos excesivos. ✅ Combinarlo con otras medidas de seguridad como CAPTCHA o autenticación multifactor. Así es posible proteger la API sin afectar innecesariamente la experiencia de los usuarios legítimos. 🌍 La realidad Cada vez que utilizas una API pública... ya sea de redes sociales, servicios bancarios, plataformas de mapas o comercio electrónico... es muy probable que exista un sistema contando silenciosamente cuántas solicitudes realizas. No porque quiera impedirte utilizar el servicio. Sino porque necesita garantizar que millones de personas puedan acceder a él de forma justa y segura. Gracias al Rate Limiting, una sola persona no puede monopolizar los recursos de toda la infraestructura. 🚀 Conclusión El Rate Limiting es un mecanismo que controla cuántas solicitudes puede realizar un cliente durante un periodo determinado. Su objetivo no es únicamente mejorar el rendimiento de una API. También protege frente a abusos, ataques automatizados y consumo excesivo de recursos. Implementarlo correctamente ayuda a construir servicios más estables, seguros y preparados para crecer. Porque una buena API no solo responde rápido. También sabe cuándo debe poner límites para seguir funcionando correctamente para todos. 💬 ¿Has implementado Rate Limiting en tus APIs? ¿Qué estrategia utilizas normalmente: por IP, por usuario autenticado o mediante API Keys? 👀 🔥 El backend no se ve, pero sin él, nada funciona. #Backend #RateLimiting #Seguridad #APIs #Ciberseguridad #SoftwareEngineering #Programación #Nginx #Cloudflare #DesarrolloBackend
12 jul 2026
Leer publicación
Seguridad
¿Cómo funciona un token JWT por dentro?
Cuando inicias sesión en una aplicación... es normal que escribas tu usuario y contraseña una sola vez. Después puedes navegar entre distintas pantallas, consultar información o realizar operaciones sin volver a introducir tus credenciales en cada petición. Pero entonces surge una pregunta muy interesante. 👉 ¿Cómo sabe el servidor que sigues siendo tú si HTTP no recuerda nada entre una petición y otra? La respuesta, en muchas aplicaciones modernas, está en un JWT . Aunque para muchos desarrolladores es simplemente una cadena larga de caracteres, detrás de ella existe un mecanismo cuidadosamente diseñado para transportar información de forma segura entre el cliente y el servidor. Comprender cómo funciona realmente un JWT es fundamental para desarrollar APIs seguras y entender muchos de los sistemas de autenticación actuales. 🧠 ¿Qué es un JWT? JWT significa JSON Web Token . Es un estándar abierto (RFC 7519) utilizado para transmitir información entre dos partes de forma compacta y verificable. Su principal objetivo es transportar información relacionada con un usuario después de que este ha sido autenticado. Es importante aclarar algo que suele generar confusión. Un JWT no autentica al usuario . La autenticación ocurre antes. Por ejemplo: ✅ El usuario escribe su correo y contraseña. ✅ El servidor verifica que las credenciales sean correctas. Solo después de esa verificación se genera un JWT. A partir de ese momento, el token sirve para demostrar la identidad del usuario en las siguientes peticiones. 🌍 ¿Por qué existe? Recordemos que HTTP es un protocolo sin estado ( stateless ). Eso significa que cada petición es completamente independiente. Cuando un navegador solicita información, el servidor no recuerda automáticamente quién hizo la petición anterior. Sin algún mecanismo adicional, el usuario tendría que iniciar sesión una y otra vez. JWT resuelve ese problema. El servidor entrega un token al cliente. Y posteriormente el cliente envía ese mismo token en cada solicitud. Así el servidor puede verificar rápidamente quién realiza la petición. ⚙️ ¿Cómo está compuesto? Un JWT está formado por tres partes. Header.Payload.Signature Cada sección está separada por un punto. Aunque visualmente parece una sola cadena de texto... internamente cada parte tiene una función muy específica. 🏷️ 1. Header El Header contiene información sobre el propio token. Normalmente incluye: ✅ El algoritmo utilizado para generar la firma. ✅ El tipo de token. Por ejemplo: { "alg": "HS256", "typ": "JWT" } El servidor utiliza esta información para saber cómo verificar posteriormente el token. 📄 2. Payload El Payload contiene la información que viajará dentro del token. Aquí suelen encontrarse datos como: 👤 ID del usuario. 📧 Correo electrónico. 👥 Roles. 🛡️ Permisos. ⏳ Fecha de expiración. 🏢 Organización. 🔑 Identificador único del token. Por ejemplo: { "user_id": 15, "email": "herman@email.com", "role": "admin" } Aquí aparece uno de los errores más comunes. Muchas personas creen que esta información está protegida porque el token "se ve raro". Pero no es así. ⚠️ El Payload NO está cifrado El Payload simplemente está codificado en Base64URL . Eso significa que cualquier persona que posea el token puede decodificarlo fácilmente. Por esa razón: ❌ Nunca debes almacenar contraseñas. ❌ Nunca debes guardar números de tarjetas. ❌ Nunca debes incluir información confidencial. El Payload únicamente debe contener información que pueda ser leída sin comprometer la seguridad del sistema. 🛡️ 3. Signature La tercera parte es probablemente la más importante. La firma . Es la encargada de garantizar que nadie haya modificado el token. Para generarla el servidor utiliza: 🔑 Una clave secreta. O bien: 🔐 Una clave privada, dependiendo del algoritmo utilizado. La firma se calcula utilizando: El Header. El Payload. La clave secreta. Cuando el servidor recibe nuevamente el JWT... realiza exactamente el mismo cálculo. Si ambas firmas coinciden: ✅ El token es auténtico. Si alguien modificó un solo carácter... aunque sea el nombre del usuario o la fecha de expiración... la firma cambia completamente. Y el servidor rechaza el token inmediatamente. 💡 ¿Cómo funciona todo el proceso? El flujo completo suele verse así. 1️⃣ El usuario inicia sesión. 2️⃣ El backend verifica las credenciales. 3️⃣ Si son correctas, genera un JWT firmado. 4️⃣ Devuelve el token al cliente. 5️⃣ El cliente lo almacena. 6️⃣ En cada petición posterior lo envía al servidor. 7️⃣ El servidor verifica la firma. 8️⃣ Si todo es correcto... permite acceder al recurso solicitado. Todo este proceso suele completarse en apenas unos milisegundos. 🌐 ¿Dónde se envía el JWT? Lo más habitual es utilizar el encabezado HTTP Authorization . Por ejemplo: Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... El prefijo Bearer indica que el cliente está presentando un token de acceso. El servidor extrae el JWT, verifica la firma y decide si la petición puede continuar. 🚀 ¿Por qué se utiliza tanto? JWT ofrece varias ventajas importantes. Entre ellas: ✅ APIs completamente Stateless. ✅ Menor necesidad de consultar la base de datos. ✅ Mejor escalabilidad. ✅ Fácil integración entre diferentes servicios. ✅ Compatibilidad con aplicaciones móviles. ✅ Muy útil en arquitecturas de microservicios. Por eso se ha convertido en uno de los mecanismos más utilizados para proteger APIs REST. 🔥 Stateless: una de sus mayores ventajas Con sesiones tradicionales... el servidor debe recordar a cada usuario. Eso normalmente implica almacenar información en memoria o en una base de datos. Con JWT ocurre algo diferente. Toda la información necesaria viaja dentro del propio token. El servidor únicamente necesita verificar la firma. Esto simplifica enormemente el trabajo cuando existen múltiples servidores atendiendo miles de peticiones simultáneamente. 🌍 JWT en microservicios En arquitecturas de microservicios esto resulta especialmente útil. Supongamos una plataforma formada por varios servicios. 👤 Servicio de usuarios. 🛒 Servicio de pedidos. 💳 Servicio de pagos. 📦 Servicio de inventario. Todos ellos pueden verificar el mismo JWT. No necesitan preguntar constantemente al servidor de autenticación quién es el usuario. Esto reduce el número de consultas y mejora el rendimiento general del sistema. ⚠️ Errores muy comunes Existen varias ideas equivocadas alrededor de JWT. Una de las más frecuentes es pensar que el token está cifrado. No lo está. Está firmado. Otra es almacenar demasiada información dentro del Payload. Mientras más datos contenga el token... más grande será cada petición HTTP. También es un error generar tokens sin fecha de expiración. Si un atacante obtiene un JWT válido que nunca expira... podría utilizarlo indefinidamente. 🛠️ Buenas prácticas Cuando implementes autenticación con JWT es recomendable: ✅ Utilizar HTTPS. ✅ Definir tiempos de expiración razonables. ✅ Firmar siempre los tokens con algoritmos seguros. ✅ No almacenar información sensible en el Payload. ✅ Revocar tokens comprometidos cuando sea necesario. ✅ Utilizar Refresh Tokens para sesiones prolongadas. Estas prácticas ayudan a reducir muchos riesgos de seguridad. 🌍 JWT está en todas partes Aunque muchas veces no lo notes, JWT se utiliza en una enorme cantidad de aplicaciones modernas. 📱 Aplicaciones móviles. 🌐 APIs REST. ☁️ Microservicios. 🔗 Integraciones entre plataformas. 🛒 Comercio electrónico. 🏦 Sistemas bancarios. Cada vez que una aplicación recuerda quién eres sin pedirte nuevamente la contraseña... es muy probable que exista un JWT trabajando detrás de escena. 🧩 La realidad Un JWT puede parecer únicamente una cadena larga de caracteres. Pero en realidad contiene toda la información necesaria para que un servidor identifique al usuario, conozca sus permisos y verifique que nadie ha manipulado esos datos durante el viaje. Su verdadero valor no consiste en ocultar información. Consiste en garantizar que esa información no pueda modificarse sin ser detectada. Por eso se ha convertido en una pieza fundamental de la seguridad en las APIs modernas. 🚀 Conclusión JWT es un mecanismo seguro y eficiente para transportar información relacionada con un usuario después de que ha sido autenticado. Gracias a su estructura compuesta por Header, Payload y Signature, permite que el servidor verifique rápidamente la identidad del cliente sin necesidad de consultar constantemente la base de datos. Sin embargo, es importante recordar que un JWT no cifra la información. Su función principal es garantizar la integridad de los datos mediante una firma criptográfica. Comprender esta diferencia ayuda a implementar sistemas de autenticación mucho más seguros y evitar errores muy comunes durante el desarrollo. Porque al final... un JWT no existe para ocultar la información. Existe para demostrar que esa información sigue siendo exactamente la misma que el servidor generó. 💬 ¿En tus proyectos prefieres implementar autenticación con JWT , sesiones tradicionales o una combinación de ambas tecnologías? 👀 🔥 El backend no se ve, pero sin él, nada funciona. #JWT #Backend #Seguridad #APIs #JSONWebToken #Autenticación #SoftwareEngineering #Programación #DesarrolloBackend #Ciberseguridad
11 jul 2026
Leer publicación
Arquitectura de Software
¿Qué es un middleware y qué hace antes de llegar a tu controlador?
Cuando un usuario hace una petición a una API... es fácil imaginar que la solicitud llega directamente al controlador que contiene la lógica del negocio. Pero en una aplicación moderna eso casi nunca ocurre. Antes de que el controlador reciba la petición... esta suele atravesar una serie de componentes encargados de verificar que todo esté en orden. ¿El usuario está autenticado? ¿Tiene permisos para acceder? ¿La petición cumple con las reglas esperadas? ¿Debe registrarse en los logs? ¿Se superó el límite de peticiones permitido? Todas estas comprobaciones suelen realizarse antes de ejecutar una sola línea de código del controlador. A esos componentes se les conoce como middlewares . Y aunque normalmente trabajan de forma silenciosa, son una de las piezas más importantes en la arquitectura de cualquier aplicación backend. 🧠 ¿Qué es un middleware? Un middleware es un componente que se ejecuta entre la petición del cliente y el controlador . Su función es interceptar cada solicitud para realizar alguna tarea antes de que llegue a la lógica principal de la aplicación. Podemos imaginarlo como un filtro. Cada petición que entra al sistema debe atravesar una serie de filtros antes de obtener acceso al controlador. Si todo está correcto... la petición continúa su camino. Si alguno de los filtros detecta un problema... la petición puede detenerse inmediatamente. En otras palabras... 👉 un middleware decide si una solicitud puede seguir avanzando o no. 🌍 ¿Por qué existen los middlewares? Imagina una aplicación con cien endpoints. Si cada controlador tuviera que verificar: 🔐 La autenticación. 👥 Los permisos. 📋 Los registros de auditoría. 🌐 La configuración de CORS. 🚦 El límite de peticiones. Estarías escribiendo exactamente el mismo código una y otra vez. Además de ser repetitivo... sería muy difícil de mantener. Los middlewares existen para evitar esa duplicación. Permiten centralizar tareas comunes y reutilizarlas en toda la aplicación. Así, cada controlador puede concentrarse únicamente en resolver el problema de negocio para el que fue creado. ⚙️ ¿Cómo funciona? De forma simplificada, el flujo de una petición suele verse así: 👤 Usuario ⬇️ 🌐 Petición HTTP ⬇️ 🛡️ Middleware ⬇️ 🛡️ Middleware ⬇️ 🛡️ Middleware ⬇️ 🎯 Controlador ⬇️ 🗄️ Base de datos ⬇️ 📤 Respuesta Cada middleware recibe la petición. Puede modificarla. Validarla. Registrar información. O incluso detenerla completamente. Cuando termina su trabajo... la envía al siguiente middleware. Y solo después de atravesar toda esa cadena llega al controlador. 💡 Un ejemplo real Supongamos que un usuario intenta acceder al siguiente endpoint: GET /api/usuarios Antes de llegar al controlador pueden ejecutarse varias verificaciones. 1️⃣ Comprobar que existe un token de autenticación. 2️⃣ Validar que el JWT sea correcto. 3️⃣ Revisar que el usuario no haya expirado su sesión. 4️⃣ Confirmar que posee permisos para consultar usuarios. 5️⃣ Registrar la petición en los logs. 6️⃣ Medir cuánto tarda la solicitud. Si todo sale correctamente... el controlador finalmente obtiene la petición y consulta la base de datos. Pero si cualquiera de esos pasos falla... la petición termina ahí mismo. El controlador ni siquiera llega a ejecutarse. 🚀 ¿Qué tareas puede realizar un middleware? Los middlewares son extremadamente versátiles. Entre las tareas más comunes encontramos: 🔐 Verificar autenticación. 👥 Validar permisos y roles. 📋 Registrar logs. 📊 Medir tiempos de respuesta. 🌍 Configurar CORS. 🛡️ Proteger contra ataques. 🚦 Aplicar Rate Limiting. 📄 Validar encabezados HTTP. 🔄 Agregar información a la petición. 📝 Registrar auditorías. Cada middleware suele tener una única responsabilidad. Y precisamente esa simplicidad hace que el código sea mucho más limpio. 🔒 Middleware de autenticación Uno de los más utilizados. Su trabajo consiste en responder una pregunta muy sencilla. 👉 ¿Quién eres? Verifica credenciales como: 🔑 JWT. 🍪 Cookies de sesión. 🔐 Tokens OAuth. Si la identidad del usuario no puede comprobarse... la petición termina inmediatamente. 👥 Middleware de autorización Una vez autenticado el usuario... todavía queda otra pregunta. 👉 ¿Qué puede hacer? Este middleware revisa: Roles. Permisos. Políticas de acceso. Si un usuario intenta acceder a una zona restringida... el middleware devuelve un error sin permitir que el controlador se ejecute. 📋 Middleware de logs Otro middleware muy habitual. Cada petición queda registrada. Por ejemplo: 📅 Fecha. 🌐 Dirección IP. 👤 Usuario. 📍 Endpoint solicitado. ⏱️ Tiempo de respuesta. Estos registros resultan muy útiles para monitoreo, auditorías y solución de problemas. 🚦 Middleware de Rate Limiting Imagina que alguien intenta enviar diez mil peticiones por segundo. Sin protección... podría saturar el servidor. Un middleware de Rate Limiting permite establecer límites como: 100 solicitudes por minuto. 500 solicitudes por hora. Cuando un cliente supera ese límite... la petición se bloquea automáticamente. Esto ayuda a proteger la infraestructura frente a abusos y ataques. 🌐 Middleware de CORS Cuando un frontend intenta consumir una API ubicada en otro dominio... el navegador aplica las reglas de CORS. Muchos frameworks utilizan un middleware para indicar: Qué dominios están permitidos. Qué métodos HTTP pueden utilizarse. Qué encabezados son válidos. Todo esto ocurre antes de ejecutar cualquier controlador. 🔥 ¿Se pueden utilizar varios middlewares? Sí. Y de hecho es lo más común. Una sola petición puede atravesar cinco, diez o incluso más middlewares antes de llegar a su destino. Por ejemplo: 🛡️ CORS. ⬇️ 📋 Logs. ⬇️ 🔐 Autenticación. ⬇️ 👥 Autorización. ⬇️ 🚦 Rate Limiting. ⬇️ 🎯 Controlador. Cada uno realiza una tarea muy específica. Y después entrega la petición al siguiente. 🌐 Frameworks que utilizan middlewares Prácticamente todos los frameworks modernos implementan este patrón. Entre ellos encontramos: 🐍 Django. 🟢 Express.js. ⚡ Laravel. ☕ Spring Boot. 🦫 ASP.NET Core. ⚡ FastAPI. 🟩 NestJS. Aunque cada framework utiliza una implementación distinta... la idea siempre es la misma. Interceptar la petición antes de que llegue al controlador. ⚠️ Un error muy común Cuando alguien comienza a desarrollar APIs suele escribir toda la lógica directamente dentro del controlador. Por ejemplo: Validar autenticación. Revisar permisos. Registrar logs. Controlar errores. Validar encabezados. El resultado suele ser un controlador enorme y difícil de mantener. Los middlewares existen precisamente para evitar ese problema. Cada componente se ocupa únicamente de una responsabilidad. Y el controlador queda mucho más limpio. 🛠️ Buenas prácticas Cuando trabajes con middlewares es recomendable: ✅ Que cada middleware tenga una única responsabilidad. ✅ Evitar lógica de negocio dentro de ellos. ✅ Mantenerlos reutilizables. ✅ Ejecutar primero los más importantes, como autenticación. ✅ Registrar únicamente la información necesaria. Siguiendo estas prácticas es mucho más sencillo mantener una aplicación conforme crece. 🌍 La realidad Cada vez que consumes una API... es muy probable que tu petición atraviese varios middlewares antes de que el backend procese realmente tu solicitud. Aunque nunca los veas... ellos verifican autenticación. Controlan permisos. Registran actividad. Aplican políticas de seguridad. Protegen contra abusos. Y preparan toda la información para que el controlador solo tenga que resolver el problema de negocio. Son uno de esos componentes que casi nadie nota... pero sin ellos muchas aplicaciones modernas serían mucho más difíciles de desarrollar y mantener. 🚀 Conclusión Los middlewares son componentes que interceptan las peticiones antes de que lleguen al controlador para ejecutar tareas comunes como autenticación, autorización, validaciones, registros o configuración de seguridad. Gracias a ellos es posible reutilizar código, mantener los controladores limpios y organizar mejor la arquitectura de una aplicación. En lugar de repetir las mismas verificaciones en cada endpoint, los middlewares permiten centralizar responsabilidades y construir sistemas más seguros, mantenibles y escalables. Porque un buen controlador debería concentrarse únicamente en resolver la lógica del negocio. Todo lo demás... puede quedar en manos de un buen middleware. 💬 ¿Cuál es el middleware que consideras indispensable en cualquier API moderna: autenticación, autorización, logs, validaciones o rate limiting? 👀 🔥 El backend no se ve, pero sin él, nada funciona. #Backend #Middleware #Arquitectura #APIs #Programación #SoftwareEngineering #Django #ExpressJS #Laravel #DesarrolloBackend
10 jul 2026
Leer publicación
Base de datos
¿Qué ocurre cuando dos usuarios modifican el mismo registro al mismo tiempo?
Imagina que dos empleados de una empresa necesitan actualizar la información del mismo cliente. Ambos abren el formulario prácticamente al mismo tiempo. Los dos ven exactamente la misma información. El primero cambia el número de teléfono. El segundo modifica la dirección. Ninguno sabe que el otro también está editando ese registro. Ambos presionan Guardar con apenas unos segundos de diferencia. Entonces surge una pregunta muy importante: 👉 ¿Cuál de los dos cambios debería conservar la base de datos? Si el sistema no está preparado para manejar este tipo de situaciones, uno de los cambios puede sobrescribir al otro. Y eso significa pérdida de información. Este problema recibe el nombre de concurrencia , y es uno de los mayores desafíos cuando varias personas trabajan simultáneamente sobre los mismos datos. 🧠 ¿Qué es la concurrencia? La concurrencia es la capacidad de un sistema para permitir que varios usuarios o procesos accedan a la misma información al mismo tiempo. En una aplicación moderna esto ocurre constantemente. Mientras una persona actualiza un pedido... otra consulta un inventario. Mientras alguien modifica un perfil... otro usuario realiza una compra. Y todo sucede de manera simultánea. El objetivo de una base de datos no es impedir que esto ocurra. Su objetivo es garantizar que, aunque cientos o miles de personas trabajen al mismo tiempo, la información permanezca correcta y consistente. 🌍 ¿Por qué es un problema? Mientras una aplicación tiene pocos usuarios, los conflictos son poco frecuentes. Pero conforme el sistema crece, también aumenta la probabilidad de que dos personas intenten modificar exactamente el mismo dato. Piensa en plataformas como: 🛒 Amazon. 🏦 Bancos. ✈️ Aerolíneas. 🎟️ Venta de boletos. 🏥 Hospitales. Miles de usuarios realizan operaciones al mismo tiempo. Si la base de datos no controlara correctamente esas operaciones, aparecerían errores constantemente. ⚙️ ¿Qué puede salir mal? Veamos un ejemplo. Supongamos que un cliente tiene registrado este número telefónico: 📞 9931234567 Dos empleados abren su expediente. El primero actualiza el teléfono. El segundo modifica la dirección. Si ambos guardan sin ningún control, podría ocurrir lo siguiente: ✅ El teléfono se actualiza. ❌ Pero cuando el segundo usuario guarda, sobrescribe el registro completo utilizando la información antigua que tenía cargada. Resultado: 👉 El cambio del teléfono desaparece. Este problema recibe un nombre muy conocido en bases de datos: ❌ Actualización perdida (Lost Update) Es uno de los errores de concurrencia más comunes. Y también uno de los más difíciles de detectar cuando una aplicación comienza a crecer. 💡 Otro ejemplo cotidiano Imagina un documento compartido. Dos personas lo editan al mismo tiempo. La primera cambia el título. La segunda modifica un párrafo. Si ambos guardan sin coordinación... uno de los trabajos podría perderse. Las bases de datos enfrentan exactamente el mismo desafío. 🚀 ¿Cómo lo solucionan las bases de datos? Los motores de bases de datos llevan décadas resolviendo este problema. Por eso incorporan diferentes mecanismos para controlar el acceso concurrente a la información. Los más utilizados son los siguientes. 🔒 Bloqueos (Locks) Cuando un usuario comienza a modificar un registro, la base de datos puede bloquear temporalmente ese dato. Mientras el bloqueo permanece activo: ❌ Otros procesos no pueden modificarlo. Deben esperar. Una vez que la operación termina: ✅ El bloqueo se libera. Y el siguiente usuario puede continuar. Este mecanismo evita que dos personas escriban sobre el mismo registro exactamente al mismo tiempo. 🔄 Control optimista (Optimistic Locking) No siempre es buena idea bloquear registros. En aplicaciones con miles de usuarios eso podría generar demasiadas esperas. Por eso existe otra estrategia. Cada registro posee un número de versión. Por ejemplo: Versión 12. Cuando un usuario intenta guardar cambios, la aplicación verifica que el registro siga estando en esa versión. Si alguien ya modificó el dato y ahora la versión es la 13... el sistema detecta el conflicto. En lugar de sobrescribir la información: ⚠️ informa al usuario que el registro cambió y debe actualizarlo antes de volver a guardar. Así se evita perder cambios. 🛒 Un ejemplo real Supongamos una tienda en línea. Solo queda una laptop disponible. Dos clientes hacen clic en Comprar exactamente al mismo tiempo. Sin control de concurrencia: ❌ Ambos podrían completar la compra. La tienda vendería un producto que realmente no existe. Con un buen manejo de concurrencia: ✅ El primer cliente obtiene la laptop. ❌ El segundo recibe un mensaje indicando que el producto ya no está disponible. Todo esto ocurre en apenas unos milisegundos. ✈️ Otro ejemplo muy conocido Cuando reservas un asiento en un avión ocurre exactamente el mismo problema. Solo existe un asiento 18A. Miles de personas podrían intentar reservarlo simultáneamente. La base de datos debe garantizar que únicamente una persona pueda obtenerlo. Si no existiera control de concurrencia... dos pasajeros podrían comprar el mismo asiento. 🌐 Herramientas utilizadas Los motores de bases de datos utilizan distintos mecanismos para mantener la consistencia. Entre los más importantes encontramos: 🗄️ Transacciones. 🔒 Locks. 📊 Niveles de aislamiento. 🔢 Versionado de registros. ⏳ Control de concurrencia optimista. ⛔ Control de concurrencia pesimista. Todos trabajan conjuntamente para garantizar que los datos permanezcan correctos incluso cuando miles de usuarios interactúan con el sistema al mismo tiempo. 🔥 ¿Qué son los niveles de aislamiento? Cuando varias transacciones se ejecutan simultáneamente, la base de datos puede decidir cuánto deben "ver" unas de otras. A esto se le llama nivel de aislamiento . Los niveles más comunes son: 🔹 Read Uncommitted. 🔹 Read Committed. 🔹 Repeatable Read. 🔹 Serializable. Mientras mayor sea el nivel de aislamiento: ✅ Mayor consistencia. Pero también puede disminuir el rendimiento debido a un mayor número de bloqueos. Elegir el nivel adecuado depende del tipo de aplicación. ⚠️ Un error frecuente Muchos desarrolladores prueban sus aplicaciones trabajando solos. Todo funciona perfectamente. Pero cuando la aplicación llega a producción... decenas o cientos de usuarios comienzan a utilizarla simultáneamente. Es entonces cuando aparecen problemas como: ❌ Actualizaciones perdidas. ❌ Datos duplicados. ❌ Inventarios negativos. ❌ Compras repetidas. ❌ Inconsistencias entre tablas. Por eso la concurrencia debe considerarse desde las primeras etapas del diseño de una aplicación. 🛠️ Buenas prácticas Para reducir problemas de concurrencia es recomendable: ✅ Utilizar transacciones correctamente. ✅ Mantener las transacciones lo más cortas posible. ✅ Elegir un nivel de aislamiento adecuado. ✅ Implementar versionado cuando varios usuarios editan información. ✅ Evitar mantener registros bloqueados durante demasiado tiempo. ✅ Diseñar pensando en múltiples usuarios desde el inicio. Estas prácticas ayudan a construir aplicaciones mucho más robustas y confiables. 🌍 La concurrencia está en todas partes Aunque muchas veces no lo notes, la concurrencia forma parte de casi todas las aplicaciones modernas. Cada vez que: 🛒 Compras el último producto disponible. ✈️ Reservas un asiento. 🏨 Apartas una habitación. 🏦 Realizas una transferencia. 📄 Editas un documento colaborativo. 💬 Envías un mensaje. La base de datos está tomando decisiones para evitar conflictos entre cientos o miles de usuarios. Todo ocurre de forma automática. Y normalmente en cuestión de milisegundos. 🧩 La realidad La concurrencia no consiste en impedir que varias personas trabajen al mismo tiempo. Al contrario. Su objetivo es permitir que todos trabajen simultáneamente sin poner en riesgo la información. Gracias a mecanismos como los bloqueos, las transacciones, el versionado y los niveles de aislamiento, las bases de datos modernas pueden garantizar que millones de operaciones ocurran de forma segura todos los días. Y aunque rara vez pensamos en ello... cada compra, reserva o transferencia que realizamos depende de que estos mecanismos funcionen correctamente. 🚀 Conclusión Cuando dos o más usuarios modifican el mismo registro al mismo tiempo, la base de datos debe decidir cómo manejar ese conflicto para evitar inconsistencias. Sin un control adecuado podrían perderse datos, duplicarse operaciones o generarse errores muy difíciles de detectar. Por eso los motores de bases de datos incorporan herramientas como transacciones, bloqueos, control de versiones y niveles de aislamiento, que permiten mantener la integridad de la información incluso bajo una gran cantidad de usuarios concurrentes. Comprender estos conceptos es fundamental para desarrollar aplicaciones robustas, escalables y seguras. Porque una aplicación profesional no solo debe funcionar cuando la utiliza una persona. Debe seguir funcionando correctamente cuando la utilizan miles al mismo tiempo. 💬 ¿Alguna vez te encontraste con un problema de Lost Update o algún conflicto de concurrencia en uno de tus proyectos? ¿Cómo lo resolviste? 👀 🔥 El backend no se ve, pero sin él, nada funciona. #SQL #Concurrencia #BaseDeDatos #Backend #Transacciones #DatabaseDesign #SoftwareEngineering #PostgreSQL #MySQL #Programación
09 jul 2026
Leer publicación
Base de datos
¿Cómo funciona una transacción en bases de datos?
Imagina que realizas una transferencia bancaria desde tu aplicación favorita. Tu cuenta tiene $2,000. Decides enviar $500 a otra persona. Presionas el botón "Transferir" . La aplicación comienza a procesar la operación. Primero descuenta los $500 de tu cuenta. Pero justo en ese momento... 💥 El servidor se apaga. 💥 La conexión con la base de datos falla. 💥 O ocurre un error inesperado. El resultado sería terrible. Tu saldo disminuiría. Pero el destinatario nunca recibiría el dinero. En otras palabras... 😨 Los $500 simplemente desaparecieron. Evidentemente, un sistema bancario no puede permitirse algo así. Y tampoco lo puede hacer una tienda en línea, una aerolínea o cualquier aplicación que maneje información importante. Para evitar este tipo de situaciones existen las transacciones . Son uno de los mecanismos más importantes que ofrecen las bases de datos modernas para garantizar que la información permanezca correcta incluso cuando ocurren errores. 🧠 ¿Qué es una transacción? Una transacción es un conjunto de operaciones que la base de datos ejecuta como si fueran una única acción. La idea es muy sencilla. Todas las operaciones relacionadas deben completarse correctamente. Si una sola falla... 👉 la base de datos deshace absolutamente todos los cambios. Es decir: ✅ Todo se ejecuta correctamente. o ❌ No se ejecuta nada. No existen resultados a medias. No existen estados intermedios. No existen datos incompletos. 🌍 ¿Por qué existen las transacciones? Las aplicaciones modernas realizan muchas operaciones que dependen unas de otras. Por ejemplo: 💳 Transferencias bancarias. 🛒 Compras en línea. 🎟️ Reservas de vuelos. 🏨 Reservas de hoteles. 📦 Actualización de inventarios. 👥 Registro de usuarios. Muchas veces una sola acción del usuario implica modificar varias tablas al mismo tiempo. Si alguna de esas modificaciones falla... todo el sistema podría quedar inconsistente. Las transacciones existen precisamente para evitar ese problema. ⚙️ ¿Cómo funciona una transacción? Supongamos nuevamente una transferencia bancaria. El proceso completo podría verse así. 1️⃣ Restar $500 de la cuenta A. 2️⃣ Sumar $500 a la cuenta B. Si ambas operaciones terminan correctamente: ✅ La base de datos confirma los cambios. Pero imaginemos otro escenario. El primer paso funciona. El segundo genera un error. ¿Qué hace la base de datos? 👉 Revierte automáticamente el primer cambio. Al finalizar... todo vuelve exactamente al estado en que estaba antes de comenzar. Como si la transferencia nunca hubiera existido. 💡 Un ejemplo cotidiano Piensa en un cajero automático. Solicitas retirar dinero. Internamente ocurren varias operaciones. 💰 Verificar saldo. 💳 Validar tarjeta. 📉 Descontar dinero de la cuenta. 🧾 Registrar el movimiento. 💵 Entregar efectivo. Si el cajero detecta que no puede entregar el dinero... la cuenta no debería descontarse. Toda la operación debe cancelarse. Eso es precisamente una transacción. 🚀 ¿Por qué son tan importantes? Las transacciones garantizan que la información permanezca correcta incluso cuando aparecen errores inesperados. Gracias a ellas es posible evitar situaciones como: ❌ Dinero perdido. ❌ Inventario incorrecto. ❌ Pedidos incompletos. ❌ Pagos duplicados. ❌ Usuarios creados parcialmente. ❌ Información inconsistente entre tablas. En sistemas críticos, las transacciones son indispensables. 🛒 Un ejemplo real Imagina una tienda en línea. Cuando un cliente realiza una compra ocurren varias operaciones. 📦 Crear el pedido. 💳 Registrar el pago. 📉 Descontar existencias del inventario. 📄 Generar la factura. 📧 Registrar el envío del correo de confirmación. Todo esto forma parte de una única operación lógica. Si el pago falla... no tendría sentido crear el pedido. Si el inventario no puede actualizarse... tampoco debería cobrarse al cliente. Por eso muchas aplicaciones agrupan todas estas acciones dentro de una misma transacción. 🔥 Las propiedades ACID Las transacciones se apoyan en cuatro principios fundamentales conocidos como ACID . Estos principios garantizan que las operaciones sean seguras y consistentes. 🅰️ Atomicidad (Atomicity) Todo o nada. La transacción se ejecuta completamente o se cancela por completo. Nunca queda a medias. 🅲 Consistencia (Consistency) La base de datos siempre pasa de un estado válido a otro estado válido. No importa si la operación fue exitosa o falló. Las reglas del sistema siempre deben cumplirse. 🅸 Aislamiento (Isolation) Las transacciones que ocurren simultáneamente no deben interferir entre sí. Cada una trabaja como si fuera la única que existe en ese momento. Esto evita muchos problemas cuando cientos o miles de usuarios utilizan la aplicación al mismo tiempo. 🅳 Durabilidad (Durability) Una vez que una transacción fue confirmada... los cambios permanecen almacenados incluso si ocurre un apagón o una falla del servidor. Los datos ya no pueden perderse. 🌐 ¿Cómo se implementan en SQL? Normalmente una transacción comienza con una instrucción como: BEGIN TRANSACTION; Después se ejecutan todas las operaciones necesarias. UPDATE Cuentas SET Saldo = Saldo - 500 WHERE Id = 1; UPDATE Cuentas SET Saldo = Saldo + 500 WHERE Id = 2; Si todo sale correctamente: COMMIT; El motor guarda definitivamente los cambios. Pero si ocurre cualquier error: ROLLBACK; La base de datos elimina todos los cambios realizados durante esa transacción. Y todo vuelve exactamente al estado inicial. ⚠️ ¿Qué hacen realmente COMMIT y ROLLBACK? Podemos imaginarlos así. COMMIT 📌 "Todo salió bien." 👉 Guarda permanentemente los cambios. ROLLBACK 📌 "Algo salió mal." 👉 Deshaz absolutamente todo. Gracias a estas dos instrucciones las bases de datos pueden recuperarse de muchos errores sin comprometer la información. 🔥 Un error muy común Muchos desarrolladores ejecutan varias consultas independientes cuando en realidad deberían formar parte de una sola transacción. Por ejemplo: Actualizar inventario. Registrar pedido. Actualizar saldo. Crear factura. Si alguna consulta falla... el sistema puede quedar en un estado inconsistente. Y esos errores suelen ser muy difíciles de detectar posteriormente. 🛠️ Buenas prácticas Cuando trabajes con transacciones es recomendable: ✅ Agrupar operaciones relacionadas. ✅ Mantener las transacciones lo más cortas posible. ✅ Utilizar COMMIT únicamente cuando todo haya finalizado correctamente. ✅ Ejecutar ROLLBACK ante cualquier error. ✅ Evitar realizar operaciones innecesarias dentro de una transacción. Mientras menos tiempo permanezca abierta una transacción... menor será el riesgo de bloqueos y conflictos con otros usuarios. 🌍 Ejemplos que utilizas todos los días Aunque no lo notes, las transacciones están presentes en muchísimas aplicaciones. Cuando utilizas: 💳 Tu banca móvil. 🛒 Amazon. 🎟️ Una plataforma para comprar boletos. 🏨 Un sistema de reservas. 📦 Un ERP empresarial. Es muy probable que cada acción importante esté protegida mediante una transacción. Gracias a ello la información permanece consistente incluso cuando ocurren fallos inesperados. 🧩 La realidad Las transacciones no existen para evitar que ocurran errores. Los errores siempre pueden aparecer. Lo que realmente hacen es impedir que esos errores dejen la base de datos en un estado incorrecto. Por eso son uno de los pilares fundamentales de cualquier sistema que maneje información importante. Cada vez que realizas una compra, haces una transferencia bancaria o reservas un vuelo... es muy probable que una transacción esté trabajando silenciosamente detrás de escena para proteger tus datos. Y si algo sale mal... la base de datos simplemente actúa como si esa operación nunca hubiera ocurrido. 🚀 Conclusión Una transacción es un mecanismo que permite ejecutar varias operaciones como una única unidad lógica. Su principal objetivo es garantizar que los datos permanezcan consistentes incluso cuando ocurren errores durante la ejecución. Gracias a principios como ACID, las bases de datos modernas pueden asegurar que todas las operaciones relacionadas se completen correctamente o, en caso contrario, revertir todos los cambios realizados. Comprender cómo funcionan las transacciones es fundamental para desarrollar aplicaciones seguras y confiables. Porque una buena base de datos no solo almacena información. También protege su integridad cuando las cosas no salen como estaban previstas. 💬 ¿Alguna vez tuviste que utilizar COMMIT y ROLLBACK para solucionar un problema en producción? ¿En qué tipo de proyecto fue? 👀 🔥 El backend no se ve, pero sin él, nada funciona. #SQL #Transacciones #BaseDeDatos #Backend #Database #ACID #SoftwareEngineering #PostgreSQL #MySQL #Programación
08 jul 2026
Leer publicación
Base de datos
¿Qué es un ORM y por qué existe?
Cuando desarrollas una aplicación, una de las tareas más comunes consiste en guardar y consultar información en una base de datos. Por ejemplo: 👤 Obtener un usuario. 📦 Registrar un pedido. 💬 Guardar un comentario. 📄 Actualizar un perfil. Para realizar estas operaciones, la base de datos entiende un lenguaje muy específico: SQL . Una opción sería escribir consultas SQL para absolutamente todo. Pero existe otra alternativa que hace el trabajo mucho más cómodo para los desarrolladores. Trabajar directamente con objetos del lenguaje de programación. Eso es precisamente lo que hace un ORM . Y aunque muchas veces trabaja silenciosamente detrás de escena, se ha convertido en una de las herramientas más importantes del desarrollo backend moderno. 🧠 ¿Qué es un ORM? ORM significa Object-Relational Mapping , que en español se traduce como Mapeo Objeto-Relacional . Es una herramienta que actúa como un puente entre el código de una aplicación y una base de datos relacional. Su objetivo es permitir que el desarrollador trabaje con objetos en lugar de escribir consultas SQL para cada operación. En otras palabras... 👉 transforma las tablas de una base de datos en clases. 👉 transforma cada registro en un objeto. 👉 y convierte las operaciones sobre esos objetos en instrucciones SQL. Así puedes trabajar utilizando el lenguaje de programación que ya conoces, mientras el ORM se encarga de comunicarse con la base de datos. 🌍 ¿Por qué existe un ORM? Antes de que los ORMs se popularizaran, los desarrolladores escribían prácticamente todas las consultas SQL manualmente. Por ejemplo: SELECT * FROM Usuarios WHERE id = 1; Después: INSERT INTO Usuarios (...) Luego: UPDATE Usuarios SET ... Y así sucesivamente. En aplicaciones pequeñas esto no representa un gran problema. Pero cuando un proyecto comienza a crecer, escribir y mantener cientos o miles de consultas SQL puede volverse repetitivo y difícil de administrar. Los ORMs surgieron precisamente para reducir ese trabajo repetitivo y permitir que los desarrolladores se concentren más en la lógica del negocio. ⚙️ ¿Cómo funciona? Veamos un ejemplo muy sencillo. Sin utilizar un ORM, para obtener un usuario normalmente escribiríamos algo parecido a esto: SELECT * FROM Usuarios WHERE id = 1; Con Django ORM, la misma operación puede verse así: usuario = Usuario.objects.get(id=1) Observa que ya no estás escribiendo SQL. Estás trabajando con un objeto llamado Usuario . Internamente, el ORM interpreta esa instrucción y genera automáticamente la consulta SQL correspondiente. El desarrollador nunca tiene que escribirla. 💡 Otro ejemplo Supongamos que deseas registrar un nuevo usuario. Sin ORM: INSERT INTO Usuarios (nombre, email) VALUES ('Herman', 'herman@email.com'); Con un ORM: Usuario.objects.create( nombre="Herman", email="herman@email.com" ) El resultado es exactamente el mismo. La diferencia es que el desarrollador trabaja utilizando el lenguaje de programación de la aplicación. 🚀 ¿Qué otras operaciones puede realizar? Los ORMs permiten realizar prácticamente todas las operaciones comunes sobre una base de datos. Por ejemplo: Consultar registros. Usuario.objects.all() Buscar un registro específico. Usuario.objects.get(id=1) Filtrar información. Usuario.objects.filter(activo=True) Actualizar registros. usuario.nombre = "Carlos" usuario.save() Eliminar registros. usuario.delete() Todo sin escribir una sola línea de SQL. 🌐 ¿Qué ventajas ofrece un ORM? Utilizar un ORM aporta numerosos beneficios. Entre los más importantes encontramos: ✅ Mayor productividad Permite desarrollar aplicaciones mucho más rápido. Muchas operaciones comunes requieren solo una línea de código. ✅ Menos código repetitivo No es necesario escribir constantemente consultas SQL para operaciones sencillas. ✅ Código más legible Trabajar con objetos suele resultar más natural que trabajar con cadenas SQL. Especialmente cuando el proyecto crece. ✅ Independencia del motor de base de datos Muchos ORMs permiten cambiar entre diferentes motores con pocos cambios. Por ejemplo: MySQL. PostgreSQL. SQLite. MariaDB. El código de la aplicación cambia muy poco. ✅ Protección frente a errores comunes La mayoría de los ORMs ayudan a prevenir problemas como la inyección SQL al utilizar consultas parametrizadas de forma automática. Aunque esto no significa que la aplicación sea completamente inmune a vulnerabilidades. 🏗️ ¿Cómo representa una tabla? Supongamos una tabla llamada Usuarios . Con un ORM normalmente se representa mediante una clase. Por ejemplo: class Usuario(models.Model): nombre = models.CharField(...) email = models.EmailField(...) Cada vez que creas un objeto de esa clase... estás trabajando con un registro de la tabla. El ORM mantiene sincronizados ambos mundos. 🔥 ¿Entonces ya no necesito aprender SQL? No. Y este es probablemente uno de los errores más comunes entre quienes comienzan a desarrollar aplicaciones. Muchos piensan: "Si utilizo un ORM, nunca tendré que aprender SQL." La realidad es muy diferente. El ORM facilita muchísimo el trabajo. Pero sigue siendo fundamental comprender cómo funciona la base de datos. Porque tarde o temprano necesitarás: 🔎 Optimizar consultas. 📊 Analizar planes de ejecución. ⚡ Crear índices. 🛠️ Resolver problemas de rendimiento. 📈 Mejorar tiempos de respuesta. Y para hacer todo eso... necesitas conocer SQL. Por eso un buen desarrollador backend domina ambas herramientas. ⚠️ ¿Cuándo un ORM puede no ser suficiente? Aunque los ORMs son extremadamente útiles, existen situaciones donde escribir SQL manualmente sigue siendo la mejor opción. Por ejemplo: Consultas muy complejas. Procesamiento masivo de datos. Consultas altamente optimizadas. Reportes avanzados. Funciones específicas del motor de base de datos. Afortunadamente, prácticamente todos los ORMs permiten ejecutar SQL nativo cuando es necesario. Así puedes combinar productividad con máximo rendimiento. 🌐 Algunos ORMs muy conocidos Cada lenguaje suele tener su propio ORM. Entre los más utilizados encontramos: 🐍 Django ORM. ⚡ SQLAlchemy. ☕ Hibernate. ⚡ Entity Framework. 🟢 Prisma. 🟨 Sequelize. 🦫 GORM. Todos persiguen el mismo objetivo. Facilitar el acceso a la base de datos utilizando objetos. 🛠️ Buenas prácticas Si decides utilizar un ORM, es recomendable seguir algunas prácticas importantes. ✅ Aprender también SQL. ✅ Revisar las consultas que genera el ORM. ✅ Evitar consultas innecesarias. ✅ Utilizar correctamente las relaciones entre modelos. ✅ Medir el rendimiento cuando la aplicación crezca. Recuerda que un ORM simplifica el desarrollo. Pero no elimina la necesidad de comprender cómo funciona la base de datos. 🌍 Un ejemplo de la vida real Imagina que desarrollas una red social. Cada vez que un usuario abre su perfil, el backend necesita obtener: 👤 Sus datos. 📸 Sus fotografías. 👥 Sus seguidores. 💬 Sus publicaciones. Todo esto puede lograrse utilizando objetos del ORM. Mientras tanto, detrás de escena, la herramienta genera múltiples consultas SQL para obtener exactamente la información necesaria. El usuario nunca ve ese proceso. Y el desarrollador tampoco necesita escribir todas las consultas manualmente. 🧩 La realidad Los ORMs existen para que los desarrolladores dediquen más tiempo a resolver problemas del negocio y menos tiempo escribiendo consultas repetitivas. Permiten trabajar con un modelo más natural, basado en objetos, sin dejar de aprovechar toda la potencia de una base de datos relacional. Sin embargo, siguen siendo únicamente un intermediario. Porque al final... el ORM siempre termina haciendo exactamente lo mismo. 👉 Hablar SQL con la base de datos. 🚀 Conclusión Un ORM es una herramienta que traduce objetos del lenguaje de programación en consultas SQL y viceversa. Gracias a él es posible desarrollar aplicaciones de forma más rápida, mantener un código más limpio y reducir la cantidad de consultas repetitivas que un desarrollador debe escribir. Sin embargo, utilizar un ORM no significa olvidar SQL. Al contrario. Comprender qué ocurre detrás de escena permite escribir aplicaciones más eficientes, optimizar consultas y aprovechar al máximo las capacidades del motor de base de datos. Porque un ORM puede hacer que escribir código sea mucho más sencillo. Pero entender SQL es lo que realmente te permitirá construir aplicaciones rápidas, escalables y profesionales. 💬 ¿Prefieres trabajar con un ORM como Django ORM, Prisma o Entity Framework, o cuando necesitas el máximo rendimiento optas por escribir SQL directamente? 👀 🔥 El backend no se ve, pero sin él, nada funciona. #ORM #SQL #Backend #Django #EntityFramework #Prisma #BasesDeDatos #SoftwareEngineering #Programación #DesarrolloBackend
07 jul 2026
Leer publicaciónSeguridad
¿Qué es el Rate Limiting y cómo protege una API?
Imagina que acabas de publicar una API. Los primeros días todo funciona perfectamente. Recibe unas cuantas peticiones por segundo. Los usuarios pueden consultar información sin problemas. Pero conforme tu aplicación crece... las solicitudes comienzan a aumentar. 10 peticiones por segundo. Luego 100. Después 1,000. Y de repente... un solo usuario, un bot o incluso un atacante empieza a enviar miles de solicitudes en cuestión de segundos. 😵 El servidor comienza a consumir toda su CPU. 😵 La memoria aumenta. 😵 Las respuestas se vuelven lentas. 😵 Los demás usuarios dejan de recibir servicio. ¿Cómo evitar que una sola persona afecte a todos los demás? La respuesta está en un mecanismo conocido como Rate Limiting . Aunque suele pasar desapercibido, es una de las primeras líneas de defensa que utilizan las APIs modernas para proteger su infraestructura. 🧠 ¿Qué es el Rate Limiting? El Rate Limiting es un mecanismo que limita la cantidad de peticiones que un usuario, una dirección IP, un dispositivo o una aplicación puede realizar durante un periodo determinado. Su funcionamiento es muy sencillo. La API establece una regla. Por ejemplo: 👉 100 peticiones por minuto. Mientras el cliente permanezca dentro de ese límite... la API responderá normalmente. Pero si intenta superar esa cantidad... el servidor comenzará a rechazar temporalmente las solicitudes. De esta forma evita que un solo cliente consuma todos los recursos disponibles. 🌍 ¿Por qué existe? Internet está lleno de aplicaciones públicas. Muchas de ellas reciben miles o incluso millones de peticiones todos los días. Sin ningún tipo de control podrían ocurrir situaciones como: 🤖 Bots realizando consultas masivas. 🔓 Ataques de fuerza bruta contra formularios de inicio de sesión. 📈 Aplicaciones mal programadas enviando miles de peticiones por error. 💥 Usuarios consumiendo recursos de forma excesiva. El resultado sería el mismo. El servidor tendría que dedicar gran parte de su capacidad a atender unas pocas solicitudes abusivas. Y los usuarios legítimos terminarían siendo los más afectados. El Rate Limiting existe precisamente para evitar ese escenario. ⚙️ ¿Cómo funciona? Imaginemos que una API establece la siguiente política. 100 solicitudes por minuto. El proceso podría verse así. 1️⃣ El cliente realiza una petición. 2️⃣ El servidor identifica quién la envió. 3️⃣ Incrementa un contador. 4️⃣ Verifica si el límite fue alcanzado. Si todavía quedan solicitudes disponibles: ✅ La petición continúa normalmente. Pero cuando el contador supera el límite establecido: ❌ La API rechaza temporalmente las nuevas solicitudes. Después de que transcurre el tiempo definido... el contador vuelve a comenzar desde cero. Y el cliente puede seguir utilizando el servicio. 🚀 ¿Qué responde la API? Cuando un cliente supera el límite permitido, normalmente recibe el código HTTP: 429 Too Many Requests Este código indica que el problema no está en la API. El problema es que el cliente ha realizado demasiadas solicitudes en un periodo muy corto. En muchos casos la respuesta también incluye encabezados como: Retry-After: 60 Indicando cuántos segundos debe esperar antes de volver a intentarlo. 💡 Un ejemplo cotidiano Imagina un restaurante. Solo hay diez mesas disponibles. Si cien personas intentan entrar al mismo tiempo... el restaurante no puede atenderlas a todas. Lo más razonable sería formar una fila y permitir el acceso poco a poco. Las APIs hacen algo muy parecido. No bloquean a los usuarios porque sí. Simplemente controlan el ritmo con el que reciben solicitudes para mantener el servicio estable. 🔥 ¿Por qué es tan importante? El Rate Limiting aporta muchos beneficios. Entre ellos: ✅ Evita abusos. ✅ Protege la infraestructura. ✅ Reduce la posibilidad de ataques automatizados. ✅ Distribuye mejor los recursos. ✅ Garantiza una experiencia más estable para todos los usuarios. Sin este mecanismo, una API pública sería mucho más vulnerable. 🛡️ Rate Limiting y seguridad Muchas personas piensan que el Rate Limiting únicamente sirve para mejorar el rendimiento. En realidad también es una herramienta muy importante de seguridad. Por ejemplo. Supongamos que un atacante intenta descubrir la contraseña de un usuario. Sin límites podría realizar: 1,000. 10,000. O incluso millones de intentos. Con Rate Limiting... después de unos pocos intentos la API comenzará a bloquear temporalmente nuevas solicitudes. Esto hace mucho más difícil ejecutar ataques de fuerza bruta. 🌐 ¿Cómo sabe la API a quién limitar? Existen diferentes estrategias. Las más utilizadas son: 🌍 Dirección IP. 👤 Usuario autenticado. 🔑 API Key. 📱 Identificador del dispositivo. 🍪 Sesión. Dependiendo del tipo de aplicación puede utilizarse una sola estrategia o combinar varias. Por ejemplo. Una API pública podría limitar por dirección IP. Mientras que una API privada podría hacerlo utilizando el usuario autenticado. ⚡ Algoritmos utilizados Detrás del Rate Limiting existen distintos algoritmos. Los más conocidos son: 🪣 Token Bucket El sistema dispone de una cantidad limitada de "tokens". Cada petición consume uno. Cuando se agotan... las nuevas solicitudes deben esperar. 🪣 Leaky Bucket Las peticiones entran en una especie de cubeta. Van saliendo poco a poco a una velocidad constante. Si llegan demasiadas... las sobrantes son rechazadas. ⏱️ Fixed Window Cuenta cuántas solicitudes se realizaron durante un intervalo fijo. Por ejemplo: 100 peticiones entre las 10:00 y las 10:01. Al comenzar el siguiente minuto... el contador vuelve a cero. 🔄 Sliding Window Es una versión más precisa. En lugar de trabajar con intervalos fijos... analiza continuamente el tiempo transcurrido. Esto evita algunos problemas presentes en el método anterior. 🌐 ¿Dónde suele implementarse? Una ventaja del Rate Limiting es que no necesariamente debe ejecutarse dentro del backend. Muchas veces se implementa antes de que la petición llegue a la aplicación. Por ejemplo mediante: 🟢 Nginx. ☁️ Cloudflare. 🌐 API Gateway. 🛡️ Kong. 🚀 Traefik. ⚡ Middlewares de Express. 🐍 Django. ⚡ Laravel. De esta forma muchas solicitudes abusivas se bloquean incluso antes de consumir recursos del servidor de aplicaciones. ⚠️ Un error muy común Algunos desarrolladores piensan que basta con aumentar la capacidad del servidor. Más CPU. Más memoria. Más servidores. Pero si una API permite solicitudes ilimitadas... el problema tarde o temprano volverá a aparecer. La solución no consiste únicamente en tener más recursos. También consiste en administrar inteligentemente cómo se utilizan. Y ahí es donde el Rate Limiting juega un papel fundamental. 🛠️ Buenas prácticas Cuando implementes Rate Limiting es recomendable: ✅ Definir límites razonables según el tipo de endpoint. ✅ Utilizar diferentes límites para usuarios autenticados y anónimos. ✅ Informar claramente cuándo un cliente superó el límite. ✅ Registrar intentos excesivos. ✅ Combinarlo con otras medidas de seguridad como CAPTCHA o autenticación multifactor. Así es posible proteger la API sin afectar innecesariamente la experiencia de los usuarios legítimos. 🌍 La realidad Cada vez que utilizas una API pública... ya sea de redes sociales, servicios bancarios, plataformas de mapas o comercio electrónico... es muy probable que exista un sistema contando silenciosamente cuántas solicitudes realizas. No porque quiera impedirte utilizar el servicio. Sino porque necesita garantizar que millones de personas puedan acceder a él de forma justa y segura. Gracias al Rate Limiting, una sola persona no puede monopolizar los recursos de toda la infraestructura. 🚀 Conclusión El Rate Limiting es un mecanismo que controla cuántas solicitudes puede realizar un cliente durante un periodo determinado. Su objetivo no es únicamente mejorar el rendimiento de una API. También protege frente a abusos, ataques automatizados y consumo excesivo de recursos. Implementarlo correctamente ayuda a construir servicios más estables, seguros y preparados para crecer. Porque una buena API no solo responde rápido. También sabe cuándo debe poner límites para seguir funcionando correctamente para todos. 💬 ¿Has implementado Rate Limiting en tus APIs? ¿Qué estrategia utilizas normalmente: por IP, por usuario autenticado o mediante API Keys? 👀 🔥 El backend no se ve, pero sin él, nada funciona. #Backend #RateLimiting #Seguridad #APIs #Ciberseguridad #SoftwareEngineering #Programación #Nginx #Cloudflare #DesarrolloBackend
12 jul 2026
Leer publicaciónSeguridad
¿Cómo funciona un token JWT por dentro?
Cuando inicias sesión en una aplicación... es normal que escribas tu usuario y contraseña una sola vez. Después puedes navegar entre distintas pantallas, consultar información o realizar operaciones sin volver a introducir tus credenciales en cada petición. Pero entonces surge una pregunta muy interesante. 👉 ¿Cómo sabe el servidor que sigues siendo tú si HTTP no recuerda nada entre una petición y otra? La respuesta, en muchas aplicaciones modernas, está en un JWT . Aunque para muchos desarrolladores es simplemente una cadena larga de caracteres, detrás de ella existe un mecanismo cuidadosamente diseñado para transportar información de forma segura entre el cliente y el servidor. Comprender cómo funciona realmente un JWT es fundamental para desarrollar APIs seguras y entender muchos de los sistemas de autenticación actuales. 🧠 ¿Qué es un JWT? JWT significa JSON Web Token . Es un estándar abierto (RFC 7519) utilizado para transmitir información entre dos partes de forma compacta y verificable. Su principal objetivo es transportar información relacionada con un usuario después de que este ha sido autenticado. Es importante aclarar algo que suele generar confusión. Un JWT no autentica al usuario . La autenticación ocurre antes. Por ejemplo: ✅ El usuario escribe su correo y contraseña. ✅ El servidor verifica que las credenciales sean correctas. Solo después de esa verificación se genera un JWT. A partir de ese momento, el token sirve para demostrar la identidad del usuario en las siguientes peticiones. 🌍 ¿Por qué existe? Recordemos que HTTP es un protocolo sin estado ( stateless ). Eso significa que cada petición es completamente independiente. Cuando un navegador solicita información, el servidor no recuerda automáticamente quién hizo la petición anterior. Sin algún mecanismo adicional, el usuario tendría que iniciar sesión una y otra vez. JWT resuelve ese problema. El servidor entrega un token al cliente. Y posteriormente el cliente envía ese mismo token en cada solicitud. Así el servidor puede verificar rápidamente quién realiza la petición. ⚙️ ¿Cómo está compuesto? Un JWT está formado por tres partes. Header.Payload.Signature Cada sección está separada por un punto. Aunque visualmente parece una sola cadena de texto... internamente cada parte tiene una función muy específica. 🏷️ 1. Header El Header contiene información sobre el propio token. Normalmente incluye: ✅ El algoritmo utilizado para generar la firma. ✅ El tipo de token. Por ejemplo: { "alg": "HS256", "typ": "JWT" } El servidor utiliza esta información para saber cómo verificar posteriormente el token. 📄 2. Payload El Payload contiene la información que viajará dentro del token. Aquí suelen encontrarse datos como: 👤 ID del usuario. 📧 Correo electrónico. 👥 Roles. 🛡️ Permisos. ⏳ Fecha de expiración. 🏢 Organización. 🔑 Identificador único del token. Por ejemplo: { "user_id": 15, "email": "herman@email.com", "role": "admin" } Aquí aparece uno de los errores más comunes. Muchas personas creen que esta información está protegida porque el token "se ve raro". Pero no es así. ⚠️ El Payload NO está cifrado El Payload simplemente está codificado en Base64URL . Eso significa que cualquier persona que posea el token puede decodificarlo fácilmente. Por esa razón: ❌ Nunca debes almacenar contraseñas. ❌ Nunca debes guardar números de tarjetas. ❌ Nunca debes incluir información confidencial. El Payload únicamente debe contener información que pueda ser leída sin comprometer la seguridad del sistema. 🛡️ 3. Signature La tercera parte es probablemente la más importante. La firma . Es la encargada de garantizar que nadie haya modificado el token. Para generarla el servidor utiliza: 🔑 Una clave secreta. O bien: 🔐 Una clave privada, dependiendo del algoritmo utilizado. La firma se calcula utilizando: El Header. El Payload. La clave secreta. Cuando el servidor recibe nuevamente el JWT... realiza exactamente el mismo cálculo. Si ambas firmas coinciden: ✅ El token es auténtico. Si alguien modificó un solo carácter... aunque sea el nombre del usuario o la fecha de expiración... la firma cambia completamente. Y el servidor rechaza el token inmediatamente. 💡 ¿Cómo funciona todo el proceso? El flujo completo suele verse así. 1️⃣ El usuario inicia sesión. 2️⃣ El backend verifica las credenciales. 3️⃣ Si son correctas, genera un JWT firmado. 4️⃣ Devuelve el token al cliente. 5️⃣ El cliente lo almacena. 6️⃣ En cada petición posterior lo envía al servidor. 7️⃣ El servidor verifica la firma. 8️⃣ Si todo es correcto... permite acceder al recurso solicitado. Todo este proceso suele completarse en apenas unos milisegundos. 🌐 ¿Dónde se envía el JWT? Lo más habitual es utilizar el encabezado HTTP Authorization . Por ejemplo: Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... El prefijo Bearer indica que el cliente está presentando un token de acceso. El servidor extrae el JWT, verifica la firma y decide si la petición puede continuar. 🚀 ¿Por qué se utiliza tanto? JWT ofrece varias ventajas importantes. Entre ellas: ✅ APIs completamente Stateless. ✅ Menor necesidad de consultar la base de datos. ✅ Mejor escalabilidad. ✅ Fácil integración entre diferentes servicios. ✅ Compatibilidad con aplicaciones móviles. ✅ Muy útil en arquitecturas de microservicios. Por eso se ha convertido en uno de los mecanismos más utilizados para proteger APIs REST. 🔥 Stateless: una de sus mayores ventajas Con sesiones tradicionales... el servidor debe recordar a cada usuario. Eso normalmente implica almacenar información en memoria o en una base de datos. Con JWT ocurre algo diferente. Toda la información necesaria viaja dentro del propio token. El servidor únicamente necesita verificar la firma. Esto simplifica enormemente el trabajo cuando existen múltiples servidores atendiendo miles de peticiones simultáneamente. 🌍 JWT en microservicios En arquitecturas de microservicios esto resulta especialmente útil. Supongamos una plataforma formada por varios servicios. 👤 Servicio de usuarios. 🛒 Servicio de pedidos. 💳 Servicio de pagos. 📦 Servicio de inventario. Todos ellos pueden verificar el mismo JWT. No necesitan preguntar constantemente al servidor de autenticación quién es el usuario. Esto reduce el número de consultas y mejora el rendimiento general del sistema. ⚠️ Errores muy comunes Existen varias ideas equivocadas alrededor de JWT. Una de las más frecuentes es pensar que el token está cifrado. No lo está. Está firmado. Otra es almacenar demasiada información dentro del Payload. Mientras más datos contenga el token... más grande será cada petición HTTP. También es un error generar tokens sin fecha de expiración. Si un atacante obtiene un JWT válido que nunca expira... podría utilizarlo indefinidamente. 🛠️ Buenas prácticas Cuando implementes autenticación con JWT es recomendable: ✅ Utilizar HTTPS. ✅ Definir tiempos de expiración razonables. ✅ Firmar siempre los tokens con algoritmos seguros. ✅ No almacenar información sensible en el Payload. ✅ Revocar tokens comprometidos cuando sea necesario. ✅ Utilizar Refresh Tokens para sesiones prolongadas. Estas prácticas ayudan a reducir muchos riesgos de seguridad. 🌍 JWT está en todas partes Aunque muchas veces no lo notes, JWT se utiliza en una enorme cantidad de aplicaciones modernas. 📱 Aplicaciones móviles. 🌐 APIs REST. ☁️ Microservicios. 🔗 Integraciones entre plataformas. 🛒 Comercio electrónico. 🏦 Sistemas bancarios. Cada vez que una aplicación recuerda quién eres sin pedirte nuevamente la contraseña... es muy probable que exista un JWT trabajando detrás de escena. 🧩 La realidad Un JWT puede parecer únicamente una cadena larga de caracteres. Pero en realidad contiene toda la información necesaria para que un servidor identifique al usuario, conozca sus permisos y verifique que nadie ha manipulado esos datos durante el viaje. Su verdadero valor no consiste en ocultar información. Consiste en garantizar que esa información no pueda modificarse sin ser detectada. Por eso se ha convertido en una pieza fundamental de la seguridad en las APIs modernas. 🚀 Conclusión JWT es un mecanismo seguro y eficiente para transportar información relacionada con un usuario después de que ha sido autenticado. Gracias a su estructura compuesta por Header, Payload y Signature, permite que el servidor verifique rápidamente la identidad del cliente sin necesidad de consultar constantemente la base de datos. Sin embargo, es importante recordar que un JWT no cifra la información. Su función principal es garantizar la integridad de los datos mediante una firma criptográfica. Comprender esta diferencia ayuda a implementar sistemas de autenticación mucho más seguros y evitar errores muy comunes durante el desarrollo. Porque al final... un JWT no existe para ocultar la información. Existe para demostrar que esa información sigue siendo exactamente la misma que el servidor generó. 💬 ¿En tus proyectos prefieres implementar autenticación con JWT , sesiones tradicionales o una combinación de ambas tecnologías? 👀 🔥 El backend no se ve, pero sin él, nada funciona. #JWT #Backend #Seguridad #APIs #JSONWebToken #Autenticación #SoftwareEngineering #Programación #DesarrolloBackend #Ciberseguridad
11 jul 2026
Leer publicaciónArquitectura de Software
¿Qué es un middleware y qué hace antes de llegar a tu controlador?
Cuando un usuario hace una petición a una API... es fácil imaginar que la solicitud llega directamente al controlador que contiene la lógica del negocio. Pero en una aplicación moderna eso casi nunca ocurre. Antes de que el controlador reciba la petición... esta suele atravesar una serie de componentes encargados de verificar que todo esté en orden. ¿El usuario está autenticado? ¿Tiene permisos para acceder? ¿La petición cumple con las reglas esperadas? ¿Debe registrarse en los logs? ¿Se superó el límite de peticiones permitido? Todas estas comprobaciones suelen realizarse antes de ejecutar una sola línea de código del controlador. A esos componentes se les conoce como middlewares . Y aunque normalmente trabajan de forma silenciosa, son una de las piezas más importantes en la arquitectura de cualquier aplicación backend. 🧠 ¿Qué es un middleware? Un middleware es un componente que se ejecuta entre la petición del cliente y el controlador . Su función es interceptar cada solicitud para realizar alguna tarea antes de que llegue a la lógica principal de la aplicación. Podemos imaginarlo como un filtro. Cada petición que entra al sistema debe atravesar una serie de filtros antes de obtener acceso al controlador. Si todo está correcto... la petición continúa su camino. Si alguno de los filtros detecta un problema... la petición puede detenerse inmediatamente. En otras palabras... 👉 un middleware decide si una solicitud puede seguir avanzando o no. 🌍 ¿Por qué existen los middlewares? Imagina una aplicación con cien endpoints. Si cada controlador tuviera que verificar: 🔐 La autenticación. 👥 Los permisos. 📋 Los registros de auditoría. 🌐 La configuración de CORS. 🚦 El límite de peticiones. Estarías escribiendo exactamente el mismo código una y otra vez. Además de ser repetitivo... sería muy difícil de mantener. Los middlewares existen para evitar esa duplicación. Permiten centralizar tareas comunes y reutilizarlas en toda la aplicación. Así, cada controlador puede concentrarse únicamente en resolver el problema de negocio para el que fue creado. ⚙️ ¿Cómo funciona? De forma simplificada, el flujo de una petición suele verse así: 👤 Usuario ⬇️ 🌐 Petición HTTP ⬇️ 🛡️ Middleware ⬇️ 🛡️ Middleware ⬇️ 🛡️ Middleware ⬇️ 🎯 Controlador ⬇️ 🗄️ Base de datos ⬇️ 📤 Respuesta Cada middleware recibe la petición. Puede modificarla. Validarla. Registrar información. O incluso detenerla completamente. Cuando termina su trabajo... la envía al siguiente middleware. Y solo después de atravesar toda esa cadena llega al controlador. 💡 Un ejemplo real Supongamos que un usuario intenta acceder al siguiente endpoint: GET /api/usuarios Antes de llegar al controlador pueden ejecutarse varias verificaciones. 1️⃣ Comprobar que existe un token de autenticación. 2️⃣ Validar que el JWT sea correcto. 3️⃣ Revisar que el usuario no haya expirado su sesión. 4️⃣ Confirmar que posee permisos para consultar usuarios. 5️⃣ Registrar la petición en los logs. 6️⃣ Medir cuánto tarda la solicitud. Si todo sale correctamente... el controlador finalmente obtiene la petición y consulta la base de datos. Pero si cualquiera de esos pasos falla... la petición termina ahí mismo. El controlador ni siquiera llega a ejecutarse. 🚀 ¿Qué tareas puede realizar un middleware? Los middlewares son extremadamente versátiles. Entre las tareas más comunes encontramos: 🔐 Verificar autenticación. 👥 Validar permisos y roles. 📋 Registrar logs. 📊 Medir tiempos de respuesta. 🌍 Configurar CORS. 🛡️ Proteger contra ataques. 🚦 Aplicar Rate Limiting. 📄 Validar encabezados HTTP. 🔄 Agregar información a la petición. 📝 Registrar auditorías. Cada middleware suele tener una única responsabilidad. Y precisamente esa simplicidad hace que el código sea mucho más limpio. 🔒 Middleware de autenticación Uno de los más utilizados. Su trabajo consiste en responder una pregunta muy sencilla. 👉 ¿Quién eres? Verifica credenciales como: 🔑 JWT. 🍪 Cookies de sesión. 🔐 Tokens OAuth. Si la identidad del usuario no puede comprobarse... la petición termina inmediatamente. 👥 Middleware de autorización Una vez autenticado el usuario... todavía queda otra pregunta. 👉 ¿Qué puede hacer? Este middleware revisa: Roles. Permisos. Políticas de acceso. Si un usuario intenta acceder a una zona restringida... el middleware devuelve un error sin permitir que el controlador se ejecute. 📋 Middleware de logs Otro middleware muy habitual. Cada petición queda registrada. Por ejemplo: 📅 Fecha. 🌐 Dirección IP. 👤 Usuario. 📍 Endpoint solicitado. ⏱️ Tiempo de respuesta. Estos registros resultan muy útiles para monitoreo, auditorías y solución de problemas. 🚦 Middleware de Rate Limiting Imagina que alguien intenta enviar diez mil peticiones por segundo. Sin protección... podría saturar el servidor. Un middleware de Rate Limiting permite establecer límites como: 100 solicitudes por minuto. 500 solicitudes por hora. Cuando un cliente supera ese límite... la petición se bloquea automáticamente. Esto ayuda a proteger la infraestructura frente a abusos y ataques. 🌐 Middleware de CORS Cuando un frontend intenta consumir una API ubicada en otro dominio... el navegador aplica las reglas de CORS. Muchos frameworks utilizan un middleware para indicar: Qué dominios están permitidos. Qué métodos HTTP pueden utilizarse. Qué encabezados son válidos. Todo esto ocurre antes de ejecutar cualquier controlador. 🔥 ¿Se pueden utilizar varios middlewares? Sí. Y de hecho es lo más común. Una sola petición puede atravesar cinco, diez o incluso más middlewares antes de llegar a su destino. Por ejemplo: 🛡️ CORS. ⬇️ 📋 Logs. ⬇️ 🔐 Autenticación. ⬇️ 👥 Autorización. ⬇️ 🚦 Rate Limiting. ⬇️ 🎯 Controlador. Cada uno realiza una tarea muy específica. Y después entrega la petición al siguiente. 🌐 Frameworks que utilizan middlewares Prácticamente todos los frameworks modernos implementan este patrón. Entre ellos encontramos: 🐍 Django. 🟢 Express.js. ⚡ Laravel. ☕ Spring Boot. 🦫 ASP.NET Core. ⚡ FastAPI. 🟩 NestJS. Aunque cada framework utiliza una implementación distinta... la idea siempre es la misma. Interceptar la petición antes de que llegue al controlador. ⚠️ Un error muy común Cuando alguien comienza a desarrollar APIs suele escribir toda la lógica directamente dentro del controlador. Por ejemplo: Validar autenticación. Revisar permisos. Registrar logs. Controlar errores. Validar encabezados. El resultado suele ser un controlador enorme y difícil de mantener. Los middlewares existen precisamente para evitar ese problema. Cada componente se ocupa únicamente de una responsabilidad. Y el controlador queda mucho más limpio. 🛠️ Buenas prácticas Cuando trabajes con middlewares es recomendable: ✅ Que cada middleware tenga una única responsabilidad. ✅ Evitar lógica de negocio dentro de ellos. ✅ Mantenerlos reutilizables. ✅ Ejecutar primero los más importantes, como autenticación. ✅ Registrar únicamente la información necesaria. Siguiendo estas prácticas es mucho más sencillo mantener una aplicación conforme crece. 🌍 La realidad Cada vez que consumes una API... es muy probable que tu petición atraviese varios middlewares antes de que el backend procese realmente tu solicitud. Aunque nunca los veas... ellos verifican autenticación. Controlan permisos. Registran actividad. Aplican políticas de seguridad. Protegen contra abusos. Y preparan toda la información para que el controlador solo tenga que resolver el problema de negocio. Son uno de esos componentes que casi nadie nota... pero sin ellos muchas aplicaciones modernas serían mucho más difíciles de desarrollar y mantener. 🚀 Conclusión Los middlewares son componentes que interceptan las peticiones antes de que lleguen al controlador para ejecutar tareas comunes como autenticación, autorización, validaciones, registros o configuración de seguridad. Gracias a ellos es posible reutilizar código, mantener los controladores limpios y organizar mejor la arquitectura de una aplicación. En lugar de repetir las mismas verificaciones en cada endpoint, los middlewares permiten centralizar responsabilidades y construir sistemas más seguros, mantenibles y escalables. Porque un buen controlador debería concentrarse únicamente en resolver la lógica del negocio. Todo lo demás... puede quedar en manos de un buen middleware. 💬 ¿Cuál es el middleware que consideras indispensable en cualquier API moderna: autenticación, autorización, logs, validaciones o rate limiting? 👀 🔥 El backend no se ve, pero sin él, nada funciona. #Backend #Middleware #Arquitectura #APIs #Programación #SoftwareEngineering #Django #ExpressJS #Laravel #DesarrolloBackend
10 jul 2026
Leer publicaciónContacto
¿Tienes una idea, proyecto, propuesta laboral o colaboración?
Escríbeme un mensaje por WhatsApp.
Mensaje rápido
Generar mensaje para WhatsApp
Llena los campos y se abrirá WhatsApp con un mensaje listo para enviar.