El principio "No te repitas" o "DRY" es importante en el desarrollo de software. En esta publicación, le mostraremos cómo aplicarlo a la configuración de Apache APISIX.  El principio DRY  "No te repitas" (DRY) es un principio de desarrollo de software cuyo objetivo es reducir la repetición de información que es probable que cambie, reemplazándola con abstracciones que tienen menos probabilidades de cambiar o utilizando la normalización de datos que evita la redundancia en primer lugar.  --  Wikipedia - No te repitas  La idea principal detrás de DRY es que si repites lo mismo y la información cambia, entonces debes actualizar la información modificada en varios lugares. No solo implica un esfuerzo adicional; existe la posibilidad de que te olvides de ello y tengas información diferente en diferentes lugares. DRY se destaca en la corrección de errores.  Imagine un fragmento de código que contiene un error. Imagine que ha duplicado el fragmento en dos lugares diferentes. Ahora, debe corregir el error en esos dos lugares, y esa es la parte fácil; lo difícil es saber que existe la duplicación en primer lugar.  Existe una gran posibilidad de que la persona que duplica y la que corrige sean diferentes. Si el fragmento se hubiera refactorizado para que se pueda compartir y se lo haya llamado desde los dos lugares, solo necesita corregir el error en este lugar.  La mayoría de las personas asocian DRY con el código. Sin embargo, podría ser más limitante y contrario a la idea original.  El principio fue formulado por Andy Hunt y Dave Thomas en su libro The Pragmatic Programmer. Lo aplican de manera bastante amplia para incluir esquemas de bases de datos, planes de prueba, el sistema de compilación e incluso la documentación.  --  Wikipedia - No te repitas  Los sistemas de configuración de sonido permiten el DRY o incluso lo fomentan.  DRY en Apache APISIX  Apache APISIX ofrece configuración DRY en dos lugares.  Aguas arriba secas  En un contexto de comercio electrónico, su viaje de principiante para definir una ruta en Apache APISIX probablemente comience de la siguiente manera:   routes: - id: 1 name: Catalog uri: /products* upstream: nodes: "catalog:8080": 1  Si está familiarizado con APISIX, definimos una ruta al catálogo bajo el URI   . Sin embargo, hay un problema: probablemente desee que los posibles clientes exploren el catálogo, pero desea evitar que las personas creen, eliminen o actualicen productos. Sin embargo, la ruta coincide con todos los métodos HTTP de forma predeterminada. /products  Deberíamos permitir que sólo los usuarios autenticados administren el catálogo para que todos puedan navegar libremente por él. Para implementar este enfoque, necesitamos dividir la ruta en dos:   routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] #1 uri: /products* upstream: #2 nodes: "catalog:8080": 1 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] #3 uri: /products* plugins: key-auth: ~ #4 upstream: #2 nodes: "catalog:8080": 1  Búsqueda de coincidencias  ¡Duplicado aguas arriba!  Gestión de partidos  Sólo los consumidores autenticados pueden usar esta ruta;   es el complemento más simple para esto key-auth  Hemos solucionado el problema de seguridad de la forma más sencilla posible: copiando y pegando. Al hacerlo, duplicamos la sección   . Si necesitamos cambiar la topología,   , añadiendo o quitando nodos, debemos hacerlo en dos lugares. Esto anula el principio DRY. upstream por ejemplo  En situaciones del mundo real, especialmente cuando involucran contenedores, no implementarías el   mediante la lista   . En su lugar, deberías implementar un   dinámico para adaptarlo a los cambios de topología. Sin embargo, el punto sigue siendo válido cuando necesitas cambiar la configuración o implementación del descubrimiento de servicios. Por lo tanto, mi punto se aplica por igual a los nodos y al descubrimiento de servicios. upstream nodes descubrimiento de servicios  Junto con la abstracción   , APISIX ofrece una abstracción   para implementar DRY. Podemos reescribir el fragmento anterior de la siguiente manera: de ruta de flujo ascendente   upstreams: - id: 1 #1 name: Catalog nodes: "catalog:8080": 1 routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /products* upstream_id: 1 #2 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /products* upstream_id: 1 #2 plugins: key-auth: ~  Definir un upstream con ID  1  Referenciarlo en la ruta  Si algo sucede en la topología, debemos actualizar el cambio solo en el   único. Upstream  Tenga en cuenta que definir el incrustado   y hacer referencia al mismo con   son   . upstream upstream_id mutuamente excluyentes  Configuración del complemento DRY  Otra área en la que APISIX puede ayudarle a secar su configuración es la abstracción   . APISIX implementa la mayoría de las funciones, si no todas, a través de complementos de complementos  Implementemos   en nuestra API. Necesitamos reescribir la URL antes de reenviarla. el control de versiones basado en rutas   routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /v1/products* upstream_id: 1 plugins: proxy-rewrite: regex_uri: [ "/v1(.*)", "$1" ] #1 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /v1/products* upstream_id: 1 plugins: proxy-rewrite: regex_uri: [ "/v1(.*)", "$1" ] #1  Elimine el prefijo   antes de reenviar /v1  Al igual que en   anterior, la sección   está duplicada. También podemos incluir la configuración del complemento en un objeto   dedicado. El siguiente fragmento tiene el mismo efecto que el anterior: upstream plugins Plugin Config   plugin_configs: - id: 1 #1 plugins: proxy-rewrite: regex_uri: [ "/v1(.*)", "$1" ] routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 #2 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 #2  Factorizar la configuración del complemento en un objeto dedicado  Referencialo  Los lectores astutos pueden haber notado que me falta parte de la configuración: ¡la   desapareció misteriosamente! De hecho, la eliminé para mayor claridad. auth-key  A diferencia de   y   ,   y     . Podemos solucionar el problema simplemente agregando el   faltante: upstream upstream_id plugins plugin_config_id no son mutuamente excluyentes plugin   routes: - id: 1 name: Read the catalogue methods: [ "GET", "HEAD" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 - id: 1 name: Read the catalogue methods: [ "PUT", "POST", "PATCH", "DELETE" ] uri: /v1/products* upstream_id: 1 plugin_config_id: 1 plugins: key-auth: ~ #1  ¡Arreglalo!  De esta manera, puedes mover la configuración compartida a un objeto   y mantener una específica en el lugar al que se aplica. Pero, ¿qué pasa si se utiliza el mismo complemento con diferentes configuraciones en el   y directamente en la   ? La   es bastante clara al respecto: plugin_config plugin_config route documentación    >   >   >   >  Consumer Consumer Group Route Plugin Config Service  En resumen, la configuración   en una   prevalece sobre la configuración en   . También nos permite proporcionar la variable   para el complemento   en un   y solo configurarlo en una ruta. ¡APISIX encontrará y usará la clave para cada   ! plugin route plugin_config_id apikey key-auth consumer consumer  Conclusión  DRY no solo se trata de código, sino de gestión de datos en general. La configuración son datos y, por lo tanto, se incluye en este ámbito general.  APISIX ofrece dos opciones DRY: una para   -   y otra para   -   . Los upstream son exclusivos; los plugins permiten la anulación. upstream upstream_id plugin plugin_config_id  Ambos mecanismos deberían ayudarle a secar su configuración y hacerla más fácil de mantener a largo plazo.   Para ir más allá:   El principio de no repetirse   Precedencia de fusión de configuraciones   Publicado originalmente en   el 1 de septiembre de 2024 A Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Este audio es producido en el idioma original de la historia!

Cómo secar la configuración Apache APISIX

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

El modelo Bitcoin UTXO, impulsando un ecosistema único

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

El modelo Bitcoin UTXO, impulsando un ecosistema único

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps