Cargando...
La innovación, nuestra razón de ser
Cuando, hace unos días, os hablaba acerca de la adaptabilidad y mantenimiento, hacía, entre otras cosas, referencia a que aplicamos una serie de patrones y pautas en la forma en la que abordamos nuestros proyectos y productos.
Lógicamente es un tema muy amplio porque más allá del manido hay que hacer las cosas bien, la definición de lo que está bien es muy subjetiva, depende del individuo, de lo que estamos haciendo e incluso de la tecnología subyacente. Por todo esto hoy me quería centrar, en exclusiva, en lo que es nuestra forma dentro del desarrollo frontend (Web) y en particular como abordamos los proyectos con React
.
He de reconoceros que la respuesta no es fácil. Si bien es cierto que, dentro de Proxia®, soportamos cualquier tipo de framework o librería de frontend (Angular, Vue, …) no lo es menos que hay que tomar decisiones con el objeto de garantizar esa capacidad de mantenimiento a futuro que nos caracteriza.
Podía haber optado por otra cosa, pero, la verdad, es que en aquel momento me pareció la mejor decisión desde el punto vista de agregación y composición de servicios diversos dentro de un portal web, ofreciéndome un equilibrio de características que me parecían básicas tales como: uso en el mercado, funcionalidad, menor dogmatismo – más grados de libertad – y una mayor simplicidad a la hora de definir un frontend no monolítico y orquestado desde la capa de backend.
En cualquier caso, las decisiones no son inamovibles y menos en un mercado tan cambiante como el tecnológico en el que la frase de Heráclito sobre el cambio y la permanencia tiene una aplicación perfecta.
Vaya pregunta, ¿no? React es React. Bueno, si y no, ya sabéis que tenemos dos visiones alternativas la funcional y la basada en clases. En nuestro caso opté por una aproximación funcional utilizando, por tanto, hooks y componentes.
Esta decisión la apoye en dos aspectos. Por una parte, en que la propia tendencia de evolución de React apuntaba en esa línea y, por otra, en que se trata de una aproximación a mi juicio más ligera y, por tanto, más fácil de comprender.
En cualquier caso, soy totalmente consciente de que esta aproximación funcional no es perfecta, que gestiona de forma un tanto obtusa algunos conceptos y que la ligereza va en contra, muchas veces, de la claridad. Pero, como sabéis, en realidad, nunca hay soluciones perfectas, solo soluciones y lo importante es saber las limitaciones de las mismas.
La verdad es que no ha sido un camino fácil ni en línea recta. Hemos pasado por varios estadios de evolución hasta llegar a un escenario como el que os represento en la siguiente figura.
Como podéis comprobar nos encontramos con una serie de servicios transversales que incluyen:
y apoyada por las capacidades de gestión de idiomas y traducciones de Proxia®.Sobre estos servicios transversales se construye, por tanto, la parte específica de cada proyecto, en la que seguimos un esquema como el siguiente:
Entrando en detalle, nos encontraríamos con:
para la construcción del proyecto, básicamente porque es un lenguaje tipado y nos ofrece las ventajas de un contrato claro y bien definido.de los endpoints del servidor. Esta capa nos permite autogenerar tanto código para el acceso a dichos endpoints como interfaces que representan la información que el servidor espera de nosotros. Como podéis ver, en realidad, no estamos inventando nada nuevo, simplemente aplicamos conceptos y arquitecturas ya conocidas a un entorno como el de desarrollo Web.
Pero, claramente, el uso consciente y controlado de una forma de trabajar bien definida nos permite ofrecer a nuestros clientes una garantía en cuanto a mantenimiento de nuestras soluciones y una facilidad en la incorporación futura de nuevos cambios.
Si te interesa lo que hacemos y lo que podemos hacer juntos no dudes en aplicar a nuestras ofertas de empleo.
Los iconos empleados son cortesía de Flaticon
David Rodríguez AlfayateDirector de Tecnología, Productos y proyectos especiales
