Angular $http Interceptor para medir tiempo de respuesta desde el servidor

¡¿?!
¡¿?!

Hace no mucho estuve involucrado en el desarrollo de un prototipo de una app MEAN. Una de las cosas que queríamos mostrar era la velocidad de respuesta del backend nodejs. Para hacerlo se me ocurrió loguear en el navegador el tiempo de respuesta de cada solicitud http que realizaba una app.

Hay diferentes opciones para hacer esto. Mi idea era ser lo menos invasivo posible. Similar a lo que hice con el cache Redis, algo que no necesite grandes modificaciones al código y que sea relativamente facil “prender” y “apagar”. Los $http interceptors fueron la opción ideal para ello. Uno de los motivos por los que me decante por esta opcion es porque anteriormente los había usado para “manejar” los permisos de acceso a determinadas URLS  y los vi usarse para insertar tokens a los request de forma mas elegante.

¿Como funcionan los interceptors?

Básicamente consiste en apoderarse de las solicitudes http y realizar algún tipo de procesamiento en el medio. En la documentación de angular lo explican un poco, cuesta al principio, pero vale la pena tomarse un rato en entenderlo ya que es una herramienta muy poderosa.

Particularmente en mi caso necesitaba saber el momento en el que comenzaba el request y el momento en el que recibía la respuesta. Teniendo estos dos solo me faltaba hacer el calculo del tiempo que tardo en ejecutarse y luego loguearlo. Al final el código me quedo así:

Como pueden ver no tiene demasiada complicación. Y en caso de necesitar utilizarlo solo tienen que cambiar el “miApp” por el nombre de su aplicación y tendría que salir andando.

Básicamente podemos ver que nuestro “logueador” de tiempos ante el request agrega un campo con el tiempo cuando empezó. Luego, ante el response, toma el tiempo actual y le resta el campo que guardamos ante el request. Lo demás como response.config.url y response.config.method fue un agregado para poder identificar a cada solicitud.

Cache Redis para backend nodejs

Quería aplicar un cache en Redis para una aplicación que estaba desarrollando. Nada del otro mundo, simplemente capturar todos los gets que peguen a mi api, fijarme desde cuando lo tengo guardado y decidir si le devuelvo el cache o si proceso el request al completo para re-hacer el cache. Y no queria usar una de las soluciones que ya existen en el mercado.

redis

Antes de comenzar necesitamos instalarnos Redis (si todavía no lo tenemos). Yo segui la explicación oficial. Que en realidad no es una explicación, solo tenemos que introducir los siguientes comandos en la consola:

El ejecutable nos queda en:

Luego necesite un conector entre mi app hecha con nodejs y express (en el clasico stack MEAN) y Redis. El primero que encontré y que resulto ser de lo mejorcito según vi después fue node_redis. En el github tienen el instructivo para instalarlo y poner el funcionamiento. No tiene sentido que se los explique mucho, es solo “npm install” y agregarlo en donde lo vallamos a usar con un “require”.

Se me había complicado un poco y no podía “interceptar” los response para poder guardarlos en mi cache. Al final, algunos compañeros de trabajo me pasaron el link, con esta pregunta de stack overflow pude hacerlo.

Básicamente lo que se hace, y en el código creo que esta bastante claro, es usar como clave la url y como value un mix entre los datos y el tiempo en el que se guarda. Cuando llega un request nos fijamos si existe el resultado y si no existe o si el tiempo es superior a nuestro limite procesamos el request (y cada vez que se procesa un request terminamos guardando en el cache). Este es el código:

Seguramente se lo puede mejorar bastante. Pero como era mas un ejercicio para probar el concepto me parece que quedo bastante bien. Con algunos retoques (y ni siquiera serian tantos) se podría tener un paquetito al que podríamos incluir por default en muchos de nuestros proyectos que consideremos que necesitan un cache.

Y pasaron los 3 meses…

Paso un mes desde el día que publique que estaba a punto de cumplir los 3 meses en FDV Solutions me gustaría pensar que alguno estaba preocupado por saber como siguió mi historia en la empresa, pero se que prácticamente nadie me lee así que me estaría mintiendo a mi mismo.

3Los tres meses pasaron. Recibí mi primer evaluación de desempeño con resultados mas que satisfactorios. ¡Y hasta me dieron un aumento! Tal vez un poco menos de lo que hubiese pedido si me preguntaban (y si yo lo pedía directamente). Pero como no me preguntaron, ni lo pedí, no puedo estar mas que contento con que me lo hallan dado de esa forma.

El reconocimiento monetario igual no lo es todo. Di una charla sobre posicionamiento en buscadores (recordando mis épocas adsenseriles), la charla gusto y estamos viendo si sumo un poco en el equipo de marketing. Lo que me encanta ya que no todo en esta vida es programar.

En cuanto a programación no puedo estar mas contento. Desarrolle en tres tecnologías diferentes. Arregle cagadas, cometí otras y aprendí un montón. En el camino hice entregas, deploys y “discuti” con americanos e indios en mi rustico ingles (que dicho sea de paso ¡la empresa esta pagandome el curso en el CUI para que mejore!)

Hice mi primer entrega grande, un desarrollo en Java/Spring/Jquery para un cliente bastante importante y al parecer tengo contentos tanto al cliente como a mi PL. Tanto que ya comenzamos con una ampliación de la aplicación y con perspectivas de hacer algunos otros cambios y mejoras.

Por otro lado participe en la elaboración de una demo en el stack MEAN para ver si podemos ofrecerle una solución mejor a un cliente. Aquí también aprendí unas cuantas cosas y me divertí un montón haciéndolo. ¡Incluso desarrolle una mini aplicación móvil!

Ahora mismo estoy participando en una pequeña investigación para ver si podemos hacer algo con el equipo de marketing y eso me tiene mas que contento.

Por otro lado extraño mis épocas de blogger. Estoy viendo si las puedo recuperar. Aunque sea dedicarle una media horita por día, en el momento del almuerzo. No todo en esta vida es trabajo, aunque me encanta lo que hago, y recuperar esa parte de mi vida me vendría muy bien. Extraño publicar planos y responder comentarios y hacer algo de SEO.

Y asi estamos. Esto esta siendo cada dia mas personal y menos interesante. Es lo que hay… por ahora.

PS: Por lo menos no me queje del tiempo de viaje, ni de lo poco que veo a mi familia :p

Se acercan los 3 meses

Como sabrán el tiempo típico de prueba cuando uno empieza a trabajar es de unos tres meses. Yo estoy cumpliendo dos y medio en FDV y estoy muy contento. Fueron unas 10 semanas muy interesantes, aprendí un montón, trabaje un montón, y conocí gente muy interesante.

keep calm and codeDurante este tiempo ya tuve la oportunidad de romper y arreglar varias cosas. Arreglar cosas de otros, romper cosas que otros tenían funcionando. Arregle lo que rompí y lo que no estaba roto también. Le dedique mucho tiempo y ganas al trabajo. Me gusta lo que estoy haciendo.

El viaje es algo que me esta pesando un poco. Pero es algo que ya sabia que iba a pasar, lo voy manejando. Lo importante es que estoy haciendo lo que quería hacer desde hace años. Y creo que estoy cumpliendo con las expectativas.

Este año esta siendo muy bueno para mi y mi familia. Están sucediendo cosas, algunas monetarias, otras de otra índole, que no creí que iban a suceder, y eso nos pone contentos. Mi hija esta creciendo a pasos agigantados, y lo que mas me pesa es no poder pasar mas tiempo con ellas…

En fin… dentro de dos o tres semanas tendría que estar escribiendo la actualización de que tan bien (o mal) parado salí luego de los 3 meses a prueba. Yo creo que voy a andar muy bien… Ganas le puse, como a todo lo que hago, y creo que la gente lo nota.

En fin… veremos lo que nos depara el futuro, ahora a seguir trabajando… pero antes a almorzar, los viernes la comida la paga FDV :).

PS: A pesar que casi no tengo tiempo para nada todavia saco algunos minutos de donde no hay para publicar algun plano en deplanos.com, de hecho ahi publico mas que en este blog personal, se imaginaran el por que.

Desarrollo rapido de apps con Ionic

lyonessDesde que surgió Ionic creo que la complejidad para desarrollar una aplicación para celulares y tablets se redujo muchísimo. Con saber un poco de html y javascript uno ya puede desarrollar una app completamente funcional y solo nuestra imaginación e ingenio nos ponen limites. Estoy viendo, por ejemplo, esta app de Lyoness. La verdad es que no se como esta desarrollada pero me imagino haciéndola con Ionic y es completamente factible.

Imaginemos lo siguiente, usamos WebView, con Angular hacemos algunos servicios que nos traigan las revistas, también usamos localstorage para guardar los settings y algunos datos para que la app este disponible cuando no tenga conexión a Internet, listo, ya tenemos nuestra app lista para funcionar.

Me parece muy importante eso de guardar datos para que estén disponibles cuando la app no tengo conexión a Internet. Eso es algo en lo que muchos de los desarrolladores que utilizan Ionic o Phonegap fallan. Con un par de minutos recorriendo Play Store se pueden encontrar multitud de comentarios diciendo que las apps no funcionan sin conexión a Internet, que solo esta mostrando una pagina web y cosas así.

Esta bueno esto de desarrollar apps de forma tan rápida. De hecho nos permite seguir eso del MVP (Minimum Viable Product o Producto viable mínimo) y sacar al mercado algo que se acerca a nuestra idea lo mas rápido posible. Pero también tenemos que asegurarnos de no caer en la tentación de sacar al mercado (aunque sea algo gratuito lo estamos sacando al mercado) apps que no sean usables y con bugs que arruinen la experiencia de usuario.

Particularmente creo que el desarrollo de aplicaciones híbridas llego para quedarse y lo vamos a ver cada vez mas. Ya no solo celulares y tablets, también en desktop y algunos dispositivos que todavía no imaginamos. Javascript se transformo en un verdadero lenguaje universal, y eso es gracias a los frameworks que surgieron a su alrededor, porque como lenguaje en si no es que facilite demasiado las cosas.