WEBVTT 00:00:00.520 --> 00:00:06.900 Listo para 10 días de Microsoft 365, Copilot, IA, Azure y las personas que están dando forma al futuro del trabajo, 00:00:07.860 --> 00:00:11.480 este enero, M365 con regresa y venimos con más fuerza. 00:00:11.640 --> 00:00:12.200 Y venimos fuerza. 00:00:12.860 --> 00:00:18.140 Una hacia nosotros para sesiones en vivo, demostraciones reales y conocimientos prácticos de MVP y expertos de la industria de todo el mundo. 00:00:18.720 --> 00:00:21.280 Sin diapositivas genéricas, sin palabras de moda interminable. 00:00:21.920 --> 00:00:23.500 Estamos abordando los desafíos reales. 00:00:23.840 --> 00:00:28.620 Copilot Studio, agentes de IA, Fabric, seguridad, gobernanza y automatización. 00:00:28.620 --> 00:00:34.400 Ya sea usted un profesional de TI, desarrollador o líder empresarial, hay sesiones diseñadas para usted. 00:00:35.440 --> 00:00:40.140 Con 10 días completos, puede explorar múltiples tecnologías y conectar con una comunidad global. 00:00:40.900 --> 00:00:44.260 Véalo en vivo y lleve perspectivas prácticas de vuelta a su organización. 00:00:45.160 --> 00:00:48.920 Enero de 2027. 10 días. Una comunidad de Microsoft. 00:00:49.400 --> 00:00:50.640 Las inscripciones ya están abiertas. 00:00:51.860 --> 00:00:55.640 Vaya a M365.com.net y asegure su lugar hoy mismo. 00:00:55.640 --> 00:00:58.620 Eso es M365.com.net. 00:01:00.100 --> 00:01:03.280 Únese ahora en M365.com.net y nos veremos. 00:01:03.660 --> 00:01:04.640 En vivo en enero. 00:01:05.300 --> 00:01:06.400 Usted cree una aplicación que funciona. 00:01:06.620 --> 00:01:10.720 Luego añade otro servicio y otro y de repente, dirigir el tráfico entre ellos se convierte en una pesadilla. 00:01:11.200 --> 00:01:12.740 Entonces, ¿qué es exactamente una puerta de enlace API? 00:01:12.820 --> 00:01:13.760 Realmente necesita una. 00:01:14.100 --> 00:01:17.720 Al final de este episodio, entenderá qué hace una puerta de enlace API por un. 00:01:18.040 --> 00:01:21.940 ¿Qué resuelve el caos de gestionar múltiples servicios y cómo saber si necesita una? 00:01:21.940 --> 00:01:24.240 Comencemos con el problema. 00:01:24.520 --> 00:01:26.460 Luego las partes y cómo encajan todas juntas. 00:01:27.500 --> 00:01:28.120 El problema. 00:01:28.420 --> 00:01:28.980 Demasiada fuerte. 00:01:29.780 --> 00:01:31.580 Imagine que dirige una empresa que está creciendo y rápidamente. 00:01:32.400 --> 00:01:36.500 Tiene un equipo de ventas en el tercer piso, contabilidad en el sótano y TI en el ala trasera. 00:01:37.200 --> 00:01:42.500 Ahora, imagine que cada uno de esos departamentos tiene su propia puerta de entrada, su propio número de teléfono y su propio guardia de seguridad que no habla con los demás. 00:01:43.460 --> 00:01:45.700 Si usted es un visitante que intenta entregar un paquete, buena suerte. 00:01:46.360 --> 00:01:50.280 Tiene que saber exactamente qué puerta usar, con qué guardia hablar y qué hacer cuando ese guardia esté en su descanso. 00:01:50.280 --> 00:01:55.760 Eso es exactamente lo que sucede cuando su aplicación tiene múltiples servicios de backend y cada cliente llama a cada uno directamente. 00:01:56.260 --> 00:02:04.120 El cliente, ya sea una aplicación móvil, un sitio web u otro servicio, tiene que saber dónde reside cada servicio, cómo autenticarse con cada uno y qué hacer cuando algo falla. 00:02:05.100 --> 00:02:09.220 Cada servicio tiene que manejar su propia seguridad, su propio límite de tasa y su propio manejo de errores. 00:02:09.700 --> 00:02:12.540 Eso es trabajo duplicado y es fácil que las cosas se vuelven inconsistentes. 00:02:12.880 --> 00:02:13.460 Tomemos un banco. 00:02:13.820 --> 00:02:16.540 Tiene servicios separados para cuentas, pagos, préstamos y detección de fraude. 00:02:17.220 --> 00:02:19.120 De la forma antigua, cada uno se expone directamente. 00:02:19.120 --> 00:02:25.060 Una aplicación móvil tiene que conocer cuatro URLs diferentes, cuatro métodos de autenticación distintos y cuatro formas diferentes de manejar errores. 00:02:25.720 --> 00:02:29.000 Eso es cuatro veces la complejidad y cuatro veces la superficie para que algo salga mal. 00:02:29.100 --> 00:02:31.740 Y ese es el caos que una API Gateway está diseñada para solucionar. 00:02:32.520 --> 00:02:33.380 Entonces, ¿cuál es la solución? 00:02:34.020 --> 00:02:34.800 ¿Qué es una API Gateway? 00:02:35.800 --> 00:02:37.780 Imagina una API Gateway como la recepción de un hotel. 00:02:38.660 --> 00:02:42.840 Cuando entras no necesitas saber en qué piso está el servicio de limpieza, dónde está la cocina o cómo contactar. 00:02:42.980 --> 00:02:44.120 Al equipo de mantenimiento. 00:02:44.740 --> 00:02:45.760 Solo vas a la recepción. 00:02:45.940 --> 00:02:48.140 Les dices lo que necesitas y ellos se encargan del resto. 00:02:48.140 --> 00:02:54.140 Ellos dirigen tu solicitud de persona indicada, verifican si tienes permiso para estar allí e incluso resuelven solicitudes básicas por su cuenta. 00:02:54.680 --> 00:02:56.640 Una API Gateway hace lo mismo para tu software. 00:02:57.420 --> 00:03:00.620 Es un punto de entrada único que se sitúa entre tus clientes y tus servicios de backend. 00:03:01.800 --> 00:03:03.440 Cada solicitud pasa primero por la Gateway. 00:03:03.800 --> 00:03:07.260 Ella decide a dónde enviarla si permitirla hay que enviar de vuelta. 00:03:07.260 --> 00:03:09.020 Ahora bien, esta no es una idea nueva. 00:03:09.520 --> 00:03:13.720 Los proxys inversos existen desde hace décadas, pero la API Gateway se ha vuelto esencial con los microservicios. 00:03:14.420 --> 00:03:17.100 Cuando divides tu aplicación en muchos servicios pequeños, de repente tiene mucha puerta. 00:03:17.520 --> 00:03:18.920 La Gateway te ofrece una única puerta principal. 00:03:19.260 --> 00:03:21.940 En el mundo de Azure, Azure API Management es la plataforma completa. 00:03:22.300 --> 00:03:24.520 Y la Gateway es el componente central que gestiona el tráfico. 00:03:25.320 --> 00:03:26.460 El patrón es el mismo en todas partes. 00:03:26.980 --> 00:03:28.360 Un punto de entrada contra lo centralizado. 00:03:29.040 --> 00:03:30.000 Cada solicitud ingresa. 00:03:30.380 --> 00:03:33.140 La Gateway la verifica, la enruta y envía la respuesta de vuelta. 00:03:33.580 --> 00:03:35.540 El cliente nunca habla directamente con tus servicios de backend. 00:03:35.980 --> 00:03:36.740 Solo habla con la Gateway. 00:03:37.380 --> 00:03:38.720 Analicemos lo que eso significa realmente. 00:03:39.580 --> 00:03:41.500 Comenzando con la tarea más básica, el enrutamiento. 00:03:42.840 --> 00:03:44.080 Parte 1. Enrutamiento de tráfico. 00:03:44.640 --> 00:03:47.120 La tarea más sencilla de una API Gateway es el enrutamiento. 00:03:47.300 --> 00:03:49.060 Dirigir cada solicitud al servicio correcto. 00:03:49.480 --> 00:03:50.660 Piensa en cómo funciona un sitio web. 00:03:50.660 --> 00:03:53.140 Cuando haces clic en un enlace, tu navegador envía una solicitud. 00:03:53.300 --> 00:03:54.320 Esa solicitud tiene una ruta. 00:03:54.620 --> 00:03:57.300 Si la ruta es Users, la Gateway sabe enviarla al servicio de usuarios. 00:03:57.300 --> 00:03:59.340 Si es Orders, va al servicio de pedido. 00:04:00.140 --> 00:04:03.440 La Gateway lee la ruta, determina a dónde debe ir y la reenvía. 00:04:03.960 --> 00:04:06.780 Sin una Gateway, tus clientes tienen que conocer la URL de cada servicio. 00:04:07.120 --> 00:04:11.900 La aplicación móvil necesita la dirección del servicio de usuarios, del servicio de pedidos, del servicio de pagos y del servicio de... 00:04:11.900 --> 00:04:13.520 Son demasiadas URLs que gestionar. 00:04:14.120 --> 00:04:16.960 Si alguna de esas direcciones cambia, tienes que actualizar cada cliente. 00:04:17.340 --> 00:04:19.140 Con una puerta de enlace, los clientes solo conocen una URL. 00:04:19.600 --> 00:04:20.580 La dirección de la puerta de enlace. 00:04:20.780 --> 00:04:22.460 No les importa dónde residen realmente los servicios. 00:04:22.980 --> 00:04:25.740 Solo envía su solicitud a la puerta de enlace y ésta se encarga del resto. 00:04:25.740 --> 00:04:29.860 Este es uno de los casos de uso más comunes de una API Gateway, el enrutamiento basado en recursos. 00:04:30.180 --> 00:04:32.360 La investigación de Apache P6 lo señala explícitamente. 00:04:32.800 --> 00:04:37.380 Puedes enrutar según la ruta, el método HTTP, los encabezados o incluso la geolocalización del cliente. 00:04:37.640 --> 00:04:40.880 Si alguien en Europa envía una solicitud, puedes redirigirlo a un centro de datos europeo. 00:04:41.220 --> 00:04:46.020 Si alguien en EU envía una solicitud va a un centro de datos estadounidense, el cliente no sabe que nada de esto está ocurriendo. 00:04:46.480 --> 00:04:47.740 Simplemente recibe una respuesta rápida. 00:04:48.060 --> 00:04:49.240 El enrutamiento maneja el control de versión. 00:04:49.820 --> 00:04:51.520 Digamos que tienes una nueva versión de tu servicio de usuario. 00:04:51.520 --> 00:04:55.540 Los clientes antiguos siguen usando Barber One of Car Users y los nuevos Usambar Users. 00:04:56.160 --> 00:04:57.880 La puerta de enlace los dirige a diferentes backends. 00:04:58.400 --> 00:05:01.020 Los clientes antiguos siguen funcionando mientras lanzas la nueva versión. 00:05:01.500 --> 00:05:03.520 Puedes cambiar tu backend sin afectar a tus clientes. 00:05:04.160 --> 00:05:06.940 Eso es fundamental cuando gestionas una aplicación en vivo con usuarios reales. 00:05:07.480 --> 00:05:09.180 Piensa en una plataforma de comercio electrónico. 00:05:09.340 --> 00:05:12.920 Tiene servicios separados para el catálogo, el carrito, el pago y las cuentas de usuario. 00:05:13.640 --> 00:05:17.040 Sin una puerta de enlace, una aplicación móvil debe conocer cuatro URLs distintas. 00:05:17.040 --> 00:05:18.740 Pero una puerta de enlace solo conoce una. 00:05:19.060 --> 00:05:24.940 La puerta de enlace lee la ruta, catálogo, carrito, pago o cuenta y envía cada petición al servicio correcto. 00:05:25.220 --> 00:05:26.440 El enrutamiento simple es la parte fácil. 00:05:26.960 --> 00:05:28.760 La siguiente función es donde se vuelve realmente útil. 00:05:29.360 --> 00:05:30.700 Parte 2. Seguridad en la entrada. 00:05:31.600 --> 00:05:33.280 Cada llamada a la API debe ser verificada. 00:05:33.640 --> 00:05:34.620 ¿Quién está haciendo esta solicitud? 00:05:34.840 --> 00:05:35.940 ¿Tiene los permisos necesarios? 00:05:36.380 --> 00:05:39.220 Sin una puerta de enlace, cada servicio debe manejar su propia autenticación. 00:05:39.540 --> 00:05:41.640 Eso significa trabajo duplicado y es fácil cometer errores. 00:05:41.640 --> 00:05:47.840 Un servicio podría verificar los tokens correctamente, otro saltarse un paso y otro usar un método distinto, distinto. 00:05:48.180 --> 00:05:51.000 Terminas con una seguridad inconsistente en toda tu aplicación. 00:05:51.500 --> 00:05:52.180 Puerta de enlace cambia eso. 00:05:52.560 --> 00:05:54.960 Maneja la autenticación y autorización en lugar centralizado. 00:05:55.660 --> 00:05:59.220 Un punto para verificar, un punto para aplicar, un punto para actualizar cuando las políticas cambien. 00:05:59.500 --> 00:06:00.820 Esa es una de las mejores prácticas de seguridad. 00:06:01.200 --> 00:06:06.480 Valida claves API, JWTs, tokens o auth o certificados en cada solicitud individual. 00:06:07.400 --> 00:06:09.220 Cada solicitud pasa por la misma verificación. 00:06:09.520 --> 00:06:09.960 Inexcepción. 00:06:09.960 --> 00:06:12.220 La puerta de enlace también aplica reglas. 00:06:12.700 --> 00:06:15.080 Puedes decir, esta clave API solo puede llamar a los endpoints de lectura. 00:06:15.660 --> 00:06:18.840 O, este cliente solo puede acceder al servicio de catálogo, no al de pagos. 00:06:19.660 --> 00:06:22.960 Defines permisos granulares a nivel de puerta de enlace y se aplican automáticamente. 00:06:23.380 --> 00:06:25.680 Los servicios de backend nunca tienen que preocuparse por la autorización. 00:06:26.300 --> 00:06:28.420 Simplemente procesan la solicitud y devuelven los datos. 00:06:28.940 --> 00:06:29.420 Aquí está la cuestión. 00:06:29.860 --> 00:06:32.800 El gateway es el único lugar para revocar el acceso cuando algo sale mal. 00:06:33.340 --> 00:06:36.260 Si la clave API de un cliente se ve comprometida, la revocas en el gateway. 00:06:36.880 --> 00:06:37.600 Cambio, listo. 00:06:37.600 --> 00:06:40.080 No tienes que actualizar cada servicio ni reiniciar nada. 00:06:40.620 --> 00:06:42.820 La siguiente solicitud con esa clave es rechazada inmediatamente. 00:06:43.180 --> 00:06:44.000 Tomemos un ejemplo real. 00:06:44.260 --> 00:06:46.160 Un banco tiene un servicio de pagos y uno de facturación. 00:06:46.840 --> 00:06:49.400 Solo el servicio de pagos necesita acceso de escritura del sistema de facturación. 00:06:49.640 --> 00:06:50.580 El gateway aplica eso. 00:06:51.020 --> 00:06:54.980 Si un cliente intenta escribir en el sistema de facturación por un endpoint incorrecto, el gateway lo bloquea. 00:06:54.980 --> 00:06:57.280 El servicio de facturación ni siquiera verá solicitud. 00:06:57.660 --> 00:07:01.660 El gateway también puede soportar TLS mutuo e integración con WAF para una protección más profunda. 00:07:02.220 --> 00:07:04.100 Pero en esencia, es tu primera línea de defensa. 00:07:04.780 --> 00:07:07.840 La seguridad es una cosa, pero ¿qué pasa cuando llegan demasiadas solicitudes a la vez? 00:07:08.620 --> 00:07:09.180 Parte 3. 00:07:09.260 --> 00:07:10.040 Gestión de tráfico. 00:07:10.760 --> 00:07:13.560 ¿Qué sucede cuando 10.000 usuarios acceden a tu aplicación al mismo tiempo? 00:07:14.020 --> 00:07:19.800 Tal vez tienes una venta flash, un lanzamiento de producto se vuelve viral, o simplemente es un martes normal y todos decidieron iniciar sesión a la vez. 00:07:19.800 --> 00:07:26.160 Sin un gateway, tus servicios de backend reciben el impacto directamente y podrían colapsar, no lentamente, sino de golpe. 00:07:26.940 --> 00:07:28.180 Ahí es donde entra la gestión de tráfico. 00:07:28.880 --> 00:07:31.600 El gateway puede limitar cuántas solicitudes puede hacer cada cliente. 00:07:32.300 --> 00:07:34.480 La limitación de tasa y el estrangulamiento son funciones estándar. 00:07:34.780 --> 00:07:36.940 Tú estableces las reglas en el gateway y éste las aplica. 00:07:37.360 --> 00:07:39.040 Tus servicios de backend nunca sienten el pico de tal. 00:07:39.660 --> 00:07:42.620 Puedes establecer cuota por usuario, por clave API o por dirección IP. 00:07:43.160 --> 00:07:44.560 Digamos que tienes un nivel gratuito de tu app. 00:07:45.020 --> 00:07:46.860 Tus usuarios gratuitos obtienen 100 solicitudes por. 00:07:47.140 --> 00:07:48.360 Los usuarios premium obtienen 10. 00:07:48.360 --> 00:07:51.240 El gateway rastrea cada solicitud y aplica sus límites en la puerta. 00:07:51.960 --> 00:07:56.420 Un usuario gratuito alcanza su límite y el gateway envía un mensaje amable de intentar más tarde. 00:07:57.180 --> 00:07:59.340 Servicios de backend ni siquiera saben que hubo una solicitud. 00:07:59.760 --> 00:08:01.740 Siguen funcionando normalmente atendiendo a los clientes de backend. 00:08:02.400 --> 00:08:03.940 El gateway también maneja el balanceo de carga. 00:08:04.600 --> 00:08:08.820 Si tienes múltiples instancias del mismo servicio ejecutándose, el gateway reparte las solicitudes entre ellas. 00:08:09.220 --> 00:08:11.760 La instancia 1 recibe una solicitud, la instancia 2 recibe la siguiente. 00:08:11.900 --> 00:08:12.780 La instancia 3 la siguiente. 00:08:13.140 --> 00:08:13.720 Es automático. 00:08:14.260 --> 00:08:16.580 Y si una instancia falla, el gateway la dirige a otra. 00:08:16.580 --> 00:08:18.720 Los clientes nunca se enteran, simplemente en su respuesta. 00:08:19.580 --> 00:08:22.140 El balanceo de carga con chequeos de salud mantiene todo funcionando sin problema. 00:08:22.540 --> 00:08:24.920 El gateway hace ping a cada instancia para asegurarse de que esté activo. 00:08:25.260 --> 00:08:26.660 Si no lo está, deja de enviar tráfico allí. 00:08:27.220 --> 00:08:29.260 Esto es especialmente importante para APIs de alto tráfico. 00:08:29.920 --> 00:08:32.680 Sin el gateway, un pico de tráfico afecta a tus servicios directamente. 00:08:32.680 --> 00:08:39.700 Con el gateway, el pico llega primero al gateway, este lo absorbe, lo distribuye y protege a tus servicios de verse saturados. 00:08:40.580 --> 00:08:42.780 Bien, pero ¿qué pasa si los datos no llegan como deberían? 00:08:44.840 --> 00:08:46.320 Parte 4. Transformación de datos. 00:08:47.200 --> 00:08:50.160 A veces los datos que envía tu cliente no coinciden con lo que espera tu backend. 00:08:50.740 --> 00:08:53.520 Quizás el cliente envía JSON, pero tu backend solo entiende XML. 00:08:54.080 --> 00:08:55.580 Tal vez los nombres de los campos no coinciden. 00:08:55.840 --> 00:08:58.200 El cliente usa nombre y tu backend espera nombre. 00:08:59.220 --> 00:09:00.340 Estas discrepancias causan error. 00:09:00.800 --> 00:09:04.060 De la forma tradicional, tendrías que arreglar cada cliente o reescribir el backend. 00:09:05.100 --> 00:09:07.780 El gateway puede transformar los datos antes de que lleguen al backend. 00:09:08.360 --> 00:09:09.300 Piénsalo como un traductor. 00:09:09.660 --> 00:09:13.000 Se ubica en el medio y puede cambiar los datos al entrar, al salir o en ambos sentidos. 00:09:13.160 --> 00:09:15.520 Eso es la transformación de peticiones y respuestas en pocas palabras. 00:09:15.920 --> 00:09:16.980 Déjame darte un ejemplo real. 00:09:16.980 --> 00:09:18.940 Digamos que tienes un sistema heredado que espera XML. 00:09:19.580 --> 00:09:20.760 Ha estado funcionando por 15 años. 00:09:21.260 --> 00:09:21.720 Funciona bien. 00:09:22.080 --> 00:09:24.800 Pero ahora estás creando una aplicación móvil y las apps móviles hablan JSON. 00:09:25.400 --> 00:09:29.480 Sin un gateway tendrías que reescribir el sistema heredado o forzar a la app a enviar XML. 00:09:30.000 --> 00:09:31.540 Con un gateway no haces ninguna de las dos cosas. 00:09:31.740 --> 00:09:32.780 La aplicación móvil envía JSON. 00:09:33.140 --> 00:09:34.320 El gateway lo convierte en XML. 00:09:34.840 --> 00:09:35.940 El sistema recibe lo que espera. 00:09:36.560 --> 00:09:38.740 La aplicación móvil recibe una respuesta de vuelta ya en JSON. 00:09:39.160 --> 00:09:40.200 Nadie tuvo que reescribir nada. 00:09:40.620 --> 00:09:41.040 Eso es esto. 00:09:41.520 --> 00:09:45.580 El gateway también puede añadir o eliminar encabezados, cambiar URLs o enmascarar datos sensibles. 00:09:45.580 --> 00:09:48.140 Imagina que una respuesta incluye un número de tarjeta de cliente. 00:09:48.540 --> 00:09:49.840 No querrás que eso llegue al cliente. 00:09:50.340 --> 00:09:54.280 El gateway puede eliminarlo antes de que la respuesta salga o reemplazarlo por una versión de mascarada. 00:09:54.540 --> 00:09:55.560 El backend nunca tiene que cambiar. 00:09:56.100 --> 00:09:57.280 El gateway se encarga de... 00:09:57.280 --> 00:09:59.600 Esto es especialmente útil cuando modernizas sistemas antiguos. 00:09:59.860 --> 00:10:00.960 No tienes que reescribir el backend. 00:10:01.360 --> 00:10:02.740 No tienes que obligar a los clientes a cambiar. 00:10:03.360 --> 00:10:04.200 Solo cambias el gateway. 00:10:04.660 --> 00:10:06.320 Es como un traductor en una conferencia internacional. 00:10:06.840 --> 00:10:10.320 Todos hablan su propio idioma, pero el traductor asegura que todos entiendan. 00:10:10.640 --> 00:10:12.160 El gateway es ese traductor para tu software. 00:10:12.160 --> 00:10:15.460 Entonces, enrutamiento, seguridad, limitación, transformación es mucho. 00:10:15.900 --> 00:10:17.100 Pero no son cuatro cosas separadas. 00:10:17.460 --> 00:10:18.660 Déjame mostrarte cómo se conecta. 00:10:18.960 --> 00:10:19.740 Cómo se conecta todo. 00:10:20.220 --> 00:10:20.660 Que esté puro. 00:10:21.360 --> 00:10:22.780 Estos cuatro trabajos no están separados. 00:10:23.300 --> 00:10:26.240 Funcionan juntos en cada petición cada vez que llega una solicitud. 00:10:26.640 --> 00:10:27.980 El gateway verifica la autenticación. 00:10:28.520 --> 00:10:29.460 Válida el límite de velocidad. 00:10:29.960 --> 00:10:30.640 Enrutas el servicio. 00:10:31.140 --> 00:10:32.520 Transforma los datos si es necesario. 00:10:33.000 --> 00:10:33.800 Recibe la respuesta de vuelta. 00:10:34.400 --> 00:10:35.540 También la transforma si hace falta. 00:10:36.240 --> 00:10:37.340 Envía todo de regreso al cliente. 00:10:37.700 --> 00:10:38.200 Una sola turn. 00:10:38.200 --> 00:10:42.440 Cada paso ocurre automáticamente, en orden, sin que el servicio deba preocuparse. 00:10:42.820 --> 00:10:44.340 El verdadero poder no está en una sola función. 00:10:44.740 --> 00:10:45.500 Está en la integración. 00:10:46.160 --> 00:10:48.800 Puedes añadir una política de seguridad sin tocar el enrutamiento. 00:10:49.620 --> 00:10:51.520 El servicio backend sin cambiar el cliente. 00:10:52.020 --> 00:10:54.220 Puedes actualizar los límites de tasa sin redesplegar nada. 00:10:54.880 --> 00:10:57.360 Cada pieza es independiente, pero todas funcionan en la misma tubería. 00:10:58.120 --> 00:11:01.400 Y como todo pasa por un solo lugar, obtienes visibilidad total de lo que sucede. 00:11:02.140 --> 00:11:03.600 Registros, métricas, analíticas. 00:11:03.940 --> 00:11:04.720 Todo es de un solo punto. 00:11:04.720 --> 00:11:08.180 Puedes ver cuántas solicitudes llegaron, cuáles fallaron, cuáles fueron lentas, 00:11:08.260 --> 00:11:09.660 qué clientes usan más recursos. 00:11:10.360 --> 00:11:13.640 Sin un gateway, tendrías que recopilar esos datos de cada servicio individualmente. 00:11:13.980 --> 00:11:15.040 Con un gateway, todo está ahí mismo. 00:11:15.420 --> 00:11:16.180 Esa es la gran revelación. 00:11:16.480 --> 00:11:17.700 El gateway no es solo un enrutador. 00:11:18.080 --> 00:11:20.140 Es un centro de control para toda tu plataforma de API. 00:11:20.680 --> 00:11:23.800 Cada solicitud, cada respuesta, cada error, todo fluye a través de un solo lugar. 00:11:24.200 --> 00:11:26.220 Tienes una visión unificada de todo lo que está ocurriendo. 00:11:26.620 --> 00:11:27.700 Entonces, ¿cómo usas esto realmente? 00:11:28.060 --> 00:11:29.360 Hablemos de lo que puedes hacer al mismo con esto. 00:11:30.100 --> 00:11:30.940 Conclusiones prácticas. 00:11:31.360 --> 00:11:31.780 Quedamos la lista. 00:11:31.780 --> 00:11:35.200 Si tienes uno o dos servicios, probablemente aún no necesites un API Gateway. 00:11:35.760 --> 00:11:38.520 Puedes manejar el enrutamiento tú mismo y gestionar la autenticación en cada servicio. 00:11:38.820 --> 00:11:39.780 No es elegante, pero funciona. 00:11:40.540 --> 00:11:43.780 Pero en el momento en que llegas a tres servicios o expones APIs a clientes externos, 00:11:43.840 --> 00:11:45.380 la complejidad crece rápido. 00:11:45.980 --> 00:11:47.160 El gateway se paga solo rápidamente. 00:11:47.600 --> 00:11:48.660 Entonces, ¿cuál es tu mejor primer paso? 00:11:49.120 --> 00:11:50.460 Centraliza la autenticación en el gateway. 00:11:50.760 --> 00:11:51.800 Haz eso antes que cualquier otra cosa. 00:11:52.140 --> 00:11:52.680 Elige un servicio. 00:11:52.820 --> 00:11:54.200 Mueve su verificación de autenticación al gateway. 00:11:54.580 --> 00:11:57.140 Notarás de inmediato que el código de tu servicio se vuelve más limpio. 00:11:57.620 --> 00:12:00.100 Ya no habrá lógica de validación de tokens dispersas por todas partes. 00:12:00.100 --> 00:12:03.100 Ya no te preguntarás si lo implementaste igual en cada servicio. 00:12:03.700 --> 00:12:06.320 El gateway lo maneja una vez y todos los servicios se benefician. 00:12:06.840 --> 00:12:07.400 Siguiente paso. 00:12:07.500 --> 00:12:08.240 Limitación de tasa. 00:12:09.160 --> 00:12:11.340 Incluso un límite simple protege a tu backend de una sobrecarga. 00:12:11.640 --> 00:12:14.400 Comienza con algo básico como 100 solicitudes por minuto por cliente. 00:12:14.800 --> 00:12:16.780 Eso evita que un cliente fuera de control tumbe tu servicio. 00:12:17.140 --> 00:12:17.480 Puedes hablar.