En el caso delfrontendno ha sido posible, por limitaciones temporales, escribir programá-
ticamente las pruebas. Pero esto no significa que no se hayan llevado a cabo. Se han realizado pero de forma manual.
Puesto que, a todas luces, resultaba excesivo acometer el estudio de otro framework de
pruebas, adicionalmente a los ya estudiados, se optó por enfocarse en un método un poco más rápido y menos complejo, que parece perfectamente viable teniendo en cuenta que no
se está tratando con un sistema enfocado a producción. Como los cimientos delfrontendson
JavaScript, y este lenguaje se guía por eventos, se ha considerado elfrontendcomo una má-
quina de estados. El procedimiento consiste en analizar un estado inicial, disparar el evento y comprobar que el estado final es el deseado. Este procedimiento es muy fácil de llevar a cabo gracias a las herramientas de desarrollo de React y Redux, que permiten visualizar tanto el estado de React como de Redux en cualquier instante. Como anécdota comentar que también existen herramientas de desarrollo que, en teoría, permiten visualizar el estado del cliente Apollo GraphQL. Pero, en realidad, estas herramientas fallan demasiado y no resultan muy útiles, puesto que en nuestro proyecto el estado de Apollo se refleja en el estado de Redux y los posibles errores se visualizan claramente en la consola del navegador.
En este trabajo, elfrontendno resulta, ni de lejos, una parte crítica del sistema. Tal y como
está implementado elbackend, es muy improbable poder comprometerlo desde elfrontendcon
entradas/acciones de usuario incorrectas, ya que debilidades tales como desbordamientos de
buffershan sido contempladas. Por otro lado, el sistema trata con total normalidad entradas de
usuario que hacen uso de caracteres Unicode y formatos requeridos, tales como direcciones de
correo electrónico, son comprobadas en elbackend, de forma que si el formato es incorrecto,
los datos no llegarán a modificarse y el cliente recibirá el mensaje de error correspondiente.
Lo que sí es mejorable es la información que recibe el usuario delfrontenden tales casos, pero
eso ya formaría parte de un sistema con un nivel de madurez mucho más alto, que difícilmente sería alcanzable en un trabajo de este tipo.
Conclusiones
E
n este último capítulo de la memoria, se presenta la situación final del trabajo, las leccionesaprendidas, y las posibles líneas futuras.
6.1 Situación final de la herramienta objeto de desarrollo
La herramienta objeto de desarrollo, en este caso una aplicación web/móvil de planifica- ción personal, ha alcanzado los objetivos inicialmente fijados. Se ha de tener en cuenta que dicha herramienta nunca fue el objetivo principal del proyecto, sino una forma de darle visibi-
lidad al trabajo realizado en elbackend. Teniendo presente esta premisa, en ningún momento
se pretendió desarrollar unsoftwareenfocado a producción y, de hecho, la herramienta carece
de muchas funcionalidades que serían deseables en cualquier aplicación en producción que se encuadrara dentro de su categoría.
Claramente, se ha obtenido un sistema multiusuario y con una seguridad más que acepta- ble, considerando que no se trata de aplicaciones críticas tales como las bancarias, etc. El uso
de protocolos seguros, en este caso HTTPS:// y WSS://, junto contokensde autorización, dan
al sistema soporte para una seguridad más que aceptable.
Por otro lado, también se ha obtenido un sistema fácilmente extensible. En el lado del ser- vidor, el enfoque basado en módulos, exigido por Elixir, facilita mucho este requisito. Esto,
junto con el uso decontext modules, que separan los módulos de negocio del resto y los agru-
pan por áreas, hacen elbackend extremadamente fácil de extender y comprender, sin mayor
complejidad. Como añadido, el uso de GraphQL hace la ampliación de la API del servidor, prácticamente, trivial; puesto que extender el esquema GraphQL no resulta para nada com- plejo, una vez disponemos de una base, con un mínimo conocimiento del lenguaje. En el lado cliente, también disfrutamos de una gran facilidad para la extensión: la sustitución del cliente GraphQL por otro no debería de resultar un proceso dramático, reemplazar Redux por otra solución FLUX, tampoco sería difícil, y el enfoque de la interfaz de usuario, como un árbol je-
rárquico de componentes, hacen muy sencilla su modificación. En resumen, tenemos la base de un software muy flexible a la hora de adaptarse a cambios.
Gracias a la acertada arquitectura adoptada, haciendofrontendybackend, prácticamente,
independientes, reemplazar un frontend por otro es extremadamente fácil y nada propenso
a errores. Esto permitiría que los usuarios dispusieran de una GUI moderna, al tiempo que
podemos conservar elbackendinalterado por largos períodos de tiempo.
Por último, el software obtenido es colaborativo, ya que soporta múltiples usuarios co- laborando, valga la redundancia, en un mismo recurso. Dicho esto, hemos de comentar que se ha llegado a la conclusión de que las operaciones GraphQL de suscripción son adecuadas para notificaciones, alarmas, etc. pero no así para edición de texto colaborativa. Esto viene dado porque existe cierta probabilidad de que se generen conflictos, entre clientes editando el mismo recurso de forma simultánea. Este problema resulta casi inevitable, a no ser que se acometa la implementación de una lógica extremadamente compleja de integrar, lo cual ca- rece de sentido, actualmente, puesto que existen soluciones más simples susceptibles de una integración indudablemente más sencilla. Por ejemplo, usando tipos de datos replicados li-
bres de conflictos, empleando elbackendcomorelay. Otro comportamiento que se debe tener
en cuenta, referente a las suscripciones, es aquel que consiste en que una suscripción envía la notificación del resultado tanto a los usuarios suscritos como al emisor del evento origen de la notificación. Esto hace que el usuario que ejecuta la mutación GraphQL, causante del disparo de la suscripción, reciba el resultado de la misma por duplicado. Esto tiene especial relevancia en la edición de texto compartido, puesto que si no se eliminan las respuestas duplicadas, se generan comportamientos no deseados complicados de depurar.