airquality-mx
airquality-mx copied to clipboard
jorgevgut
Apuntes sobre el diseño inicial
1- Diseño de notificaciones por email estando out-of-scope
Si el envío de emails está out-of-scope debería eliminarse todo lo relacionado con esto del diagrama de arquitectura general. Podría considerarse que está dentro del componente Other - not implemented.
De igual modo considero que analizar escenarios posibles durante el trabajo con emails es un desgaste innecesario por el mismo hecho de que no es un caso de uso soportado. Este tipo de análisis puede llevar no solo a perder tiempo haciéndolo sino también a una sobre ingeniería en el diseño inicial del sistema. Si el único tipo de notificación a implementar es vía Twitter todo el diseño debe estar enfocado en esto. Este es un principio de diseño que siempre tengo muy presente: KISS (Keep It Simple, Stupid!).
Nota: Cuando hablo de sobre ingeniería no me refiero al análisis de otros aspectos como el manejo de errores o la escalabilidad de la solución, teniendo en cuenta que es cloud-native, los que si deben tenerse en cuenta.
2- Evitar el envío de notificaciones irrelevantes Nota: Creo que este tema lo trataron de algún modo en el video de Youtube
Sería necesario evitar llenar el buzón de notificaciones de los usuarios cuando ya se le haya notificado de un aumento del valor de la calidad del aire (> 51). Con esto me refiero a que si la situación no ha cambiado significativamente desde la última notificación no debería volver a notificarse de este hecho cada 5 minutos.
Para lograr esto es necesario mantener los datos referentes a la última notificación enviada para poder comparar con los nuevos datos. Los términos del API indican que no se pueden redistribuir los datos ni en forma de caché ni en forma de datos archivados pero almacenar solo aquellos referentes a un instante de tiempo puntual (los de la última notificación enviada) únicamente con el fin de poder compararlos con la nueva situación considero que no contraviene los términos de uso de los datos.
El punto importante sería definir que entendemos en el sistema como un cambio significativo por lo que te dejo los criterios que yo consideraría, respecto al valor del índice de calidad del aire.
- Pasó a ser > 51
- Aumentó más de 5 puntos habiendo tenido anteriormente un valor > 51
- Cambio de nivel según el Air Pollution Level aunque la variación del valor sea menor a 5 puntos
- Pasó a ser < 51
3- Pérdida de notificaciones Pienso que el modo en que esto debe manejarse no es el almacenar todas las notificaciones no enviadas y enviarlas en el momento que ya no exista el problema que impidió su envío, porque por ejemplo si Twitter se cae por 5 horas y suponiendo que en esas 5 horas se generaron 20 nuevas notificaciones (teniendo en cuenta siempre el punto anterior) al momento de restablecerse el servicio le llegarán de golpe 20 notificaciones que quizás ya perdieron su importancia puesto que la situación ya se ha normalizado.
No obstante se sería importante saber si la última notificación generada no pudo enviarse para reenviarla en el momento que se pueda (se restableció el servicio de Twitter), aunque las validaciones definidas en el punto anterior indiquen lo contrario.
Gracias @betanzos por el feedback! Efectivamente, lo del email aun no decido si dejarlo fuera por completo, o dejarlo en otro apartado que ando trabajando como "fase 2". Gracias tambien por los comments de los puntos 2 y 3, efectivamente estos los discutimos en el video, y ando trabajando en un cambio que contempla tanto la logica de cuando enviar notificaciones, los terminos y la perdida de notificaciones. En el caso de la perdida por error del delivery channel(por ejemplo twitter) al final si se va a quedar por fuera. Espero la proxima semana actualizar todo.
