Photo by Mabel Amber
Al definir un documento JSON, los campos pueden tener diferentes tipos, como string, number, boolean, etc… Sin embargo, al crear un documento usando --arg, el valor siempre se trata como string:
--arg name value:This option passes a value to the jq program as a predefined variable. If you run jq with –arg foo bar, then $foo is available in the program and has the value “bar”. Note that value will be treated as a string, so –arg foo 123 will bind $foo to “123”.
Una de las automatizaciones que hemos desarrollado consiste en un autoservicio para que los clientes puedan gestionar políticas en un proxy.
El usuario genera un fichero CSV con varios parámetros y los “sube” a un repositorio Git en su proyecto. El evento desencadena la ejecución de una pipeline en la que procesamos el fichero, validamos su contenido, etc. Una vez procesados, construimos un objeto JSON para cada una de las reglas, las agregamos y finalmente las integramos en el documento de configuración del proxy del cliente (que contiene otros campos que el cliente no debe editar).
Hace unos días me topé con el vídeo Why You Shouldn’t Nest Your Code del canal CodeAesthetic de YouTube. Me recordó en cierto modo al artículo de Mat Ryer Code: Align the happy path to the left edge.
Aprovechando la calma de estos días, he revisado algo del código que tenemos en algunas de nuestras pipelines. He aplicado las ideas explicadas en estos artículos y el incremento en la claridad del código ha sido espectacular.
En entradas anteriores he escrito sobre cómo interaccionar con una API a través de scripts en Bash, usando curl y poco más… En vez de dejar en manos de los usuarios la tarea de generar el payload que enviar vía curl a la API, desarrollé un cliente en Bash: Cliente API en Bash (con curl).
Desde entonces, he estado trabajando en una versión en Go del cliente para ésta API… Y creo que ¡ya está lista 🎉!
En esta entrada, describo por encima cómo funciona, pero sobre todo cómo ha sido la experiencia de desarrollarla.
En esta entrada describo un caso práctico sobre cómo manipular un documento JSON (una IAM Policy de Google Cloud) para añadir un nuevo miembro a un rol determinado.
Las políticas pueden gestionarse directamente mediante la herramienta de línea de comandos gcloud, por ejemplo, sobre un folder. Sin embargo puede ser interesante disponer de un registro con el estado deseado de los permisos de los recursos y así evitar drift (por ejemplo, si alguien modifica los permisos mediante gcloud o desde la consola).
Aunque el ejemplo se centra en un fichero de políticas de GCP, la entrada describe técnicas aplicables a la manipulación de cualquier fichero JSON.
Hace unos días leía en el foro de Kubernetes el caso de un usuario que no tenía claro cómo hacer que su aplicación fuera escalable, ya que al llegar a un determinado nivel de carga, la aplicación se saturaba.
El problema, por lo que entendí, es que la aplicación hacía “todo el trabajo”: recibía las peticiones de los usuarios, gestionaba las acciones para procesar cada petición y devolvía el resultado a los usuarios una vez finalizado.
Una solución rápida podría ser desplegar un horizontal pod autoscaler, pero probablemente lo ideal sería cambiar la arquitectura de la aplicación…
Así que me puse a ello en mi lenguaje de programación favorito: Go ;)
Habitualmente, al insertar un valor en el backend a través de la API, si la operación tiene éxito, se devuelve el identificador del registro creado.
En el tutorial de Jeremy Morgan Building a Web App with Go and SQLite, se devuelve un mensaje genérico {"message": "success"}, que no permite realizar acciones adicionales sobre el nuevo registro.
En esta entrada modificamos el código de la función AddPerson para devolver el identificador del nuevo registro.
En la entrada Mejora al tutorial ‘Building a Web App with Go and SQLite’: limitar el número de registros devueltos por defecto modificamos el código original del tutorial de Jeremy Morgan Building a Web App with Go and SQLite para que el usuario pudiera especificar el número de resultados devueltos al consultar la API a través del parámetro count: http://<URL>/api/v1/person?count=15.
El problema es que siempre se devuelven las entradas empezando por la de Id más bajo (habitualmente, 1).
En esta entrada, modificamos la función getPersonById para introducir también el parámetro count y que se devuelvan count resultados a partir del Id especificado.
En la mayoría de tutoriales sobre cómo construir una API en Go (incluído el tutorial de la documentación oficial de Go), el primer endpoint que se describe es el que usa el método GET y que recupera todos los registros de la base de datos.
Sin embargo, en el mundo real, las APIs devuelven un número limitado de registros y un índice; en una nueva consulta, se puede obtener un nuevo conjunto de resultados (y un nuevo índice), etc. Esto es así porque el resultado de la consulta con GET puede, potencialmente, devolver un número elevado de registros.
En el tutorial Building a Web App with Go and SQLite, se incluye una limitación hardcodeada en el código para evitar, precisamente, que se devuelvan todos los valores en la base de datos de ejemplo (1000 registros).
En este artículo, voy a mostrar cómo obtener el valor desde la queryString para que sea configurable desde la llamada a la API.
Una de puntos que siempre se destacan al trabajar con Go es lo completa que es la biblioteca estándar de funciones que proporciona el propio lenguaje.
flag proporciona funcionalidad para gestionar las opciones de las aplicaciones sin interfaz gráfica que se ejecutan desde la línea de comandos (CLI).
En esta entrada reviso cómo usar el paquete para los casos de uso más habituales.
