![\"\"\/](\"https:\/\/lh6.googleusercontent.com\/19yFTZlFj0yPRiUTxtri0oHdxL29MlJQcXdo4X6pdaDmCPbdaNfkF6zHxL4k2ILakywABt-kmS_zGQ5cFIl8ndEv-03Z3NGXOOc3pD6rUlKEhhMw7H7LwCtJIVUU7D5OvcpGvKy7iKCJchD4M9d_Llo\")
Una introducci\u00f3n de los beneficios que nos puede aportar esta definici\u00f3n hasta el momento ser\u00edan los siguientes:<\/p>\n\n\n\n
- \n
- Permitir reemplazar los servicios sin la necesidad de actualizar al cliente, dado que es el API-GATEWAY que tiene el acoplamiento.<\/li>\n\n\n\n
- Podemos verlo como una aplicaci\u00f3n a nivel de arquitectura del patr\u00f3n de dise\u00f1o delegate.<\/li>\n\n\n\n
- El cliente no conoce la ubicaci\u00f3n de cada uno de los servicios, tales como localizaci\u00f3n de las direcciones IP, cantidad de instancias que existan. El cliente solo tiene acoplamiento hacia un punto y es este punto quien tiene el acoplamiento a los diferentes servicios.<\/li>\n<\/ul>\n\n\n\n
Ahora, \u00bfsab\u00edas que el api gateway puede trabajar con diferentes patrones arquitect\u00f3nicos?, conozcamolos: <\/p>\n\n\n\n
Gateway Routing Pattern<\/h2>\n\n\n
\nFuente: <\/strong>https:\/\/medium.com\/design-microservices-architecture-with-patterns\/gateway-routing-pattern-f40eb56a2dd9<\/a><\/figcaption><\/figure><\/div>\n\n\n Este patr\u00f3n se refiere al uso de un componente de gateway para enrutar las solicitudes de los clientes a los servicios apropiados en funci\u00f3n de criterios de enrutamiento predefinidos. El gateway act\u00faa como un punto de entrada \u00fanico para los clientes y se encarga de recibir las solicitudes de los clientes, evaluar los criterios de enrutamiento (como la URL, el tipo de solicitud, la versi\u00f3n de la API, etc.) y enrutar la solicitud al servicio apropiado en funci\u00f3n de los criterios. Este patr\u00f3n es \u00fatil cuando se necesita controlar y gestionar la ruta de las solicitudes de los clientes a diferentes servicios, y permite una mayor flexibilidad y escalabilidad en el enrutamiento de solicitudes.<\/p>\n\n\n\n
Principales beneficios:
<\/p>\n\n\n\n- \n
- Centralizaci\u00f3n del Enrutamiento<\/strong>: Con un \u00fanico punto de entrada (el gateway), se simplifica la gesti\u00f3n y configuraci\u00f3n del enrutamiento de solicitudes hacia los diferentes servicios. Esto facilita la adaptaci\u00f3n y el ajuste de las rutas sin tener que modificar directamente cada microservicio.<\/li>\n\n\n\n
- Flexibilidad en la Direcci\u00f3n del Tr\u00e1fico<\/strong>: El patr\u00f3n de enrutamiento con puerta de enlace permite cambiar las reglas de enrutamiento y las asociaciones entre rutas y servicios de manera m\u00e1s sencilla. Esto es especialmente \u00fatil cuando se necesita ajustar el tr\u00e1fico en funci\u00f3n de condiciones cambiantes, como la carga de los servicios o la disponibilidad de recursos.<\/li>\n\n\n\n
- Aislamiento de Microservicios<\/strong>: Los clientes no necesitan conocer la estructura interna de los microservicios ni interactuar directamente con ellos. Esto permite que los microservicios se mantengan independientes y facilita cambios en su implementaci\u00f3n sin afectar a los clientes.<\/li>\n\n\n\n
- Similitud con patrones de dise\u00f1o de software<\/strong>: Es la aplicaci\u00f3n del patr\u00f3n delegate<\/a> a nivel de arquitectura de software.<\/li>\n<\/ol>\n\n\n\n
Gateway Aggregation Pattern<\/h2>\n\n\n\n
Este patr\u00f3n se refiere a la consolidaci\u00f3n y agregaci\u00f3n de m\u00faltiples solicitudes de clientes en una sola solicitud que se env\u00eda a varios servicios en el backend. El gateway act\u00faa como un punto de entrada \u00fanico para los clientes y se encarga de recibir las solicitudes de los clientes, combinarlas y enrutarlas a los servicios apropiados en funci\u00f3n de las necesidades del cliente. Luego, el gateway recopila las respuestas de los servicios y las combina en una sola respuesta que se env\u00eda al cliente. Este patr\u00f3n es \u00fatil cuando se necesita reducir la latencia y el ancho de banda de la red, ya que evita que los clientes realicen m\u00faltiples solicitudes a diferentes servicios por separado.<\/p>\n\n\n\n
Fuente<\/strong>: https:\/\/medium.com\/design-microservices-architecture-with-patterns\/gateway-aggregation-pattern-9ff92e1771d0<\/figcaption><\/figure>\n\n\n\n Principales beneficios:
<\/p>\n\n\n\n- \n
- Simplificaci\u00f3n de la Interfaz del Cliente<\/strong>: Los clientes solo necesitan conectarse a un \u00fanico Gateway<\/em> para acceder a datos de diferentes servicios y fuentes. Esto simplifica la interacci\u00f3n del cliente y evita la necesidad de que los clientes conozcan la estructura interna de los microservicios.<\/li>\n\n\n\n
- Centralizaci\u00f3n de la L\u00f3gica de Agregaci\u00f3n<\/strong>: La l\u00f3gica de combinaci\u00f3n y agregaci\u00f3n de datos se encuentra en el Gateway<\/em>, lo que significa que los clientes no necesitan preocuparse por realizar m\u00faltiples llamadas a diferentes servicios. El Gateway<\/em> se encarga de obtener y combinar los datos de manera eficiente.<\/li>\n\n\n\n
- Reutilizaci\u00f3n de Datos<\/strong>: Al combinar datos de diferentes fuentes en una sola interfaz, se puede promover la reutilizaci\u00f3n de informaci\u00f3n en diferentes partes de la aplicaci\u00f3n.<\/li>\n\n\n\n
- Similitud con patrones de dise\u00f1o de software<\/strong>: Es la aplicaci\u00f3n del patr\u00f3n Facade<\/a> a nivel de arquitectura de software.<\/li>\n<\/ol>\n\n\n\n
Los dos patrones vistos hasta ahora no son excluyentes, es decir, tu puedes tener un gateway que aplica Gateway Aggregation Pattern y Gateway Routing Pattern de tal forma que algunos endpoints son simplemente para hacer un ruteo hasta un servicio y otros que son un endpoint que consolida diferentes llamados<\/p>\n\n\n\n
Anti-corruption Layer pattern<\/h2>\n\n\n\n
Este es un patr\u00f3n arquitect\u00f3nico que se utiliza para proteger y aislar un sistema nuevo o actualizado de componentes externos o legados que operan con un modelo de datos o un dise\u00f1o diferente. Se aplica cuando hay una necesidad de comunicaci\u00f3n entre sistemas que tienen estructuras de datos incompatibles o paradigmas de dise\u00f1o divergentes.
Implementa una capa de adaptador entre nuestro sistema con un subsistema externo que no comparten la misma sem\u00e1ntica. Esta capa traduce las solicitudes que hace un subsistema al otro subsistema.<\/p>\n\n\n\nFuente<\/strong>: Propia<\/figcaption><\/figure><\/div>\n\n\n Con este patr\u00f3n es importante ver donde se ubica la capa anti corruption dado que si busca interpretar y traducir las respuestas de otro sistema, debe estar en el sistema de origen.<\/p>\n\n\n\n
Principales beneficios:<\/p>\n\n\n\n
- \n
- Independencia y Aislamiento<\/strong>: Los sistemas heredados o externos pueden tener estructuras de datos, reglas de negocio y modelos de dise\u00f1o \u00fanicos que no encajan bien con el nuevo sistema. Aplicando la Capa Anti-Corruption, puedes aislar la complejidad y las peculiaridades de estos sistemas, permitiendo que el nuevo sistema mantenga su propio dise\u00f1o coherente y adaptado.<\/li>\n\n\n\n
- Estandarizaci\u00f3n de Interfaces<\/strong>: Al trabajar con sistemas externos que tienen interfaces propias poco convencionales o poco amigables, la Capa Anti-Corruption te permite definir interfaces m\u00e1s limpias y coherentes que reflejen las necesidades y el dise\u00f1o de tu nuevo sistema.<\/li>\n\n\n\n
- Separaci\u00f3n de Responsabilidade<\/strong>s: La Capa Anti-Corruption puede convertirse en el lugar centralizado donde se gestionan todas las interacciones con sistemas externos, separando as\u00ed esta preocupaci\u00f3n de los componentes principales del nuevo sistema.<\/li>\n\n\n\n
- Similitud con patrones de dise\u00f1o de software<\/strong>: Es la aplicaci\u00f3n del patr\u00f3n Adapter a nivel de arquitectura de software.<\/li>\n<\/ol>\n\n\n\n
\u00bfEs posible aplicar con los otros patrones arquitect\u00f3nicos?, la respuesta corta es S\u00cd, s\u00ed es posible combinarlos y ofrecer los tres patrones en un mismo componente.<\/em><\/p>\n\n\n\n
Ubicaci\u00f3n del Gateway en nuestras arquitecturas<\/h2>\n\n\n\n
Tenemos dos ubicaciones donde es posible ubicar nuestro componente gateway<\/em>:<\/p>\n\n\n\n
- \n
- Dentro de nuestro sistema para reducir el acoplamiento hacia otro subsistema:
Este gateway puede trabajar como Gateway Aggregation Pattern y Gateway Routing Pattern y anti-corruption layer pero solo es v\u00e1lido para componentes del contexto del sistema A
<\/li>\n\n\n\n - Al aplicar un gateway en un subsistema estamos buscamos ofrecer reutilizaci\u00f3n, <\/em>al igual que reducir el acoplamiento en los sistemas A y B.
Este gateway puede trabajar como Gateway Aggregation Pattern y Gateway Routing Pattern, pero no como anti-corruption layer.<\/li>\n<\/ol>\n\n\n\nBFF<\/h2>\n\n\n\n
Un BFF no es m\u00e1s que la aplicaci\u00f3n de todos los patrones vistos hasta ahora (Gateway Aggregation Pattern, Gateway Routing Pattern, anti-corruption layer) pero con un contexto limitado de uso hacia un \u00fanico cliente.<\/p>\n\n\n
\n<\/figure><\/div>\n\n\n
Se usa principalmente para respaldar la solicitud del cliente con un \u00fanico Backend.<\/p>\n\n\n\n
El prop\u00f3sito de tener un BFF es brindarle a su cliente una interfaz enfocada para conectarse. <\/p>\n\n\n\n
Diferencia entre un BFF y un API Gateway<\/h2>\n\n\n\n
Fuente<\/strong>: https:\/\/medium.com\/javarevisited\/api-gateway-vs-backend-for-frontend-bff-everything-you-need-to-know-90154a1e693f<\/figcaption><\/figure>\n\n\n\n Un API gateway puede ser usado por m\u00e1s de un cliente, un BFF provee servicios a un \u00fanico cliente.
El BFF es el responsable de completar las transacciones que necesita el cliente para funcionar, de tal forma que si nuestro Front necesita de m\u00faltiples API para obtener la informaci\u00f3n que necesita, el BFF trabaja como Gateway Aggregation Pattern para consolidar la informaci\u00f3n en un \u00fanico llamado. <\/p>\n\n\n\nUn API ser\u00eda un componente (posiblemente REST) encargado de proveer una funcionalidad del negocio dentro del dominio que se encuentre.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Conclusiones:<\/strong><\/p>\n\n\n\n
- \n
- Utiliza un BFF <\/strong>cuando tu front deba comunicarse con diferentes API, si tu front solo tiene comunicaci\u00f3n con un API, un BFF es sobredise\u00f1o.<\/li>\n\n\n\n
- Ubica el API-Gateway dependiendo de lo que busques, ya sea tener caracter\u00edsticas de aggregate, routing o anti-corruption layer.<\/li>\n\n\n\n
- Existen m\u00e1s patrones arquitectonicos que se pueden aplicar en los Gateway.<\/li>\n\n\n\n
- Un Gateway es para proveer a 1 o m\u00e1s clientes, un BFF siempre ser\u00e1 para un \u00fanico cliente.<\/li>\n\n\n\n
- Si necesitas solo el patr\u00f3n Gateway Routing<\/strong> y estas trabajando en ambiente cloud<\/strong>, lo mejor es adpotar uno de los servicios de aws<\/a> o gcp<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
Antes de comenzar definamos que es un patr\u00f3n arquitect\u00f3nico y en qu\u00e9 se diferencian con un patr\u00f3n de dise\u00f1o. Ambos son soluciones probadas y efectivas para problemas recurrentes en el dise\u00f1o y desarrollo de software, pero tienen diferentes alcances y enfoques.Los patrones arquitect\u00f3nicos son estrategias de alto nivel para dise\u00f1ar la estructura general de un … Leer m\u00e1s<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[2],"tags":[47,41,46,48,45,44,42,39],"class_list":["post-281","post","type-post","status-publish","format-standard","hentry","category-clean-architecture","tag-anti-corruption-layer","tag-api-gateway","tag-bff","tag-gateway","tag-gateway-aggregation-pattern","tag-gateway-routing-pattern","tag-patron-arquitectonico","tag-patron-de-diseno"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/posts\/281"}],"collection":[{"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/comments?post=281"}],"version-history":[{"count":7,"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/posts\/281\/revisions"}],"predecessor-version":[{"id":291,"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/posts\/281\/revisions\/291"}],"wp:attachment":[{"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/media?parent=281"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/categories?post=281"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/tags?post=281"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Utiliza un BFF <\/strong>cuando tu front deba comunicarse con diferentes API, si tu front solo tiene comunicaci\u00f3n con un API, un BFF es sobredise\u00f1o.<\/li>\n\n\n\n
- Estandarizaci\u00f3n de Interfaces<\/strong>: Al trabajar con sistemas externos que tienen interfaces propias poco convencionales o poco amigables, la Capa Anti-Corruption te permite definir interfaces m\u00e1s limpias y coherentes que reflejen las necesidades y el dise\u00f1o de tu nuevo sistema.<\/li>\n\n\n\n
- Centralizaci\u00f3n de la L\u00f3gica de Agregaci\u00f3n<\/strong>: La l\u00f3gica de combinaci\u00f3n y agregaci\u00f3n de datos se encuentra en el Gateway<\/em>, lo que significa que los clientes no necesitan preocuparse por realizar m\u00faltiples llamadas a diferentes servicios. El Gateway<\/em> se encarga de obtener y combinar los datos de manera eficiente.<\/li>\n\n\n\n
- Flexibilidad en la Direcci\u00f3n del Tr\u00e1fico<\/strong>: El patr\u00f3n de enrutamiento con puerta de enlace permite cambiar las reglas de enrutamiento y las asociaciones entre rutas y servicios de manera m\u00e1s sencilla. Esto es especialmente \u00fatil cuando se necesita ajustar el tr\u00e1fico en funci\u00f3n de condiciones cambiantes, como la carga de los servicios o la disponibilidad de recursos.<\/li>\n\n\n\n
- Centralizaci\u00f3n del Enrutamiento<\/strong>: Con un \u00fanico punto de entrada (el gateway), se simplifica la gesti\u00f3n y configuraci\u00f3n del enrutamiento de solicitudes hacia los diferentes servicios. Esto facilita la adaptaci\u00f3n y el ajuste de las rutas sin tener que modificar directamente cada microservicio.<\/li>\n\n\n\n
![\"\"\/](\"https:\/\/lh5.googleusercontent.com\/02RsftaRYTp6VR5fX7ndnU4EXhHzDz7FuKMhX4bLV8V0iMnti5YWbCB7w_hxgPjzjSfcow-FnjPXh2nE54O3KKuReDrORjtjWPG3onUSKlVLkOOCaTbPq2m3L8aORwmlBEfnEZDdEaOs0j80GBJouGw\")
![\"\"\/](\"https:\/\/lh5.googleusercontent.com\/BlFQpFWROgDvJa4UBTSeXCr0Q_D6wth2eCovZIYo0ZoNEcxFD_J2F9qITc2n9INXGz1zRDR6VhH5303I5Trp6WhQgZ-LIzxeBXcMdZe3AXcKToxCcP91HpDoviBG8JKmThZKj-gVUYN0YVmQEVlOD4U\")
![\"\"](\"https:\/\/lh3.googleusercontent.com\/esrckBsND_kW8uSJ7bMl5ZnZG1x4YOEsLm--QF5HeBh9sHibKO58SGdQd12_FEAmVYgNzHnPNTUeFKakw4DFq5OtzqYlOYY0fCgTcani9YI-s9VNVszr75PQ5NC_cGIrwEEB_nb4kdPKjaQgsVJolWI\")
![](\"https:\/\/lh5.googleusercontent.com\/AsMPcQ9TJCY2_Tr3smBUgXH6czm4xZc_Kpd6KM23sQ6PkMAl91zkhl8Cbvrf5z4WapQZJpFJduk1lu69hVSxaRZkOKXkxGcF-dL5glpgfxNzHzUmST8gnUcZvvh2OCG9O7yveEPpCO30qOE_w-32CpQ\")
![](\"https:\/\/lh4.googleusercontent.com\/9n5uAO7ym9FVLNfUF3gbpOdPjlWpOWjv0xjIGuwyMBS85I_OZqmFud21gm9iC6x2fwNsQd22_XbogkqNfM5Mh1dGz_E5sUeNO1uMuZJn7PEPuqgQZ2rloPCj9WxbRQvmFRHZinVvt35b7q3nFDcQojw\")
![\"\"\/](\"https:\/\/lh6.googleusercontent.com\/l2unOXTem3l91svDNlzSrkj_zXjcm6alNxkagNOX-0-I8SL5tdy4asEnNWHZz64jRTGQ2Jl6rxgVrWgI0q7jpkDREqnZDoC7cUqpyaWVE6R3TI84MH3zUMp64YA_QY7S_64IZBY_9Cd6VuxWsxQOiSg\")