PlanPok

Para retomar un poco blog que había caído en el olvido, traigo este pequeño proyecto que acabo de poner en marcha y se llama PlanPok.

Lo que permite PlanPok es poder realizar estimaciones por varias personas de forma distribuida. La mecánica es sencilla, hay una persona que crea una sala y es la que puede moderar cuándo se realiza una nueva votación o cuando se muestran los votos.

El resto de personas pueden unirse a la sala mediante la URL y votar. Todo de forma anónima.

Sin registro, sin datos personales y sin publicidad (al menos de momento, no prometo nada).

Es totalmente gratuito, así que te invito a que pases y lo pruebes. Encantado de recibir comentarios y críticas constructivas; y por supuesto abierto a sugerencias. Tiene cuenta propia de Twitter pero también me podéis buscar directamente por la red.

Un poco de historia

PlanPok nace de querer aprender y ensayar algunas tecnologías y prácticas. Llevaba un tiempo dándole vueltas a hacer algún proyecto que no me llevase mucho tiempo, un MVP que pudiese evolucionar si me apetecía luego. Mi objetivo empezó siendo:

• Sockets para la comunicación entre front y back. Algo en tiempo real
• Código en back fuese totalmente reactivo
• Front totalmente separado de back

Casualidades de la vida en el proyecto en el que estoy trabajando desde hace un tiempo con un equipo distribuido, usamos una web para las estimaciones de las tareas y hace unos meses empezó a no funcionar muy bien. Cuadraba muy bien con lo que estaba buscando y además le podíamos sacar partido directamente.

Y así lo hice aprovechando unos días de vacaciones del pasado diciembre, en ratos libres después de disfrutar con la familia.

Seguidamente comentaré alguna de las decisiones, pero finalmente he usado:

• Vue.js para front
• Java con Spring Boot para back
• RSocket para comunicación entre front y back
• Redis para almacenamiento y como pub/sub
• Go para un exporter de prometheus y visualización en grafana

Comunicación mediante sockets

Tengo que decir que con esta parte es con la que más vueltas di. Leyendo e informándome sobre tecnologías me pareció adecuado usar websockets con STOMP. Me permitía trabajar de forma similar a una API REST, enrutado mensajes y contenido serializable. Primeras pruebas de concepto de comunicación entre front y back sin problemas hasta que llego a la parte de hacerlo reactivo con Spring websocket: no hay forma.

Así que busqué alternativas y encontré RSocket. Tengo que decir que la integración fue sencilla excepto por una cosa: la configuración del enrutado en javascript. En retrospectiva diré que fue una chorrada por no entender bien cómo hacerlo, pero bueno, que hasta llegué a leer los paquetes con Wireshark. Dejo la anécdota para otro momento que el post ya se está alargando y queda todavía.

Código en back reactivo

Era una asignatura pendiente que quería explorar algún día desde que probamos ciertos desarrollos y leí sobre ello. Creo que Java no es el mejor lenguaje para esto, tiene un soporte bastante decente pero a veces hace las cosas difíciles. Elegí Java porque quería al menos un punto de apoyo conocido y poder centrarme en reactor; a día de hoy me encuentro más cómodo.

El cambio a programación reactiva fue duro pero gratificante en ciertos aspectos. Duro porque es un paradigma que es realmente distinto de la programación imperativa. En cierta forma me recuerda cuando aprendí la inversión de dependencias y empecé a usar TDD, hay que seguir unas buenas prácticas, pero tienes que amueblar bien la cabeza para que no se convierta en algo infumable cuando empiezas a hacer piezas un poco más complicadas de lo habitual.

Los ejemplos sencillos son fáciles de seguir: recuperar datos, transformarlos, iterarlos y generar un resultado está bien, pero nada más que empiezas a necesitar otras herramientas como bifurcaciones o control de errores empiezas a hiperventilar como Sheldon Cooper. He pasado buenos ratos revisando la extensa API intentando entender los conceptos y elegir las opciones más correctas.

Mención especial a Redis, no por el propio Redis que quien me conoce sabe que me gusta mucho, en su justa medida, sino en lo que me costó configurarlo bien en la parte de la suscripción del pub/sub y en la se cancelaba una suscripción (unsubscribe). Da para otro post, pero este fue el problema. Tuve que separar las conexiones y posteriormente borrarlas a mano, no me gustó, pero no encontré mejor forma, espero encontrarla algún día.

Front independiente de back

Quizás pueda sonar de perogrullo a día de hoy sobre todo pensando que tiene que existir comunicación entre ambos, pero tenemos que pensar que para un pequeño proyecto como este o un MVP no es una necesidad, lo hice porque quería recordar lo poco que sé de React o probar Vue.js. Finalmente me quedé con el segundo porque es lo que usamos en el proyecto en el que me encuentro trabajando ahora mismo, así que quizás podría servirme en el corto plazo.

Conclusión

Ahora mismo estoy contento con el stack elegido. No es porque sea mejor o peor sino porque satisface las necesidades que tengo en el proyecto a día de hoy y he cumplido mi objetivo de aprender un poco más, que para mí era lo principal.

Espero que ir evolucionando con nuevas ideas. Espero también que te sirva y aprovecha que es gratis. Y si crees que es útil y que lo merece, siempre puedes invitarme a un café. Recuerda que un programador es un organismo que convierte café en código 😉