Una aplicación es un programa de software diseñado para que las personas realicen tareas específicas, ya sea desde un navegador, un celular o una computadora.

Aplicación

El cliente o frontend es todo lo que corre en el dispositivo del usuario: lo que ve, toca e interactúa en una aplicación.

Cliente (Frontend)

El backend es la parte de una aplicación que corre en el servidor, procesando datos, aplicando reglas de negocio y comunicándose con bases de datos.

Servidor (Backend)

El estado es la información que una aplicación necesita recordar en un momento dado para funcionar correctamente.

Estado

El flujo de datos describe cómo la información viaja entre el usuario, el frontend, el backend y la base de datos en una aplicación.

Flujo de datos

Valores de configuración que se definen fuera del código para adaptar la aplicación a cada ambiente.

Variables de entorno

Situaciones inesperadas que ocurren durante la ejecución de un programa y cómo manejarlas.

Errores y excepciones

Las diferentes categorías de valores que un programa puede almacenar y manipular.

Tipos de datos

Los archivos y carpetas que vas a encontrar en cualquier proyecto de código, y para qué sirve cada uno.

Anatomía de un proyecto

Un dominio es el nombre legible que identifica a un sitio web en internet, como google.com o miapp.com.ar.

Dominio

El DNS es el sistema que traduce nombres de dominio legibles (como google.com) a direcciones IP numéricas que las computadoras entienden.

HTTP es el protocolo que define cómo se comunican el navegador y el servidor; HTTPS agrega una capa de encriptación para proteger esos datos.

HTTP / HTTPS

Un request en red es el proceso completo que ocurre cuando el navegador pide un recurso a un servidor, desde la resolución DNS hasta recibir la respuesta.

Requests en red

Técnicas para que tu sitio web aparezca en los primeros resultados de los buscadores.

Pequeños archivos de datos que el navegador almacena para recordar información entre visitas.

Cookies

Un mecanismo de seguridad que controla qué dominios pueden acceder a los recursos de tu servidor.

CORS

La UI es el conjunto de elementos visuales e interactivos que permiten a una persona usar una aplicación.

UI (Interfaz de usuario)

La UX es la percepción general que tiene una persona al usar una aplicación, abarcando facilidad de uso, eficiencia y satisfacción.

UX (Experiencia de usuario)

Los formularios son el principal mecanismo que tienen las aplicaciones para recibir información del usuario.

Formularios

La navegación es el sistema que permite al usuario moverse entre las distintas secciones y páginas de una aplicación.

Navegación

El feedback son las señales visuales y mensajes que una aplicación usa para comunicarle al usuario qué está pasando en cada momento.

Feedback

Piezas reutilizables e independientes que conforman la interfaz de una aplicación.

Componentes

Técnicas para que una interfaz se adapte a cualquier tamaño de pantalla.

Responsive design

Prácticas para hacer que una aplicación sea usable por todas las personas, incluyendo aquellas con discapacidades.

Accesibilidad (a11y)

Transiciones y movimientos visuales que mejoran la experiencia del usuario en una interfaz.

Animaciones

Una interfaz que permite a dos aplicaciones comunicarse entre sí

El modelo de comunicación donde un cliente envía un pedido (request) y el servidor devuelve una respuesta (response).

Request / Response

Un mecanismo donde un servidor envía automáticamente datos a otro sistema cuando ocurre un evento, sin que el otro tenga que preguntar.

Webhooks

El proceso de conectar tu aplicación con servicios y plataformas externas para aprovechar funcionalidades que ya existen.

Integraciones

Un lenguaje de consultas para APIs que permite pedir exactamente los datos que necesitás.

GraphQL

Un protocolo de comunicación de alto rendimiento para conectar servicios entre sí.

gRPC

Un mecanismo para que el servidor envíe actualizaciones al cliente en tiempo real a través de HTTP.

SSE (Server-Sent Events)

Un sistema organizado para almacenar, gestionar y recuperar información

Base de datos

La capacidad de almacenar datos de forma duradera para que sobrevivan al cierre de la aplicación o del servidor.

Persistencia

Una capa de almacenamiento temporal que guarda datos frecuentemente usados para acelerar su acceso.

Cache

Una técnica de bases de datos que crea estructuras auxiliares para encontrar datos mucho más rápido sin recorrer toda la tabla.

Indexación

Scripts que modifican la estructura de la base de datos de forma controlada y reversible.

Migraciones

Una herramienta que permite interactuar con la base de datos usando objetos en vez de SQL.

Copias de seguridad de los datos para poder recuperarlos en caso de pérdida o error.

Backups

Una técnica para dividir grandes conjuntos de datos en páginas más pequeñas y manejables.

Paginación

El proceso de verificar la identidad de un usuario en una aplicación

Autenticación

El proceso de determinar qué acciones o recursos tiene permitido acceder un usuario ya autenticado.

Autorización

El mecanismo que permite a una aplicación recordar que un usuario ya inició sesión mientras navega entre páginas.

Sesiones

El conjunto de funcionalidades que permiten a los usuarios crear, modificar y eliminar sus cuentas dentro de una aplicación.

Gestión de cuentas

Un protocolo que permite a los usuarios iniciar sesión con sus cuentas de Google, GitHub u otros servicios.

OAuth

Un sistema para controlar qué puede hacer cada usuario dentro de una aplicación.

Roles y permisos

El proceso de guiar a un usuario nuevo para que entienda y empiece a usar tu aplicación.

Onboarding

Cómo y dónde se guardan los archivos que sube o genera una aplicación

Almacenamiento de archivos

Cómo controlar quién puede acceder a los archivos almacenados en tu aplicación

URLs públicas y privadas

Una red de servidores distribuidos que acelera la entrega de archivos a usuarios en todo el mundo

Técnicas para reducir el tamaño de archivos y datos para transferirlos más rápido.

Compresión

Técnicas para servir imágenes de forma eficiente sin sacrificar calidad visual.

Imágenes y optimización

Un modelo de ejecución donde cada operación espera a que la anterior termine antes de continuar

Procesamiento síncrono

Un modelo de ejecución donde las tareas se inician sin esperar a que las anteriores terminen

Procesamiento asíncrono

Un sistema que organiza y distribuye tareas pendientes para que se procesen en orden

Colas de tareas

Procesos que se ejecutan en segundo plano para realizar tareas sin afectar la experiencia del usuario

Workers

Tareas que se ejecutan automáticamente en horarios o intervalos definidos

Jobs programados

Un mecanismo para limitar la cantidad de peticiones que un cliente puede hacer en un período de tiempo.

Rate limiting

Procesamiento de grandes volúmenes de datos en lotes en vez de uno por uno.

Batch processing

La capacidad de un programa de manejar múltiples tareas al mismo tiempo.

Concurrencia

Señales que emite una aplicación cuando algo sucede, permitiendo que otras partes reaccionen

Eventos

Un protocolo que mantiene una conexión abierta entre el cliente y el servidor para comunicación bidireccional en tiempo real

WebSockets

Una técnica para enviar datos de forma continua sin esperar a que todo esté listo

Streaming

Mecanismos que usa una aplicación para avisar al usuario que algo importante ocurrió

Notificaciones

Un monolito es una arquitectura de software donde toda la aplicación vive en un único código base y se despliega como una sola unidad.

Monolito

Los microservicios son una arquitectura donde la aplicación se divide en servicios pequeños e independientes que se comunican entre sí.

Servicios

La modularidad es el principio de organizar el código en partes independientes y reutilizables, cada una con una responsabilidad clara.

Modularidad

Las dependencias son paquetes o módulos externos que tu proyecto necesita para funcionar.

Dependencias

Un patrón de arquitectura donde la aplicación se divide en servicios pequeños e independientes.

Microservicios

Un punto de entrada único que gestiona todas las peticiones a los distintos servicios de una aplicación.

API Gateway

Un patrón donde cada cambio en la aplicación se registra como un evento inmutable.

Event sourcing

Soluciones probadas a problemas comunes de diseño de software.

Design patterns

Un servidor es una computadora que almacena y ejecuta aplicaciones para que los usuarios puedan acceder a ellas.

Servidores

El deploy es el proceso de publicar una aplicación para que los usuarios puedan acceder a ella.

Deploy

La escalabilidad es la capacidad de una aplicación para manejar más carga de trabajo sin perder rendimiento.

Escalabilidad

Los logs son registros de eventos que genera una aplicación para que los desarrolladores puedan entender qué pasó y cuándo.

Logs

El monitoreo es la práctica de observar continuamente una aplicación para detectar problemas antes de que afecten a los usuarios.

Monitoreo

Una tecnología que empaqueta una aplicación con todo lo que necesita para funcionar en cualquier lugar.

Contenedores (Docker)

Un componente que distribuye el tráfico entrante entre varios servidores para evitar sobrecarga.

Load balancer

Protocolos de seguridad que cifran la comunicación entre el navegador y el servidor.

SSL/TLS

Un repositorio es el lugar donde se almacena todo el código fuente de un proyecto junto con su historial de cambios.

Repositorio

El versionado es el proceso de registrar y gestionar los cambios que se hacen en el código a lo largo del tiempo.

Versionado

Una branch (rama) es una línea de desarrollo independiente que permite trabajar en cambios sin afectar el código principal.

Branch

Un commit es una foto del estado de tu código en un momento específico, acompañada de un mensaje que describe qué se cambió.

Commit

Un pull request es una solicitud para incorporar los cambios de una rama al código principal, permitiendo revisión y discusión antes del merge.

Pull Request

Un merge es la operación de unir los cambios de una rama con otra, combinando el trabajo de diferentes líneas de desarrollo.

Merge

El control de cambios es el conjunto de prácticas y herramientas para rastrear qué se modificó en el código, quién lo hizo y cuándo.

Control de cambios

La colaboración en código es el conjunto de prácticas y flujos de trabajo que permiten que varias personas trabajen en el mismo proyecto sin pisarse.

Colaboración

El testing es el proceso de verificar que el software funciona como se espera antes de que llegue a los usuarios.

Testing

QA (Quality Assurance) es el proceso sistemático de asegurar que un producto de software cumple con los estándares de calidad antes de llegar a los usuarios.

Un bug es un error en el software que hace que se comporte de forma inesperada o incorrecta.

Bugs

El testing automatizado consiste en escribir código que verifica automáticamente que tu software funciona correctamente.

Testing automatizado

El A/B testing es una técnica para comparar dos versiones de algo y determinar cuál funciona mejor con datos reales.

A/B Testing

Una técnica de testing que simula dependencias externas para probar código de forma aislada.

Mocking

Pruebas que verifican que múltiples partes de la aplicación funcionan correctamente juntas.

Tests de integración

Una métrica que indica qué porcentaje del código está cubierto por tests automatizados.

Coverage

Un workflow es una secuencia de pasos automatizados que se ejecutan para completar un proceso.

Workflows

Un pipeline es una cadena de tareas que se ejecutan en secuencia, donde la salida de una etapa es la entrada de la siguiente.

Pipelines

Un trigger es un evento o condición que dispara automáticamente la ejecución de una acción o proceso.

Triggers

Prácticas de integración continua y deploy continuo que automatizan el camino del código a producción.

CI/CD

¿Qué es un A/B test? Un A/B test es un experimento donde mostrás dos versiones diferentes de algo a distintos grupos de usuarios para ver cuál funciona mejor. Por ejemplo, imaginá que tenés un botón de "Comprar" en tu tienda online. La versión A es verde y dice "Comprar ahora", la versión B es azul y dice "Agregar al carrito". Mostrás cada versión al 50% de los usuarios y medís cuál genera más ventas. Así dejás que los datos decidan, en lugar de discutir opiniones en una reunión.  ¿Cómo funciona? El proceso de un A/B test tiene pasos bien definidos: 1. Hipótesis: definís qué querés probar y por qué. "Creemos que un botón más grande va a aumentar las conversiones." 2. Variantes: creás las versiones A = control, B = variante. Puede haber más de dos variantes. 3. Segmentación: dividís el tráfico de usuarios de forma aleatoria entre las variantes. 4. Medición: dejás correr el experimento recolectando datos con eventos de analytics/eventosanalytics. 5. Análisis: evaluás los resultados y decidís si hay un ganador.  Feature flags: la herramienta detrás del A/B testing Para poder mostrar distintas versiones a distintos usuarios, se usan feature flags banderas de funcionalidad. Son configuraciones que te permiten activar o desactivar funcionalidades sin hacer un nuevo deploy. Herramientas como LaunchDarkly, Unleash o incluso una configuración simple en tu backend te permiten decir "al usuario X mostrale la versión A, al usuario Y la versión B".  Significancia estadística Acá viene la parte que muchos ignoran: no alcanza con que una variante tenga "más clics" que la otra. Necesitás que la diferencia sea estadísticamente significativa, es decir, que no sea simplemente producto del azar. Si solo 20 personas vieron tu test, la diferencia puede ser casualidad. Generalmente necesitás cientos o miles de usuarios para sacar conclusiones confiables. Herramientas como Optimizely o VWO calculan esto automáticamente y te dicen cuándo podés confiar en los resultados.  Optimización de conversiones El A/B testing es una pieza clave de la optimización de conversiones CRO, Conversion Rate Optimization: el proceso de mejorar el porcentaje de usuarios que completan una acción deseada. Junto con el análisis de funnels/funnels y las métricas/metricas de producto, te permite mejorar tu app de forma incremental y basada en datos. No se trata de rediseñar todo de una vez, sino de hacer cambios chicos, medirlos y quedarte con lo que funciona. Un botón acá, un texto allá, un cambio en el flujo de checkout. Cada mejora chica se acumula con el tiempo.

Una app para todas las personas La accesibilidad abreviada como a11y, porque hay 11 letras entre la "a" y la "y" de "accessibility" es el conjunto de prácticas que garantizan que cualquier persona pueda usar tu aplicación, incluyendo personas con discapacidades visuales, auditivas, motrices o cognitivas. No es un feature opcional ni un "nice to have": es parte fundamental de una buena experiencia de usuario/ux.  HTML semántico: la base de todo La herramienta más poderosa para la accesibilidad es usar el HTML correcto. Los lectores de pantalla software que lee en voz alta lo que hay en pantalla para personas ciegas dependen de las etiquetas HTML para entender la estructura de la página: La diferencia es enorme. Un <button es navegable con teclado, anunciado como botón por el lector de pantalla, y activable con Enter o Espacio. Un <div no hace nada de eso por sí solo.  Atributos ARIA Cuando el HTML semántico no alcanza, existen los atributos ARIA Accessible Rich Internet Applications. Le dan información extra a las tecnologías asistivas: Sin el arialabel, el lector de pantalla no sabría qué hace ese botón con solo un ícono. La regla general: usá HTML semántico primero, y ARIA solo cuando sea necesario.  Navegación por teclado Muchas personas no usan mouse: navegan con el teclado usando Tab para moverse entre elementos, Enter para activar botones y Escape para cerrar modales. Tu app tiene que funcionar completamente con teclado. Esto significa:  Todos los elementos interactivos deben ser enfocables.  El orden de tabulación debe ser lógico.  El foco debe ser visible nunca pongás outline: none sin un reemplazo.  Contraste y contenido visual El texto tiene que tener suficiente contraste con el fondo para que personas con baja visión puedan leerlo. La relación mínima recomendada es de 4.5:1 para texto normal. Además, toda imagen que transmita información necesita un texto alternativo:  Por qué deberías empezar ahora La accesibilidad no es solo un tema ético, aunque ya eso debería alcanzar. Mejora la interfaz/ui para todos: los subtítulos ayudan a quien ve un video sin sonido, el buen contraste ayuda a quien usa el celular bajo el sol, la navegación por teclado ayuda a quien tiene el mouse roto. Además, en muchos países es un requerimiento legal. Hacé de la accesibilidad un hábito desde el primer formulario/formularios que construyas, no algo que se "agrega después".

¿Qué es un agente? Un agente de IA es un programa que va más allá de simplemente responder preguntas: puede razonar, decidir qué hacer y ejecutar acciones por su cuenta. Mientras que un modelo/modelos normal recibe un prompt/prompts y devuelve una respuesta, un agente puede analizar la situación, elegir qué herramienta usar, ejecutarla, ver el resultado y decidir el siguiente paso. Es como la diferencia entre un asistente que contesta preguntas y uno que además puede mandarte mails, reservarte turnos y hacer compras.  ¿Cómo funciona un agente? El agente opera en un loop ciclo continuo. En cada iteración: 1. Observa: Recibe información del entorno o del usuario. 2. Piensa: Usa un LLM modelo de lenguaje, como GPT o Claude para razonar sobre qué hacer. 3. Actúa: Ejecuta una herramienta o acción. 4. Evalúa: Analiza el resultado y decide si terminó o necesita otro paso.  Tool use: el superpoder de los agentes Lo que hace poderosos a los agentes es el tool use uso de herramientas. Le definís al modelo un conjunto de funciones que puede llamar, como buscar en una base de datos, hacer un request HTTP, leer un archivo o ejecutar código. El modelo decide cuándo y cómo usar cada herramienta según lo que necesite. Esto conecta la capacidad de razonamiento del modelo con acciones concretas en el mundo real.  Ejemplos de agentes Los agentes ya están en todos lados:  Agentes de código: Como Claude Code o GitHub Copilot agent, que pueden leer tu código, editarlo, correr tests y hacer commits.  Asistentes de atención al cliente: Que buscan en la base de datos del cliente, consultan el historial de pedidos y resuelven problemas.  Agentes de investigación: Que buscan información en múltiples fuentes, la sintetizan y generan reportes.  Automatizaciones inteligentes: Que combinan agentes con workflows/workflows para ejecutar procesos de negocio complejos.  Consideraciones importantes Los agentes son potentes pero hay que diseñarlos con cuidado. Cada paso del loop implica una llamada al modelo que consume recursos y plata, así que pueden ser costosos. También necesitás manejar errores: ¿qué pasa si una herramienta falla? ¿Y si el agente entra en un loop infinito? Definir buenos límites, timeouts y mecanismos de fallback es clave para que un agente funcione bien en producción.

Cuando un usuario sube una foto de perfil, un PDF o cualquier otro archivo a tu aplicación, ese archivo tiene que guardarse en algún lugar. Pero, ¿dónde? A diferencia de los datos estructurados como nombres o emails que van a una base de datos/basededatos, los archivos se almacenan de forma diferente porque suelen ser mucho más pesados.  Archivos vs base de datos La base de datos/basededatos es ideal para guardar datos pequeños y estructurados: textos, números, fechas. Pero no es buena idea guardar archivos grandes directamente ahí. Imaginá meter una imagen de 5 MB en una tabla de PostgreSQL — la base se volvería lenta y enorme. Lo que se hace en la práctica es guardar el archivo en un servicio de almacenamiento y en la base de datos solo guardar la referencia la URL o ruta del archivo.  Almacenamiento en la nube Los servicios más usados para guardar archivos son:  Amazon S3 Simple Storage Service: el más popular, ofrece almacenamiento prácticamente ilimitado  Google Cloud Storage GCS: la alternativa de Google con integración con sus otros servicios  Azure Blob Storage: la opción de Microsoft Estos servicios organizan los archivos en buckets contenedores. Pensá en un bucket como una carpeta raíz donde metés todos los archivos de tu aplicación. Cada archivo tiene una key clave que funciona como su ruta dentro del bucket.  Local vs remoto Durante el desarrollo, es común guardar archivos en el disco local del servidor. Pero en producción, esto trae problemas: si tenés varios servidores, un archivo subido a uno no está disponible en los otros. Además, si el servidor se cae, perdés los archivos. Por eso en producción se usa almacenamiento remoto en la nube. Los archivos quedan accesibles desde cualquier servidor, tienen respaldo automático, y podés servir los archivos a través de un CDN/cdn para que carguen rápido en todo el mundo. El acceso se controla con URLs públicas o privadas/urlspublicasprivadas según la necesidad.  Cuándo usar qué  Base de datos: datos pequeños y estructurados texto, números, JSON pequeño  Almacenamiento en la nube: archivos binarios imágenes, videos, PDFs, backups  Disco local: solo para desarrollo o archivos temporales durante el procesamiento

La estructura de un proyecto Cuando abrís un proyecto de código por primera vez, ves un montón de archivos y carpetas con nombres que parecen crípticos. Pero cada uno tiene un propósito claro. Esta guía te explica los más comunes para que puedas orientarte en cualquier proyecto de código. Si te sirve una imagen mental, un proyecto web con Next.js y Node.js suele verse más o menos así: No hace falta memorizar este árbol. Lo importante es entender la lógica: pages/ define rutas, components/ guarda piezas reutilizables, lib/ concentra lógica compartida y public/ contiene archivos estáticos.  Componentes comunes de interfaz Estos son nombres que vas a encontrar una y otra vez en la carpeta components/ o src/:  Nombre en código  Qué es  Qué hace   Header / Navbar  Barra superior  Navegación principal, logo, menú, botones de acción   Footer  Pie de página  Links secundarios, copyright, redes sociales   Sidebar  Barra lateral  Navegación secundaria, filtros, menú colapsable   Layout  Estructura base  Envuelve todas las páginas con header, footer, sidebar   Modal / Dialog  Ventana emergente  Confirmaciones, formularios, alertas que aparecen encima del contenido   Card  Tarjeta  Bloque visual que agrupa información producto, artículo, usuario   Button  Botón  Acción clickeable con variantes primary, secondary, danger   Input / TextField  Campo de texto  Donde el usuario escribe datos   Form  Formulario  Agrupa inputs y maneja el envío de datos   Avatar  Imagen de perfil  Foto circular del usuario   Badge  Etiqueta  Indicador pequeño conteo de notificaciones, estado   Tooltip  Texto emergente  Información extra al pasar el mouse sobre algo   Dropdown / Select  Menú desplegable  Lista de opciones que se abre al hacer click   Tabs  Pestañas  Navegación entre secciones dentro de una misma vista   Breadcrumb  Migas de pan  Muestra la ruta de navegación Home  Productos  Detalle   Spinner / Loader  Indicador de carga  Animación mientras se carga contenido   Toast / Snackbar  Notificación temporal  Mensaje que aparece brevemente y desaparece solo   Pagination  Paginador  Controles para navegar entre páginas de resultados   Archivos de configuración En la raíz del proyecto vas a encontrar archivos que no son código de la app, sino configuración:  Archivo  Para qué sirve   package.json  Lista de dependencias/dependencias y scripts del proyecto   .env / .env.local  Variables de entorno/variablesdeentorno claves de API, configuración secreta   README.md  Documentación del proyecto — qué es, cómo instalarlo, cómo usarlo   .gitignore  Archivos que Git debe ignorar nodemodules, .env, etc.   tsconfig.json  Configuración de TypeScript   next.config.js  Configuración de Next.js   tailwind.config.js  Configuración de Tailwind CSS   Dockerfile  Instrucciones para crear un contenedor/contenedores   .eslintrc  Reglas de estilo de código   Carpetas típicas  Carpeta  Qué contiene   src/  Todo el código fuente de la aplicación   components/  Componentes reutilizables de interfaz   pages/ o app/  Las rutas/páginas de la aplicación   api/  Endpoints del backend/servidorbackend   lib/ o utils/  Funciones auxiliares y lógica compartida   hooks/  Hooks personalizados lógica reutilizable en React   contexts/  Contextos de React para estado/estado global   styles/  Archivos CSS y estilos   public/  Archivos estáticos imágenes, favicons, fuentes   tests/ o tests/  Tests/testing del proyecto   nodemodules/  Dependencias instaladas no se toca manualmente   ¿Por qué importa? Cuando le pedís a una AI que te ayude con tu proyecto, saber cómo se llaman las cosas hace toda la diferencia. No es lo mismo decir "quiero un cosito arriba" que "necesito un Header con navegación y un botón de dark mode". Los nombres son un lenguaje compartido entre programadores — y ahora también entre vos y tu modelo de AI.

Movimiento con propósito Las animaciones en una interfaz/ui no son adornos: son una herramienta de comunicación. Un botón que cambia de color al pasar el mouse, un menú que se desliza al abrirse, una notificación que aparece suavemente en lugar de "flashear" de golpe. Todo eso le da al usuario pistas sobre qué está pasando y hace que la experiencia/ux se sienta más fluida y natural.  Transiciones CSS: el primer paso La forma más simple de animar es con transiciones. Le decís al navegador "cuando esta propiedad cambie, hacelo gradualmente en vez de instantáneamente": Con solo agregar transition, el botón ya no salta bruscamente de un color a otro: se desliza suavemente. La propiedad transform con scale lo agranda levemente, dando una sensación táctil muy satisfactoria.  Animaciones con keyframes: control total Cuando necesitás movimientos más complejos, usás @keyframes para definir una secuencia de pasos: Esta animación hace que una notificación aparezca deslizándose hacia abajo mientras se hace visible. Es mucho más expresiva que un simple "ahora se ve, antes no se veía".  Cuándo animar y cuándo no No todo necesita animación. Usá movimiento cuando tenga un propósito claro:  Feedback/feedback: un botón que reacciona al toque confirma que registró la acción.  Atención: una animación sutil puede guiar la vista hacia algo importante, como una notificación nueva.  Transiciones de contexto: al cambiar de pantalla o abrir un modal, la animación ayuda a entender de dónde viene y a dónde va la información. Evitá animaciones puramente decorativas que no aportan información. Si algo se mueve sin razón, distrae en vez de ayudar.  Rendimiento: que no se trabe Una animación que se ve entrecortada es peor que no tener animación. Para que sean fluidas 60 fotogramas por segundo, seguí estas reglas:  Animá solo transform y opacity: estas propiedades las maneja la GPU directamente, sin recalcular el layout de la página.  Evitá animar width, height, margin o top: fuerzan al navegador a recalcular posiciones de todos los elementos.  Usá willchange con cuidado: le avisa al navegador que un elemento va a animarse, permitiéndole optimizar.  Respetá las preferencias del usuario Algunas personas sufren mareos o molestias con el movimiento excesivo. Los sistemas operativos permiten activar una opción de "reducir movimiento", y vos podés respetar esa preferencia: Esto desactiva prácticamente todas las animaciones para quienes lo necesiten. Es un detalle chico que marca una gran diferencia en la experiencia/ux de esas personas.

¿Qué es un API Gateway? Un API Gateway es un servidor que actúa como punto de entrada único para todas las peticiones de los clientes hacia tus microservicios/microservicios. En vez de que el frontend tenga que saber la dirección de cada servicio y hablar con cada uno por separado, le habla a un solo lugar: el gateway. Este se encarga de redirigir cada petición al servicio correcto.  ¿Por qué necesitás un gateway? Sin un gateway, el cliente necesita conocer cada servicio: Imaginá una app móvil que necesita datos de usuarios, productos y pedidos. Sin gateway, haría tres requests a tres URLs distintas. Con gateway, hace todo a través de api.miapp.com y el gateway resuelve el ruteo internamente.  Responsabilidades del gateway Un API Gateway no solo rutea peticiones. Suele encargarse de varias cosas más:  Ruteo: dirige /api/users/ al servicio de usuarios, /api/orders/ al de pedidos.  Autenticación: verifica el token de autenticación/autenticacion una sola vez en el gateway, en vez de que cada servicio lo haga por separado.  Rate limiting: limita la cantidad de requests por cliente para proteger los servicios.  Logging y métricas: registra todas las peticiones en un punto centralizado.  Transformación: puede combinar respuestas de varios servicios en una sola, o adaptar el formato.  SSL termination: maneja la conexión segura HTTPS en el gateway y usa HTTP simple internamente entre servicios, simplificando la configuración.  Opciones populares  nginx / OpenResty: liviano, rápido, muy usado como reverse proxy un intermediario que recibe las peticiones y las reenvía al servicio correcto y gateway.  Kong: gateway open source basado en nginx, con plugins para auth, rate limiting, logging.  AWS API Gateway: servicio managed de Amazon, ideal si ya estás en AWS.  Traefik: se integra muy bien con contenedores y Kubernetes.  Express Gateway: basado en Node.js, fácil de extender si tu stack es JavaScript.  El patrón BFF Backend for Frontend Un patrón interesante es el BFF Backend for Frontend: en vez de tener un solo gateway genérico, tenés uno específico por tipo de cliente. Un BFF para la app móvil que devuelve respuestas livianas con menos datos, otro para la web que incluye más información. Cada BFF conoce las necesidades de su cliente y adapta las respuestas de los servicios/servicios internos. El API Gateway es una pieza clave en una arquitectura de microservicios. Simplifica la vida del frontend, centraliza preocupaciones transversales como autenticación/autenticacion y logging, y te da un punto de control sobre todo el tráfico que entra a tu sistema. Pero no abuses: mantené el gateway liviano y evitá meter lógica de negocio ahí. Su trabajo es dirigir tráfico, no procesarlo.

Ruta para tu idea