Una de las decisiones más importantes a la hora de generar un software nuevo es la arquitectura en la que se apoyará.
De forma habitual, las ingenierías han optado por desarrollos monolíticos, centrándose mucho en el backend y supeditando el frontend a él. Esto deriva en una pérdida de flexibilidad que complica más la evolución y actualización de la aplicación y que, además, perdía potencial al no poder reutilizarse.
Con el paso de los años, las empresas más vanguardistas han dejado atrás este tipo de estructuras para decantarse por arquitecturas desacopladas o modulares. Desde que se ha introducido esta innovación, se logran beneficios como la posibilidad de reutilizar componentes y la facilidad para modificar una de las dos partes sin afectar a la otra.
En ese sentido, Digital55 es una de las empresas pioneras a la hora de aplicar esta filosofía. Durante su ponencia en una de las últimas ediciones de las conferencias de CodeMotion explicaron este enfoque modular en mayor profundidad. Os dejamos a continuación un resumen de la información que compartieron y por qué las ingenierías deberían plantearse el uso de una arquitectura modular.
LA ARQUITECTURA MONOLÍTICA
Una división básica pero muy común entre metodologías de desarrollo es la que distingue arquitecturas monolíticas y desacopladas. El criterio que considera es la unión o separación de backend y frontend.
La más tradicional es la que se conoce como monolítica: todo en la plataforma es una sola aplicación, un bloque de código, un mismo programa.
Con este desarrollo, que normalmente requería siempre perfiles full stack, la base de datos, la lógica de negocio y la interfaz que se muestra al usuario se encontraban integradas dentro de una misma aplicación monolítica, de ahí su denominación.
Este tipo de estructuras requieren esfuerzos adicionales ante cualquier cambio o actualización. Por ejemplo, si se quiere desplegar la plataforma para múltiples soportes, será necesario también contar con múltiples bases de código. De igual manera, cualquier modificación en la interfaz suele conllevar cambios en la lógica de la aplicación, al encontrarse ambas partes estrechamente ligadas. Es, por tanto, una estructura difícilmente escalable.
El trade off es también mucho más complicado por distintos motivos:
Además, si tenemos equipos 100% full stack y arquitecturas monolíticas cerradas, el código no es reutilizable la mayoría del tiempo, no está acoplado. Tocaría repetir los códigos en distintos sitios y para distintos usuarios, complicando así el mantenimiento de la aplicación.
EL PASO DE MONOLÍTICO A MODULAR
El paradigma de programación monolítica comenzó su transición gracias a la aparición del primer iPhone, en 2007. Con él, surgía la necesidad de desarrollar aplicaciones que funcionaran en distintos dispositivos, adaptándose así a este smartphone y ampliando su mercado. Y este deseo se fue viendo incrementado con el lanzamiento de nuevos dispositivos, como los smartwatches.
Por el esfuerzo extra que suponía, la arquitectura monolítica dejaba de ser la opción principal para hacer aplicaciones capaces de funcionar en móviles, portátiles, relojes, televisores… Se recurre entonces a la separación de los datos de las interfaces que están manejando, con lo que se consolida el paso a la arquitectura desacoplada.
Esta evolución también deriva en el auge de paradigmas de agile development, donde la aplicación está en constante cambio y evolución. En este punto, dejamos de hablar de aplicaciones y comenzamos a hablar de plataformas digitales, preparadas para adaptarse a nuevas necesidades, dispositivos y modos de navegación.
La metodología de desarrollo también se modifica y se empieza a pensar en el diseño para distintas plataformas, con el indiscutible protagonismo del responsive. También enfoques como el de MVP (Producto Mínimo Viable), a partir del cual se suelen hacer más revisiones de diseño y tests A/B hasta llegar a una versión inicial, que continuará evolucionando.
Otra de las consecuencias más visibles es que lenguajes que, al menos hasta hacía poco, ocupaban una posición muy secundaria comienzan a resurgir. El mayor ejemplo es JavaScript, que al principio se usaba principalmente para incluir animaciones.
Sin embargo, aquí JavaScript comienza a destacar tanto por su gestión de la asincronía como por no seguir un flujo de ejecución lineal, sino ser programación orientada a eventos. En respuesta a una acción del usuario (clic en un botón, scroll, hover…) se desencadenan una serie de eventos. Todo ello permite comenzar a trabajar en frontend directamente, separándolo de la lógica del backend. Es por todo ello por lo que se convierte en el principal lenguaje de frontend, diseñado de cara a la interacción con el usuario. También debemos mencionar su estructura jerárquica, que permite la reutilización de componentes. Además, el amplio ecosistema de frameworks y librerías JavaScript contribuyó aún más a convertirlo en uno de los lenguajes más sonados del desarrollo de software.
Como expusieron los compañeros de Digital55, gracias a esto se pudieron modularizar las plataformas, separando:
Esto es ahora una forma muy común de trabajar, pero el poder desligar estos polos ha generado precisamente una separación entre desarrolladores front y back, más marcada hoy en día. De hecho, desde Digital55 se está desarrollando un proyecto en el que la propia parte de backend comienza a tener divisiones internas. Esto es lo que se denomina como “microservicios” y que permite, además de una gestión más sencilla y organizada, una especialización todavía mayor en el equipo.
LA ARQUITECTURA MODULAR O DESACOPLADA
Una arquitectura digital preparada para el cambio es modular o desacoplada, es decir, aquella que aísla en el frontend la capa de interacción con el usuario final del backend. Para lograr que estos dos polos se comuniquen entre sí, se recurre a APIs. Estas APIs exponen los datos y la lógica de negocio estrictamente necesaria, con lo que la seguridad de estas arquitecturas tiende a ser mayor.
Podemos mantener nuestros datos centralizados en el back, con la ventaja de que, realizando peticiones a través de la interfaz de comunicación (API), podemos tener de forma más sencilla aplicaciones para distintos dispositivos: iOS, Android, navegadores web… Esto ocurre gracias a que la interfaz de usuario se ejecuta como aplicaciones independientes en los soportes necesarios.
VENTAJAS DE LA SEPARACIÓN ENTRE FRONT Y BACK
Digital55, que desde hace años ha apostado por esta visión, conoce en profundidad los beneficios que tiene esta división para todo tipo de empresas y, en concreto, para las ingenierías. En base a su experiencia, desarrollamos a continuación los puntos esenciales:
Una de las principales ventajas para Negocio es que, al estar separado, permite contar con equipos de desarrollo distintos e independientes, en los que colaboran perfiles muy específicos e incluso se puede externalizar a proveedores muy especializados, dedicados únicamente a front o a back, que, por lo tanto, suelen conocer más al detalle los desarrollos que les tocan. Se deja de depender únicamente de profesionales fullstack y cada persona del equipo puede trabajar en tecnologías en las que son expertos, logrando un resultado más versátil.
Simplifica el desarrollo en múltiples soportes, llegando a un público mucho más amplio. La logística se ve facilitada gracias a las innovaciones en cloud, de forma que al actualizar una aplicación, pueda encontrarse automáticamente disponible para todo el mundo.
Además de aumentar las posibilidades de desarrollo para distintos dispositivos, favorece la independencia de la plataforma, tecnología y formato de los datos de backend. Con ello, se abre la posibilidad de utilizar una gran variedad de lenguajes de programación y filosofías de diseño.
Evita que los cambios en la experiencia de usuario alteren el backend. Al desligar la lógica de los datos de la interfaz visible, se gana una mayor flexibilidad para actualizar el backend o el diseño de forma independiente, sin afectar a la otra. Esto permite al departamento de Negocio centrarse en el usuario final, en ofrecerle la mejor experiencia posible. Podrán hacer cambios y pruebas de cara al usuario sin afectar a la lógica de negocio. Esto se veía muy limitado en arquitecturas monolíticas, pues traía consigo modificaciones también en el backend y, por tanto, había que evaluar si se contaba con suficientes recursos.
Por esta misma separación, se trata de una arquitectura mucho más escalable: es posible que una de las dos partes necesite más recursos en un momento dado, siendo más fácil actuar únicamente sobre los de esa parte, en vez de en ambas.
Las arquitecturas monolíticas son más difíciles de gestionar y tienen ciclos de desarrollo más altos. Cualquier cambio implementado puede afectar a otros elementos y aspectos de la base de datos. Con una arquitectura desacoplada, se facilitan mucho la evolución continua, el testing A/B y la medición y, con ello, la política de mejora permanente de aplicaciones. Además, los ciclos de desarrollo son más cortos y se logran migraciones y actualizaciones más sencillas.
El sector de la ingeniería se vería especialmente beneficiado de esta separación por diversos motivos. Como ya se había comentado previamente, es habitual que las empresas dedicadas a la ingeniería requieran diversas aplicaciones, llegando incluso a contar con una propia para cada proyecto que gestionan.
Desarrollar y mantener un catálogo tan amplio de aplicaciones supone un importante esfuerzo, tanto económico como de optimización de tiempos. Si se tuviera que crear una plataforma desde cero para cada caso o fin, el mantenimiento se complicaría demasiado.
Para este caso, la separación entre el back y el front supone una importante ventaja, en tanto que pueden reutilizar componentes creados con anterioridad. De hecho, una buena idea es generar una biblioteca de componentes que puedan servir para otros proyectos.
Con esto, además de la reducción de costes, se aceleran mucho los tiempos de desarrollo. También permite, entre otras cosas, reducir el número de incidencias, pues se utilizan componentes que ya han sido testados y revisados en varias ocasiones.
Si tras conocer las ventajas de la arquitectura desacoplada te estás planteando actualizar tus desarrollos o buscas ayuda con algún nuevo proyecto, no dudes en contactar con Digital55 y contarles tu idea para que puedan asesorarte.
Nuestros asociados
