Problemas de desempeño con Equip === 1. Actualmente tenemos 2 problemas críticos con dos acciones: la primera es la carga de la aplicación, que para jefaturas con muchos compromisos aceptados se vuelve crítico (4 ~ 6 seg) de espera para que carge la aplicación, y la otra acción es la de enviar la aplicación (6 seg). - El problema de la acción de enviar planificación era que una query estaba mla diseñada y gastaba cerca de 2~3 segundos innecesariamente, aparte habían otros pequeños problemas con la eficiencia de la query que debiese reducir el tiempo menos de 1 seg. Ese pedido lo está abordando luís actualmente. - El problema con la carga de la aplicación son dos: - Se carga toda la información de la aplicación en una sola llamada a la base de datos (por ejemplo la información de colaboradores se podría postergar hasta que llegue la información de la agenda). (Pedido a marco) - Pedidos aceptados (confiabilidad y colaboración) no se cargan gradualmente. (pedido a marco) - Una query no estaba utilizando el indice de proyecto, por lo que se demoraba cerca de 400ms innecesariamente (Ya se arregló) - Las acciones derivadas no se estaban eliminando y aumentaban considerablemente el tiempo (200ms a 300ms) de todas las acciones (Ya se arregó) 2. Como parte de este compromiso también se mejoró el proceso de diseño de una query y los estándares del [documento de diseño de solución](https://hackmd.io/BNcUd5fsQhmEBTfVLyTelg?view#Queries) para ayudar a los desarrolladores a mejorar la implementación de sus queries 3. Desde el rol de arquitecto siento que si bien podemos seguir manteniendo y mejorando el desempeño de las queries, creo que valdría la pena evaluar alternativas que permitan simplificar el proceso de "mantención del estado de la aplicación" Tales como graphQL con Apollo. Lo que entre sus beneficios incluyen: las queries no generan errores, es trivial llamar nuevos datos, no hay que preocuparse del desempeño de cada query, disminuir el trabajo de incorporar queries, entre otras.