051.2 Lección 1

Cuando utiliza sistemas online, es muy probable que en algún momento se haya encontrado un mensaje como el de Ejemplo cuando una respuesta esta marcha.

Retrocedamos un poco y observemos el contexto en el que está viendo este mensaje. Supongamos que está intentando obtener acceso a su cuenta bancaria a través del sitio web de su banco. Cuando intenta acceder al sitio web bancario desde su computadora portátil, utiliza un tipo de software (es decir, aplicación) llamado navegador web, como Google Chrome o Firefox. En este caso, el navegador de su computadora envía una solicitud a otra computadora que aloja el sitio web. Este tipo particular de computadora se llama servidor. Está especialmente diseñado para funcionar las 24 horas del día, los 7 días de la semana, y siempre atiende nuevas solicitudes provenientes de todas partes del mundo.

Entonces, un servidor es una computadora, igual a la que se usas para trabajar, jugar videojuegos y realizar tareas de programación. Sin embargo, existe una diferencia principal: un servidor normalmente utiliza todos sus recursos para la aplicación de software que se ejecuta en este. En este ejemplo, el software es una aplicación web, un programa informático que se ejecuta en el servidor.

En Ejemplo cuando una respuesta esta marcha, el servidor ha recibido una solicitud de un navegador y la aplicación que se ejecuta en el servidor está procesando la operación resultante. Esta operación podría consistir en consultar una base de datos para obtener los datos de un usuario en el banco o comunicarse con otro servidor para verificar un descuento especial en el próximo pago del usuario.

En este ejemplo, llamamos al navegador que se ejecuta en su máquina la aplicación cliente, o simplemente, el cliente. El cliente interactúa con el servidor remoto.

La comunicación de red entre el cliente y el servidor puede tener lugar dentro de una red empresarial o a través de la red mundial que llamamos Internet. Una característica común de la interacción cliente-servidor es que un servidor puede establecer múltiples relaciones con múltiples clientes. Pensemos en el ejemplo anterior: el sitio web de un banco alojado en un servidor puede atender miles de solicitudes por minuto desde múltiples ubicaciones, cada una con un usuario diferente intentando acceder a su cuenta bancaria personal.

No todos los escenarios están estructurados como un navegador que interactúa con un servidor que realiza casi todo el procesamiento. En algunos casos, el cliente puede ser la instancia principal de procesamiento; este concepto se denomina cliente pesado (o thick client), donde el cliente almacena y procesa la mayoría de las tareas en lugar de depender de los recursos del servidor. En nuestro ejemplo bancario, por el contrario, el navegador es un cliente ligero (o thin client), que depende del servidor para calcular y devolver información a través de la red.

Un ejemplo de cliente pesado es una aplicación (de escritorio) de videojuego, donde la mayor parte del almacenamiento y procesamiento de datos se realiza localmente, utilizando la GPU, RAM, CPU y espacio en disco de la computadora para procesar la información. Una aplicación de este tipo rara vez depende de un servidor externo, eespecialmente si el juego se juega/disfruta sin conexiónA difierencia de SPA.

Ambos enfoques tienen ventajas y desventajas: para un cliente pesado, la inestabilidad de la red es un problema menor en comparación con un cliente ligero que depende de un servidor remoto, pero las actualizaciones de software pueden ser más difíciles de aplicar y el cliente pesado requiere más recursos informáticos. Para un cliente ligero, los costos más bajos podrían ser una gran ventaja. Para cualquier tipo de cliente, proporcionar datos personales a una aplicación de terceros puede ser un problema.

Una aplicación web es un software que se ejecuta en un servidor; procesa las interacciones del usuario y es contactado por clientes pesados o ligeros a través de una red informática. No todos los sitios web se consideran aplicaciones web: las páginas web estáticas simples sin interactividad no se consideran aplicaciones web porque el servidor no ejecuta una aplicación para procesar las acciones solicitadas por el cliente.

Muchas aplicaciones web se pueden dividir en dos grupos: la aplicación de una sola página (SPA - single page application) y la aplicación de varias páginas (MPA - multi page application). Una SPA tiene una sola página web, donde se produce todo el intercambio y carga de datos sin necesidad de redirigir al usuario a otra página web dentro de la aplicación. A diferencia de SPA, una MPA tiene múltiples páginas web. Un cambio de datos podría actualizar la misma página web que originó la acción o redirigir al usuario a otra página web.

Considere el ejemplo anterior, donde un usuario desea verificar las transacciones de su cuenta más recientes en el sitio web de su banco. Imagine que se produce una transacción después de cargar la página web. Si la aplicación web del banco es un SPA, la nueva transacción se mostrará automáticamente en la misma página web, sin redirigir al usuario a una nueva página. Si el usuario consulta sus préstamos, la nueva información también se muestra en la misma página, evitando la necesidad de redirección. Modificar la página sin redirigir al usuario facilita la navegación. Para un MPA, cuando el usuario solicita la página web de préstamo, el servidor debe redirigir al usuario a una nueva ubicación, es decir, a otra página web.

Un famoso ejemplo de aplicación web SPA, es Google Mail (Gmail). No redirige al usuario a una página completamente nueva cuando, el usuario desea mostrar la carpeta de spam, ya que la aplicación simplemente actualiza la parte específica de la pantalla que muestra todos los mensajes de spam y permanece en la misma página web.

Por otro lado, una aplicación MPA es Amazon.com, el gigante del comercio electrónico, donde cada artículo se ubica en una página web distinta.

Una ventaja de una MPA sobre una SPA es que los análisis web son mucho más fáciles de recopilar y medir. Esto es crucial para ayudar a los desarrolladores a optimizar los resultados de búsqueda en Internet. Normalmente, una aplicación web se divide en dos partes: frontend y backend. El fronted (o interfaz) es la capa de vista, donde el usuario interactúa con un navegador utilizando los elementos de la página haciendo clic, seleccionando o escribiendo. Aquí es donde los datos del servidor se reciben, se formatean y se muestran al usuario a través del navegador.

El backend es generalmente la parte más grande de una aplicación web. Comprende la lógica empresarial, los controladores de comunicación, la mayor parte del procesamiento de datos y el almacenamiento de estos. El almacenamiento de datos se realiza a través de un sistema de gestión de bases de datos independiente conectado al backend.

El frontend y el backend se comunican entre sí. Las solicitudes de datos son reenviadas por el frontend al backend, y el frontend recibe, formatea y muestra los datos devueltos por el backend al usuario.

En nuestro ejemplo anterior de obtener la última transacción en la cuenta bancaria de un usuario, la acción es interpretada por el frontend de la aplicación, que se ejecuta en el navegador del escritorio del usuario. Luego, esta solicitud se envía al backend de la aplicación, que valida si el usuario tiene permiso para realizar la acción, recupera los datos y devuelve la lista de transacciones al frontend cargado en el navegador. Luego, el navegador formatea y muestra los datos al usuario.

Ningún software es útil sin comunicarse con componentes internos y externos. Entonces, ¿cómo puede comunicarse el cliente con la aplicación web? ¿Cómo puede el frontend enviar datos al backend?

Las aplicaciones de software se comunican entre sí a través de una interfaz de programación de aplicaciones (API - Application Programming Interface), que se ejecuta a través de protocolos básicos de comunicación de Internet. Los protocolos son estándares y reglas desarrollados para garantizar que dos o más aplicaciones intercambien comandos y datos.

El principal beneficio de una API es desacoplar diferentes partes de la aplicación y al mismo tiempo permitirles cooperar en el procesamiento de datos. Las API también centralizan el flujo de datos en canales predefinidos, actuando como una puerta de enlace que garantiza que todos utilicen el mismo camino para ir y venir. En las aplicaciones web, las API son vitales para la funcionalidad de la aplicación, ya que permiten la interacción del usuario, la entrega de información procesada, solicitudes de almacenamiento de datos y muchas otras tareas. El cliente puede utilizar una API para solicitar acciones que se ejecutarán en el servidor, por ejemplo.

Volvamos al ejemplo de la aplicación web bancaria. Para iniciar sesión en una cuenta a través de una aplicación web, el usuario generalmente escribe datos como nombre de usuario y contraseña en ciertos campos de texto y luego hace clic en el botón "Iniciar sesión". El navegador toma esta información y llama a una API de backend. La aplicación web que se ejecuta en el servidor remoto recibe los datos del usuario, los valida, verifica el derecho del usuario a obtener acceso y finalmente envía una respuesta al navegador. Para que el usuario se comunique con el servidor, es obligatorio que tanto el cliente como el servidor envíen datos de un lado a otro. Eso es lo que permiten las API.

Tenga en cuenta que la aplicación web del banco no expone otra información confidencial; muestra al usuario solo los campos que están permitidos y son necesarios para una interacción deseada. El resto está oculto al usuario.

La comunicación entre API puede basarse en diseños y protocolos muy diferentes. El protocolo de transferencia de hipertexto (HTTP - Hypertext Transfer Protocol) es el protocolo más utilizado en aplicaciones web. Hipertexto es texto con enlaces a otros textos, concepto que subyace a los enlaces en las páginas web HTML. Los hipervínculos constituyen así la base para construir páginas web y mostrarlas en los navegadores.

HTTP fue diseñado para aplicaciones cliente-servidor, donde los recursos se solicitan desde un servidor y luego se devuelven al cliente a través de la red utilizando una estructura predefinida especificada por el protocolo HTTP.

Para una aplicación web estructurada, los ingenieros de software diseñan la aplicación con partes o módulos separados. Esta separación de responsabilidades permite tareas y responsabilidades claramente definidas, resultando así un desarrollo más rápido y un mejor mantenimiento. Tomemos, como ejemplo una aplicación con dos módulos internos: uno que implementa la lógica empresarial y el otro que depende de una integración de terceros. Este tercero es una empresa externa que proporciona su API para algún propósito específico, ejemplo: pronóstico del tiempo. Si el servidor meteorológico no funciona, es imposible obtener detalles meteorológicos, y si estos datos son cruciales para el resultado final, el usuario puede experimentar algunos dolores de cabeza temporales si no hay una fuente alternativa para los datos.

Ahora imagine que se reemplaza este proveedor externo y el nuevo tiene una forma diferente de manejar la misma API. La separación de módulos significa que los desarrolladores tendrán que actualizar solo ese módulo. La lógica de negocios en el otro módulo no necesita ser tocada en absoluto, o al menos requiere actualizaciones mínimas.

La necesidad de estructuras de procesos claras también influye en el diseño de las API para facilitar su uso. El concepto de transferencia de estado representacional (REST - Representational state transfer) es un estilo de arquitectura con un conjunto de pautas para diseñar e implementar el acceso a los datos en una aplicación.

Hay seis principios REST. Para simplificar, vamos a explicar tres que son más relevantes para esta lección:

Las API que siguen los principios REST se denominan RESTful y, en la web moderna, muchas aplicaciones web siguen el diseño REST. Aunque una API RESTful no necesita implementar estos principios utilizando el protocolo HTTP, se usa casi universalmente en el modelo REST dada su solidez, simplicidad y universalización en el entorno web.

Existen docenas de estilos y estándares de arquitecturas que intentan organizar las estructuras de las aplicaciones web. Como casi todo en el mundo de la informática, no hay un "ganador", sólo un conjunto de pros y contras para cada modelo. Un paradigma importante es la llamada arquitectura de microservicios, que se creó como alternativa a la antigua arquitectura monolítica.

La arquitectura de microservicios es un modelo de software compuesto por múltiples servicios interdependientes que juntos forman la aplicación final. Esta arquitectura tiene como objetivo descentralizar el código base en múltiples capas de software que se dividen en múltiples aplicaciones más pequeñas para un mejor mantenimiento (Arquitectura de microservicio).

Por el contrario, una arquitectura monolítica contiene todos los servicios y recursos de la aplicación en una sola aplicación (Arquitectura monolítica).

Las imágenes muestran que el modelo de microservicio está descentralizado y la aplicación depende de múltiples servicios, cada uno con su propia base de datos, código base e incluso recursos de servidor. Como su nombre lo indica, cada microservicio debe ser más pequeño que su contraparte monolítica, que asume la responsabilidad de todos los servicios.

La aplicación monolítica encapsula todos sus recursos en una sola unidad. Toda la lógica empresarial, los datos y el código base están centralizados en un bloque enorme, por lo que se llama “monolito”.

Los usuarios apenas notan si una aplicación web se está ejecutando como un modelo monolítico o de microservicio; la elección debe ser transparente. Nuestra aplicación bancaria, por ejemplo, podría ser un monolito donde toda la lógica empresarial relativa a pagos, transacciones, préstamos, etc. esté ubicada en el mismo código base ejecutándose en uno o más servidores. Por otro lado, si la aplicación bancaria utiliza un estilo de microservicio, probablemente tenga un microservicio dedicado a procesar pagos y otro microservicio solo para emitir préstamos. Este último microservicio llama a otro microservicio más para analizar la probabilidad de que el solicitante incumpla el pago. La aplicación podría tener miles de servicios más pequeños.

El enfoque monolítico requiere una mayor sobrecarga de mantenimiento cuando la aplicación crece, especialmente con varios equipos codificando en la misma base de código. Dados los recursos de software centralizados, es muy probable que un equipo cambie algo que rompa la parte de la aplicación del otro equipo. Esto podría ser un verdadero dolor de cabeza para los equipos más grandes, especialmente cuando hay una gran cantidad de estos.

Los microservicios son mucho más flexibles en ese sentido, porque cada servicio es gestionado por un solo equipo. Por supuesto, un equipo puede gestionar más de un servicio. Los cambios de código se realizan fácilmente y los recursos en competencia no son un problema real. Dado que cada servicio está interconectado, cualquier punto de falla podría tener un impacto negativo en toda la aplicación. Además, dado que existen múltiples instancias de bases de datos, servidores y API externas que se comunican entre sí, la resiliencia de toda la aplicación es tan buena como la de su microservicio más débil.

Una ventaja del enfoque monolítico es tener una fuente de datos centralizada, lo que facilita evitar la duplicación de datos. El enfoque también reduce el consumo de recursos de la nube, porque un servidor más grande necesita menos recursos informáticos que varios servidores descentralizados. Una aplicación de microservicio de aproximadamente el mismo tamaño supone una carga mayor para la nube.