UT01 Arquitecturas Web
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<title>UT01 Arquitecturas Web</title>
</head>
<body>
<blockquote>
<strong>En este tema trabajaremos los siguientes RAs:</strong>
<ul>
<li>RA1. Selecciona las arquitecturas y tecnologías de programación Web en entorno servidor, analizando sus capacidades y características propias.</li>
</ul>
</blockquote>
<h1>UT01 Arquitecturas Web</h1>
<div style="border:1px solid #2196f3;background:#f1f8ff;padding:10px;margin:10px 0;">
<strong>¿Qué vamos a aprender en esta unidad?</strong><br>
En esta unidad vamos a aprender los conceptos básicos de las arquitecturas web. Para ello empezaremos analizando los principios SOLID, los patrones de diseño y las arquitecturas de software más comunes.
También veremos cómo se relacionan con el desarrollo de aplicaciones web del lado del servidor (backend) y cómo se utilizan en la práctica.
</div>
<h2>Introducción</h2>
<p>
Una <strong>página web estática</strong> es aquella cuyo contenido no cambia en función de la interacción del usuario o del contexto. Estas páginas están compuestas principalmente por archivos HTML y CSS, que se almacenan en un servidor y se envían tal cual al navegador del usuario. El servidor simplemente "sirve" estos archivos, sin procesamiento adicional.
</p>
<p>
Las aplicaciones web modernas requieren mayor interactividad y personalización, lo que nos lleva a la necesidad de páginas web dinámicas, donde el contenido cambia según la interacción, datos de bases de datos o servicios externos.
</p>
<p>
Las aplicaciones web modernas se basan en la arquitectura cliente-servidor. Los clientes (navegadores web) realizan peticiones al servidor, que responde enviando los recursos solicitados, como se ve en el esquema siguiente:
</p>
<img src="https://upload.wikimedia.org/wikipedia/commons/thumb/c/c9/Client-server-model.svg/1920px-Client-server-model.svg.png" alt="Arquitectura Cliente-Servidor"/>
<p>
El cliente realiza peticiones al servidor, habitualmente usando el protocolo HTTP. El servidor procesa la solicitud y responde con el contenido adecuado.
</p>
<p>Existen dos formas principales de generar páginas dinámicas:</p>
<ul>
<li><strong>Procesamiento en el servidor:</strong> El servidor genera contenido dinámico usando lenguajes como PHP, Python, Ruby, Java, .NET, etc.</li>
<li><strong>Consumo de servicios externos desde el cliente:</strong> El navegador usa JavaScript para solicitar datos a servicios REST y actualizar la página dinámicamente.</li>
</ul>
<h2>Arquitectura Cliente-Servidor</h2>
<p>
El modelo cliente-servidor reparte tareas entre los proveedores de recursos (<strong>servidores</strong>) y los consumidores (<strong>clientes</strong>), habitualmente comunicándose a través de una red, aunque pueden residir en la misma máquina en desarrollo.
</p>
<ol>
<li>El usuario solicita una URL desde el navegador web.</li>
<li>El servidor recibe la <strong>petición</strong> HTTP y la procesa mediante su <strong>lógica de negocio</strong>.</li>
<li>Produce una <strong>respuesta</strong> HTTP, que puede contener archivos HTML, CSS, XML, JSON, multimedia, JavaScript, etc.</li>
<li>El navegador interpreta y representa la respuesta (normalmente página web).</li>
</ol>
<img src="https://darioaxel.github.io/docencia/dam-daw/DWES/images/dwes/arquitectura-cliente-servidor.png" alt="Arquitectura Cliente-Servidor propia"/>
<p>Ventajas:</p>
<ul>
<li><strong>Centralización</strong> del control.</li>
<li><strong>Escalabilidad</strong>: aumentar capacidad de clientes y servidores.</li>
<li><strong>Portabilidad</strong>: independencia del sistema operativo.</li>
<li>Fácil <strong>mantenimiento</strong> y <strong>encapsulación</strong>.</li>
<li>Tecnologías desarrolladas para usabilidad y seguridad.</li>
</ul>
<p>Desventajas:</p>
<ul>
<li><strong>Congestión</strong> de tráfico puede causar sobrecargas.</li>
<li><strong>Caída del servidor</strong> implica falla en las peticiones.</li>
<li>Dependencia de <strong>hardware y software específico</strong>.</li>
</ul>
<div style="border:1px solid #ffc107;background:#fff8e1;padding:10px;margin:10px 0;">
Estas desventajas se refieren a casos sin replicación/distribución. Existen técnicas de escalado que pueden solucionarlo.
</div>
<h3>Ejemplo práctico</h3>
<p>
Usando las herramientas de desarrollador del navegador vamos a observar los pasos al consultar una URL (Campus Virtual FP).
</p>
<ol>
<li>
Abrimos una pestaña en el navegador e introducimos la URL <a href="https://www.campusvirtualfp.com">www.campusvirtualfp.com</a>.<br>
<img src="https://darioaxel.github.io/docencia/dam-daw/DWES/images/dwes/pill-01-campusdigitalfp.png" alt="Acceso a la web y herramientas"/>
</li>
<li>
Abrimos las herramientas de desarrollador y vamos a la pestaña <strong>Network</strong>.<br>
<img src="https://darioaxel.github.io/docencia/dam-daw/DWES/images/dwes/pill-02-campusdigitalfp.png" alt="Herramientas Network"/>
</li>
<li>
Refrescamos la página y observamos:<br>
<img src="https://darioaxel.github.io/docencia/dam-daw/DWES/images/dwes/pill-03-campusdigitalfp.png" alt="Red refrescada"/>
<ul>
<li><strong>whois</strong>: indica la IP del servidor.</li>
<li><strong>builtwith</strong>: analiza los servidores y tecnologías empleadas.</li>
</ul>
</li>
<li>
<img src="https://darioaxel.github.io/docencia/dam-daw/DWES/images/dwes/pill-04-campusdigitalfp.png" alt="Red Accedida"/>
El servidor responde y la información se muestra en el navegador.
</li>
</ol>
<div style="border:1px solid #ff9800;background:#fff3e0;padding:10px;margin:10px 0;">
<strong>Aviso:</strong> Métodos avanzados para analizar servidores pueden ser ilegales fuera del ámbito de ciberseguridad profesional.
</div>
<p>
Pinchando en la petición principal vemos los datos y la respuesta, incluyendo el código HTTP devuelto (<strong>200</strong>).
</p>
<img src="https://darioaxel.github.io/docencia/dam-daw/DWES/images/dwes/pill-05-campusdigitalfp.png" alt="Respuesta servidor"/>
<div style="border:1px solid #8bc34a;background:#f9fff9;padding:10px;margin:10px 0;">
El servidor puede enviar su versión software. Es recomendable configurar para que no se muestre, evitando riesgo de ataques.
</div>
<img src="https://darioaxel.github.io/docencia/dam-daw/DWES/images/dwes/pill-06-campusdigitalfp.png" alt="Headers respuesta"/>
<h2>Generación de páginas web</h2>
<h3>Estáticas</h3>
<p>
Las webs estáticas no actualizan dinámicamente su contenido por interacción del usuario; la misma URL siempre devuelve la misma información, salvo cambios manuales por un desarrollador.
</p>
<h3>Dinámicas</h3>
<p>
Las webs dinámicas generan contenido en función de datos actuales en el servidor, normalmente usando bases de datos y tecnologías que permiten operaciones CRUD (crear, leer, modificar, eliminar).
</p>
<h2>Arquitecturas Web: Capas Físicas y Lógicas</h2>
<p>
Las arquitecturas web modernas usan <strong>capas físicas</strong> (tiers) y <strong>capas lógicas</strong> para organizar funcionalidad y facilitar escalabilidad/mantenimiento.
</p>
<h3>Capas Físicas (Tiers)</h3>
<ul>
<li>Servidor web</li>
<li>Servidor de aplicaciones</li>
<li>Servidor de base de datos</li>
</ul>
<h3>Capas Lógicas (Layers)</h3>
<ul>
<li>Presentación: Interfaz de usuario</li>
<li>Negocio/Aplicación: Lógica de negocio</li>
<li>Datos/Persistencia: Gestión de datos</li>
</ul>
<h3>Modelo MVC (Modelo-Vista-Controlador)</h3>
<ul>
<li><strong>Modelo:</strong> Gestión de datos y acceso</li>
<li><strong>Controlador:</strong> Procesa acciones del usuario y coordina entre modelo y vista</li>
<li><strong>Vista:</strong> Presentación al usuario e interacción</li>
</ul>
<h2>Patrones y tipos de arquitecturas en Servidor</h2>
<h3>Principios SOLID</h3>
<p>
Cinco principios para diseño de software orientado a objetos.
</p>
<a href="https://www.youtube.com/watch?v=E_mSr-VFd3g">Video SOLID</a>
<img src="https://darioaxel.github.io/docencia/dam-daw/DWES/images/dwes/solid-principles.jpg" alt="Principios SOLID"/>
<img src="https://darioaxel.github.io/docencia/dam-daw/DWES/images/dwes/solid.gif" alt="SOLID Animado"/>
<ol>
<li><strong>Responsabilidad única:</strong> Una clase debe tener una sola razón para cambiar.</li>
<li><strong>Abierto/Cerrado:</strong> Clases abiertas a extensión, cerradas a modificación.</li>
<li><strong>Sustitución de Liskov:</strong> Las subclases deben poder sustituir a la superclase sin alterar el funcionamiento.</li>
<li><strong>Segregación de interfaces:</strong> Los clientes no deben depender de interfaces que no usan.</li>
<li><strong>Inversión de dependencias:</strong> Dependencia de abstracciones, no implementaciones concretas.</li>
</ol>
<div style="border:1px solid #8bc34a;background:#f9fff9;padding:10px;margin:10px 0;">
Los principios SOLID fueron introducidos por Robert C. Martin. El acrónimo fue creado por Michael Feathers. El libro <a href="https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0136083239">Clean Code</a> es recomendable.
</div>
<h3>Patrones de Diseño</h3>
<ul>
<li><strong>Patrones de creación:</strong> Singleton, Factory, Builder...</li>
<li><strong>Patrones estructurales:</strong> Adapter, Decorator, Proxy...</li>
<li><strong>Patrones de comportamiento:</strong> Observer, Strategy, Command...</li>
<li><strong>Patrones arquitectónicos:</strong> MVC, Capas, Microservicios...</li>
<li><strong>Patrones de concurrencia:</strong> Mutex, Semaphore, Monitor...</li>
</ul>
<p>
Más información en <a href="https://refactoring.guru/es/design-patterns">Refactoring Guru</a> y <a href="https://github.com/joseluisgs/EntornosDesarrollo-08-2022-2023">Entornos de Desarrollo 8</a>.
</p>
<div style="border:1px solid #8bc34a;background:#f9fff9;padding:10px;margin:10px 0;">
Los patrones fueron popularizados por "Design Patterns: Elements of Reusable Object-Oriented Software", la "Gang of Four".
</div>
<h3>Arquitecturas Software</h3>
<img src="https://darioaxel.github.io/docencia/dam-daw/DWES/images/dwes/arquitecturas.jpeg" alt="Arquitecturas Software"/>
<ul>
<li><strong>Monolítica:</strong> Todo en una sola aplicación. Fácil de desarrollar pero difícil de escalar y mantener.</li>
<li><strong>De capas:</strong> Separación por capas lógicas, mejorando modularidad, mantenibilidad y escalabilidad.</li>
<li><strong>Servicios web:</strong> Servicios independientes que se comunican por protocolos estándar, permitiendo modularidad y escalabilidad horizontal.</li>
<li><strong>Microservicios:</strong> División máxima en servicios pequeños y autónomos, ideal para grandes sistemas pero costoso para pequeños.</li>
</ul>
<div style="border:1px solid #2196f3;background:#f1f8ff;padding:10px;margin:10px 0;">
Aunque los microservicios han sido muy populares, no siempre son la mejor solución; en muchos casos una arquitectura monolítica o de capas es más adecuada para proyectos pequeños o medianos.
</div>
<h3>Ejemplo de arquitectura: Netflix</h3>
<p>
Netflix usa una arquitectura basada en microservicios, cada uno dedicado a tareas específicas y comunicándose por interfaces bien definidas, permitiendo alta escalabilidad y flexibilidad.
</p>
<img src="https://darioaxel.github.io/docencia/dam-daw/DWES/images/dwes/netflix.gif" alt="Arquitectura Netflix"/>
<h2>API Web</h2>
<p>
Una API web permite que diferentes aplicaciones o sistemas se comuniquen y compartan datos. Utiliza HTTP y formatos como JSON o XML.
</p>
<ul>
<li><strong>API RESTful:</strong> Usa métodos HTTP para acceder/manipular recursos. Exposición de datos vía URLs, usando JSON.</li>
<li><strong>API GraphQL:</strong> Una especificación para pedir exactamente los datos necesarios en cada consulta.</li>
<li><strong>API Websocket:</strong> Permiten comunicación bidireccional en tiempo real entre cliente y servidor.</li>
</ul>
<div style="border:1px solid #d32f2f;background:#ffcdd2;padding:10px;margin:10px 0;">
Las API web son claves en el desarrollo moderno, permitiendo integración y flexibilidad.
</div>
<img src="https://darioaxel.github.io/docencia/dam-daw/DWES/images/dwes/apis.gif" alt="API Web"/>
</body>
</html>