En este sitio web utilizamos cookies para mejorar tu experiencia de navegación y entender mejor tua preferencias. Eso nos ayuda a entenderte mejor y a centrarnos en aquellos tópicos que son de tu interés. Por favor, acepta nuestro uso de cookies.
Frecuentemente, cuando desarrollamos productos digitales basados en componentes web, de manera consciente o inconsciente, aplicamos los principios del paradigma de orientación objetos, aquellos referidos habitualmente a través de sus siglas en ingles SOLID. Este hecho conduce a solucionesbien formadas, sólidas y robustas. Sin embargo, con frecuencia este tipo de problemas requiere de aproximaciones divergentes que aplican técnicas y modelos arquitectónicos de metaprogramación más propios del paradigma clásico de la orientación a componentes. Se trata, en este sentido, de idear soluciones con una capacidad de adaptación plástica y dinámica al contexto arquitectónico de uso particular que sean capaces de elevar las cotas de reutilización potencial de los activos construidos.De acuerdo a estas ideas, el foco no está tanto en la construcción de los componentes idóneos para resolver problemas particulares sino de ser capaces de crear estrategias de transformación adaptativa que provoquen cambios puntuales irreversibles sobre la estructura y comportamiento de los componentes y de encapsular esas estrategias en activos arquitectónicos de primer nivel para contribuir de maneraformal y sistemática sobre el cuerpo de cualquier componente.
Los procesos de construcción de soluciones de software pasan habitualmente por la creación de arquitecturas sólidas. Este tipo de diseños son aquellas que cumplen con los principios fundacionales del paradigma de la orientación a objetos, de sus siglas en inglés SOLID. Sin embargo, en ocasiones resulta conveniente aplicar otro tipo de estrategia para la creación de software. Esto es especialmente cierto en aquellos casos en los que se pretenda dar con soluciones que resulten flexibles y plásticamente adaptables a distintos contextos de uso. El uso de determinadas técnicas y modelos de diseño arquitectónico tal es como el uso de traits, mixins, roles, aspectos o subjects, propios del paradigma de la orientación a componentes, es de aplicaciónen estos casos. Muchos lenguajes, de hecho, invitan a llevar a cabo un proceso de ideación de soluciones basado en estas técnicas dando lugar a soluciones más flexibles y dinámicamente cambiantes a tenor de las condiciones ambientales. A lo largo de esta charla se hace un recorrido exhaustivo de este paradigma arquitectónico revisando los principios, técnicas y modelos sobrela base del stack tecnológico de la plataforma web.
Dentro del mundo de la computación distribuida, la orientación a servicios ha sido el paradigma arquitectónico de mayor aplicación recurrente. En efecto, hoy por hoy cualquier solución desarrolla y despliega su parte back de acuerdo a una colección de servicios que expone el modelo de información requerido. En ese sentido, se ha alcanzado un alto grado de madurez a través de un recorrido evolutivo que abarca los últimos 20 años, llegando a un consenso aceptado de usar REST como la aproximación arquitectónica más conveniente y habitual. Sin embargo a la hora de diseñar servicios aplicamos recurrentemente los mismos esquemas sin pararnos a pensar la adecuación con respecto al espacio del problema. Lo cierto es que dentro de las aproximaciones orientadas a recursos existen distintos modeloso estilos arquitectónicos que pueden utilizarse a la hora de diseñar el protocolo de interacción con losservicios. En esta charla haremos un recorrido de los fundamentales modelos de diseño de APIs de servicios que pueden desarrollarse para cada tipo de problema. Además ofreceremos técnicas y patrones de diseño aplicables para cada uno de estos modelos.
El desarrollo de soluciones digitales se ha enfocado, de manera convencional, como un proceso que nacedel diseño formal y sistemático de modelos de información que se desarrollan y despliegan en el lado del servidor. Solo entonces son consumidos por clientes específicos que elaboran solucionesvisuales a medida para los modelos de información así diseñados. Esta aproximación implica grandes ventajas con respecto a los desarrolladores de back que gozan de libertad absoluta en cuanto a la toma de decisiones refería a cómo diseñar los modelos de información subyacentes y cómo exponerlos en base a un espacio de recursos de acuerdo a los principios de las arquitecturas REST. Sin embargo, esta aproximación es penalizante en relación a los esfuerzos ímprobos que tienen que hacer los equiposde front para adaptarse de manera recurrente y sistemática a la demanda cambiante de la parte del back.Se impone, en este sentido, una inversión de control relacionada con la forma en la que deben ser enfocados los esfuerzos de desarrollo. Dado que los modelos de interacción en la parte del front son recurrentes y limitados, tiene sentido permitir que sean los desarrolladores de esta parte los que dirijan los procesos constructivos demandando a los desarrolladores de back que expongan un modelo de interrogación y respuesta adaptado a las necesidades visuales y interactivas que demanda la interfaz.