Tabla de contenidos

• ¿Qué Es la Arquitectura de las Aplicaciones Web?

• ¿Por Qué es Importante la Arquitectura de las Aplicaciones Web?

• ¿Cómo Funciona la Arquitectura de las Aplicaciones Web?

• Tipos de Arquitectura de Aplicaciones Web

• Capas de la Arquitectura de Aplicaciones Web

• Componentes de la Aplicación Web

• Mejores Prácticas para la Arquitectura de Aplicaciones Web

El mundo se ha trasladado a Internet, y las aplicaciones web se han convertido en los nuevos lugares de trabajo y tiendas comerciales. Para dar cabida a la variedad de propósitos a los que sirven las aplicaciones web modernas, cada una de ellas tiene que estar diseñada para ofrecer un alto rendimiento y personalización.

Las arquitecturas de las aplicaciones web resuelven este problema.

La arquitectura de las aplicaciones web define cómo se estructuran los distintos componentes de una aplicación basada en la web. Esta arquitectura es muy específica para la naturaleza y el propósito de la aplicación web. Elegir una arquitectura equivocada para tu aplicación web puede causar estragos en tu negocio.

En esta guía, desglosaremos el concepto de arquitectura de la aplicación web y comprenderemos cómo afecta a la experiencia del usuario final de tu aplicación. Hacia el final, también veremos algunas de las mejores prácticas que puedes aplicar para sacar el máximo partido a tu aplicación web.

¿Qué Es la Arquitectura de las Aplicaciones Web?

Para iniciar el debate, empecemos con la definición de arquitectura de aplicaciones web.

En palabras sencillas, la arquitectura de aplicaciones web es un esquema de cómo interactúan entre sí los distintos componentes de tu aplicación web.

Puede ser tan simple como definir la relación entre el cliente y el servidor. También puede ser tan compleja como definir las interrelaciones entre un enjambre de servidores backend en contenedores, equilibradores de carga, pasarelas API y frontends de una sola página orientados al usuario.

Dicho esto, rara vez se trata de elegir el lenguaje de programación en el que escribirás tu código.

La forma de diseñar tu aplicación web desempeña un papel clave tanto en su usabilidad como en la optimización de sus costes. Este es el aspecto de un ejemplo de arquitectura de aplicación web sobre el papel:

Diagrama de arquitectura de una aplicación de recomendación. (Fuente de la imagen: Wikipedia)

¿Por Qué es Importante la Arquitectura de las Aplicaciones Web?

La arquitectura de una aplicación web es, sin duda, una de las partes más importantes de tu aplicación web. Si eliges desarrollar tu aplicación web con una arquitectura específica en mente, seguro que obtendrás muchos beneficios a la hora de mantener y hacer crecer tu aplicación.

Sin embargo, la elección de la arquitectura adecuada amplía aún más estos beneficios.

Estas son algunas de las principales razones por las que deberías considerar seriamente adoptar una arquitectura de aplicaciones web.

Se Adapta Fácilmente a las Necesidades del Negocio

Tu aplicación es una puerta de entrada clave para tu negocio, y las necesidades empresariales evolucionan con los cambios del mercado. Para mantener el ritmo, necesitarás que tu aplicación sea lo suficientemente flexible como para adaptarse a las necesidades cambiantes de tu negocio. Y si construyes una aplicación sin tener en cuenta la posibilidad de flexibilidad, es probable que en un futuro desperdicies cada vez más tiempo y esfuerzo haciendo pequeños ajustes en tu aplicación.

Una arquitectura de aplicación web adecuada ya tiene en cuenta algunos de los cambios que tu negocio podría necesitar en el futuro. Por ejemplo, si sabes que estás construyendo una aplicación de comercio electrónico que un día escalará y ofrecerá una amplia gama de servicios a un gran número de clientes, elegir una arquitectura de microservicios en lugar de una monolítica te proporcionará más flexibilidad.

Por otro lado, si estás construyendo una aplicación interna para tu empresa con sólo uno o dos requisitos fijos, puedes optar por un monolito más sencillo para acelerar el desarrollo y mantener tu código base limpio.

Desarrollo Organizado

Como hemos mencionado anteriormente, la arquitectura correcta de la aplicación web te proporciona una hoja de ruta más adecuada para el desarrollo. La arquitectura proporciona suficiente modularidad en tu sistema para aislar los componentes según sea necesario, y obtienes la libertad de elegir la estructura de proyecto adecuada para cada uno de tus módulos y componentes según sea necesario.

Si te sumerges en el desarrollo de una aplicación sin una arquitectura en mente, te arriesgas a perder tiempo y dinero reorganizando tus componentes y estableciendo nuevas reglas que faciliten la colaboración entre los miembros de tu equipo — tiempo y dinero que de otro modo podrías haber invertido en otra cosa.

Mejor Gestión de la Base de Código

Además de escribir el código de tu aplicación, también pasarás una cantidad considerable de tiempo gestionándolo. Organizar los archivos de tu proyecto, dividir tu aplicación en módulos y establecer canalizaciones personalizadas son sólo algunas de las tareas que requieren un mantenimiento activo para garantizar un desarrollo fluido.

Una arquitectura de aplicación web adecuada te facilita la realización de cambios. Puedes aplicar las mejores prácticas específicas de cada componente, separar los puntos de dolor de tu aplicación y mantener cada función independiente y poco acoplada. No es que estas cosas no puedan hacerse sin la arquitectura, sino que la arquitectura adecuada lo hace todo mucho más sencillo.

Seguir una arquitectura predefinida también te facilita desarrollar tus aplicaciones más rápidamente. La arquitectura adecuada, combinada con una buena estrategia de control de versiones, puede permitir a tus desarrolladores trabajar en paralelo y crear funciones más rápidamente.

La arquitectura de una aplicación web también asegura el futuro de tu aplicación. Una vez que definas una estrategia sólida sobre cómo organizar los componentes de tu aplicación, podrás migrar fácilmente esos componentes a tecnologías más nuevas, uno por uno, sin tener que rehacer toda la aplicación.

Seguridad Mejorada

La mayoría de las arquitecturas de aplicaciones web tienen en cuenta la seguridad al estructurar los componentes. Los desarrolladores pueden planificar, con antelación, las medidas y prácticas que deben aplicar para mejorar la seguridad de la aplicación antes de ponerla a disposición de los usuarios.

Por ejemplo, crear una aplicación de streaming de vídeo OTT que ofrezca contenidos gratuitos y de pago utilizando microservicios tiene más sentido, ya que la arquitectura de microservicios te permite dividir tu aplicación en componentes que se adapten al negocio, como la autenticación del usuario y el streaming de contenidos gratuitos o de pago. Si tu módulo de autenticación de usuarios deja de funcionar, puedes configurar fácilmente tu aplicación para restringir el acceso al módulo de contenido de pago hasta que se restablezca la autenticación, mientras que el módulo de contenido gratuito sigue estando disponible para tus usuarios.

Si esta misma aplicación estuviera diseñada como un monolito perfectamente integrado, un servicio de autenticación caído significaría una aplicación caída o un contenido de pago disponible de forma gratuita —  resultados que querrás evitar a toda costa.

¿Cómo Funciona la Arquitectura de las Aplicaciones Web?

Antes de hablar de cómo funciona la arquitectura de las aplicaciones web, es importante entender cómo funciona un sitio web sencillo:

1. El usuario introduce la URL de tu aplicación en la barra de direcciones del navegador o hace clic en un enlace.

2. El navegador busca la URL en los servidores DNS e identifica la dirección IP de tu aplicación.

3. El navegador envía una petición HTTP a tu aplicación.

4. Tu aplicación responde con el contenido correcto (normalmente una página web).

5. El navegador muestra la página web en la pantalla.

Si quieres profundizar un poco más, así es como una aplicación web gestionaría una solicitud:

1. El usuario envía una petición a tu aplicación a través de la interfaz de usuario del frontend.

2. Si tienes configurada una caché relevante, la aplicación la comprobará primero para ver si tiene un registro válido que pueda enviarse de vuelta al cliente directamente. En caso afirmativo, se devolverá el contenido almacenado en la caché, y la solicitud se marcará como completada.

3. Si no hay caché, la petición se reenvía al equilibrador de carga.

4. El equilibrador de carga identifica una instancia de servidor que esté disponible para gestionar la petición y la reenvía.

5. La instancia del servidor procesa la petición y llama a cualquier API externa si es necesario.

6. Una vez recogidos los resultados en un lugar, el servidor devuelve la respuesta al equilibrador de carga.

7. El equilibrador de carga devuelve la respuesta a la pasarela de la API, que a su vez la envía al usuario en el cliente del frontend. A continuación, la solicitud se marca como completada.

Tipos de Arquitectura de Aplicaciones Web

Ahora que tienes una idea básica de lo que es la arquitectura de las aplicaciones web, vamos a echar un vistazo detallado a algunos de los tipos más populares de arquitectura de aplicaciones web que se utilizan en la red.

Arquitectura de Una Sola Página

La arquitectura de una aplicación de una sola página (SPA) es tan sencilla como su nombre: toda la aplicación se basa en una sola página. Una vez que el usuario accede a tu aplicación, no necesita navegar a ninguna otra página web. La aplicación se hace lo suficientemente dinámica como para obtener y renderizar pantallas que satisfagan los requisitos de los usuarios mientras navegan por la propia aplicación.

Las SPA son estupendas cuando se trata de proporcionar una experiencia rápida y sin fisuras a los usuarios finales o consumidores. Sin embargo, carecen del toque de un sitio web tradicional, y pueden ser difíciles de optimizar para el SEO.

Ventajas de la Arquitectura SPA

Algunos de los pros de la arquitectura SPA son:

• Puedes construir aplicaciones web altamente interactivas.

• Las SPA son fáciles de escalar.

• Optimizar las SPA para el rendimiento no requiere mucho esfuerzo.

Inconvenientes de la Arquitectura SPA

Algunos de los inconvenientes de la arquitectura SPA son:

• Las SPA limitan la flexibilidad con los hipervínculos y el SEO.

• El renderizado inicial suele ser lento.

• La navegación por la aplicación puede ser poco intuitiva.

Arquitectura de Aplicaciones Web Progresivas

La arquitectura de la Aplicación Web Progresiva (PWA) se basa en la Arquitectura de Página Única proporcionando capacidades offline para tu aplicación web. Tecnologías como Capacitor e Ionic se utilizan para crear PWA que pueden proporcionar a los usuarios una experiencia uniforme en todas las plataformas.

Al igual que las SPA, las PWA son fluidas y sin fisuras. Con la capacidad añadida de instalarse en los dispositivos de los usuarios (a través de service workers), tus usuarios obtienen una experiencia más uniforme con tu aplicación.

Al mismo tiempo, puede ser difícil optimizar estas aplicaciones para el SEO, y las actualizaciones de las aplicaciones instaladas pueden ser difíciles de impulsar.

EJEMPLOS:

Google Maps.Google Drive.Google Fotos.Google Duo.Google Stadia.Uber. Twitter. Facebook. Instagram.Telegram. Pinterest.

https://www.xataka.com/basics/aplicaciones-web-progresivas-pwa-windows-10-que-como-se-utilizan#:~:text=Sin%20embargo%2C%20si%20quieres%20conocer,dot%20com%20Australia%20o%20Rocketmiles. 

https://sirvelia.com/ejemplos-aplicaciones-web-progresivas/ 

Ventajas de la Arquitectura PWA

Hay muchas ventajas de la arquitectura PWA, entre ellas:

• Las aplicaciones se ejecutan con mucha fluidez y ofrecen compatibilidad entre plataformas.

• La escalabilidad es sencilla.

• Los desarrolladores pueden acceder al acceso sin conexión y a las API nativas de los dispositivos, como los trabajadores en segundo plano y las notificaciones push.

Contras de la Arquitectura PWA

Algunos de los contras de la arquitectura PWA pueden ser:

• Hay un soporte limitado para la gestión de enlaces y el SEO.

• Enviar actualizaciones a las PWA sin conexión es más complejo que con las aplicaciones nativas.

• La compatibilidad de las PWA con los navegadores web y sistemas operativos es limitada.

Arquitectura de Renderizado del Lado del Servidor

En la renderización del lado del servidor (SSR), las páginas web del frontend se renderizan en un servidor backend después de ser solicitadas por el usuario. Esto ayuda a reducir la carga en el dispositivo del cliente, ya que recibe una página web estática de HTML, CSS y JS.

Las aplicaciones SSR son muy populares entre los blogs y los sitios web de comercio electrónico. Esto se debe a que hacen que la gestión de enlaces y el SEO sean bastante sencillos. Además, la primera representación de las aplicaciones SSR es bastante rápida, ya que el cliente no tiene que procesar ningún código JS para representar las pantallas.

El renderizado del lado del servidor es más fácil de implementar que el del lado del cliente. Es la tecnología de renderizado por defecto para casi todos los top contenido gestión sistemas (CMS). Ya sea que esté desarrollando un sitio web con WordPress, Joomla o Drupalprobablemente utilizará el renderizado del lado del servidor. 

Ventajas de la Arquitectura SSR

A continuación se enumeran algunas de las ventajas de la arquitectura SSR:

• Estas aplicaciones son estupendas para los sitios web con mucho SEO.

• La carga de la primera página es casi instantánea en la mayoría de los casos.

• Puedes combinarla con un servicio de caché para mejorar aún más el rendimiento de tu aplicación.

Contras de la Arquitectura SSR

Algunos de los inconvenientes de utilizar la arquitectura SSR son:

• No se recomienda para páginas web complejas o pesadas, ya que el servidor puede tardar en generar completamente la página, lo que provoca un retraso en la primera carga.

• Se recomienda sobre todo para aplicaciones que no se centran mucho en la interfaz de usuario y sólo buscan una mayor escalabilidad o seguridad.

Arquitectura de Aplicaciones Prerrenderizadas

La arquitectura de aplicaciones pre-renderizadas también se conoce como arquitectura de generación de sitios estáticos. En esta arquitectura, las páginas web del frontend de la aplicación se generan previamente y se almacenan como archivos HTML, CSS y JS planos en el servidor. Una vez que el usuario solicita una página, ésta se obtiene directamente y se le muestra. Esto hace que la aplicación web sea muy rápida, con tiempos de carga mínimos de cualquier tipo. Sin embargo, esta arquitectura aumenta el tiempo de construcción de la aplicación, ya que las páginas web se renderizan durante el proceso de construcción.

Las aplicaciones web prerrenderizadas son estupendas para cuando quieres generar contenido estático, como blogs o detalles de productos que no cambian a menudo. También puedes utilizar plantillas para simplificar el diseño de tu página web. Sin embargo, es casi imposible crear aplicaciones web dinámicas con esta arquitectura.Si quieres construir una página de búsqueda que tome la consulta en su ruta (algo así comohttps://myapp.com/search/foo+bar), estás en el lugar equivocado.

Dado que cada posible ruta de la aplicación se pre-renderiza durante el proceso de construcción, es imposible tener rutas dinámicas como las anteriores, ya que hay infinitas posibilidades que no pueden pre-renderizarse durante la construcción (y tampoco tiene sentido hacerlo).

Ventajas de la Arquitectura Prerrenderizada

Algunas de las principales ventajas de la arquitectura de aplicaciones prerrenderizadas son:

• Las páginas web se generan en HTML, CSS y JS puros, por lo que su rendimiento es similar al de las aplicaciones construidas con vanilla JS.

• Si conoces todas las rutas posibles de tu aplicación, el SEO se vuelve superfácil.

Contras de la Arquitectura Prerrenderizada

Como cualquier modelo de arquitectura, la pre-renderizada tiene sus inconvenientes:

• El contenido dinámico no se puede servir con estas aplicaciones.

• Hacer cualquier cambio en la aplicación web significa reconstruir y desplegar completamente la aplicación desde cero.

Arquitectura de Aplicaciones Isomórficas

Las aplicaciones isomórficas son aquellas que son una mezcla de aplicaciones renderizadas en el lado del servidor y SPA. Esto significa que dichas aplicaciones se renderizan primero en el servidor como una aplicación normal renderizada del lado del servidor. Una vez que las recibe el cliente, la app se hidrata y adjunta el DOM virtual para un procesamiento más rápido y eficiente por parte del cliente. Esto convierte esencialmente la aplicación en una aplicación de una sola página.

Isomorphic reúne lo mejor de ambos mundos. El procesamiento y la interfaz de usuario del cliente son superrápidos, gracias a la SPA. También obtienes un renderizado inicial rápido y un soporte completo de SEO y enlaces, gracias al renderizado del lado del servidor.

Ventajas de la Arquitectura Isomórfica

Éstas son algunas de las ventajas de utilizar una arquitectura de aplicación isomórfica:

• Las apps isomórficas tienen una renderización inicial súper rápida y soporte completo para el SEO.

• Estas aplicaciones también tienen un buen rendimiento en el cliente, ya que se convierten en una SPA después de la carga.

Contras de la Arquitectura Isomórfica

Algunos de los contras de la arquitectura de aplicación isomórfica pueden ser:

• La puesta en marcha de una aplicación de este tipo requiere de un conocimiento profundo.

• Las opciones del stack tecnológico son limitadas cuando se trata de diseñar una aplicación isomórfica. Sólo puedes elegir entre un puñado de librerías y frameworks (en su mayoría) basados en JS.

Arquitectura Orientada al Servicio

La arquitectura orientada a servicios es una de las alternativas más populares a la forma tradicional de construir aplicaciones en forma de monolito. En esta arquitectura, las aplicaciones web se dividen en servicios que representan una unidad funcional de negocio cada uno. Estos servicios están débilmente acoplados e interactúan entre sí mediante el paso de mensajes.

La arquitectura orientada a servicios añade estabilidad y escalabilidad al stack tecnológico de tu aplicación. Sin embargo, el tamaño de los servicios en la SOA no están claramente definidos y suelen estar vinculados a los componentes de negocio, no a los componentes técnicos; de ahí que el mantenimiento pueda ser a veces un problema.

Ventajas de la Arquitectura Orientada a Servicios

Las principales ventajas de la arquitectura orientada a servicios son:

• Esta arquitectura ayuda a construir aplicaciones altamente escalables y fiables.

• Los componentes son reutilizables y se comparten para mejorar los esfuerzos de desarrollo y mantenimiento.

Contras de la Arquitectura Orientada a Servicios

Aquí tienes una lista de los posibles inconvenientes de utilizar la arquitectura orientada a servicios:

• Las aplicaciones SOA aún no son 100% flexibles, ya que el tamaño y el alcance de cada servicio no son fijos. Puede haber servicios del tamaño de aplicaciones empresariales que pueden ser difíciles de mantener.

• La compartición de componentes introduce dependencias entre los servicios.

Arquitectura de Microservicios

La arquitectura de microservicios fue diseñada para resolver los problemas de la arquitectura orientada a servicios. Los microservicios son componentes aún más modulares que encajan entre sí para construir una aplicación web. Sin embargo, los microservicios se centran en mantener cada componente pequeño y con un contexto limitado. Contexto delimitado significa esencialmente que cada microservicio tiene su código y sus datos acoplados con mínimas dependencias de otros microservicios.

La arquitectura de microservicios es probablemente la mejor arquitectura para construir aplicaciones que pretenden escalar algún día a miles y millones de usuarios. Cada componente es resistente, escalable y fácil de mantener. Sin embargo, el mantenimiento del ciclo de vida de DevOps para una aplicación basada en microservicios requiere esfuerzos adicionales, por lo que podría no ser adecuado para casos de uso más pequeños.

Ventajas de la Arquitectura de Microservicios

Algunas de las ventajas de la arquitectura de microservicios son:

• Los componentes de las aplicaciones son muy modulares, independientes y pueden reutilizarse en mayor medida que los de la arquitectura orientada a servicios.

• Cada componente puede escalarse de forma independiente para satisfacer el tráfico variable de usuarios.

• Las aplicaciones basadas en microservicios son altamente tolerantes a los fallos.

Contras de la Arquitectura de Microservicios

Un inconveniente de la arquitectura de microservicios puede ser:

• Para los proyectos más pequeños, la arquitectura de microservicios puede requerir demasiado esfuerzo de mantenimiento.

Arquitectura Sin Servidor

La arquitectura sin servidor es otra de las novedades en el mundo de las arquitecturas de aplicaciones web. Esta arquitectura se centra en desglosar tu aplicación en términos de las funciones que debe realizar. A continuación, estas funciones se alojan en plataformas FaaS (Function-as-a-Service) como funciones que se invocan a medida que llegan las solicitudes.

A diferencia de la mayoría de las otras arquitecturas de esta lista, las aplicaciones construidas con la arquitectura sin servidor no permanecen en funcionamiento todo el tiempo. Se comportan como lo harían las funciones — esperan a ser llamadas, y al ser llamadas, ejecutan el proceso definido y devuelven un resultado. Debido a esta naturaleza, reducen los costes de mantenimiento y son altamente escalables sin mucho esfuerzo. Sin embargo, es difícil llevar a cabo tareas de larga duración utilizando estos componentes.

Ventajas de la Arquitectura Sin Servidor

Estas son las principales ventajas de la arquitectura sin servidor:

• Las aplicaciones sin servidor son muy fácilmente escalables. Incluso pueden adaptarse al tráfico entrante en tiempo real para reducir la carga de tu infraestructura.

• Estas aplicaciones pueden utilizar el modelo de precios de pago por uso de las plataformas sin servidor para reducir los costes de infraestructura.

• Las aplicaciones sin servidor son bastante fáciles de construir y desplegar, ya que todo lo que tienes que hacer es escribir una función y alojarla en una plataforma como funciones Firebase, AWS Lambda, etc.

Inconvenientes de la Arquitectura sin Servidor

A continuación se presentan algunos de los inconvenientes de la arquitectura sin servidor:

• Las tareas de larga duración pueden ser costosas en una arquitectura de este tipo.

• Cuando una función recibe una petición después de mucho tiempo, se conoce como arranque en frío. Los arranques en frío son lentos y pueden proporcionar una mala experiencia a tu usuario final.

Capas de la Arquitectura de Aplicaciones Web

Aunque las arquitecturas de aplicaciones web que has visto anteriormente pueden parecer muy diferentes entre sí, sus componentes pueden agruparse lógicamente en capas definidas que ayudan a alcanzar un objetivo empresarial.

Capa de Presentación

La capa de presentación representa todo lo que en una aplicación web se expone a los usuarios finales. Principalmente, la capa de presentación está compuesta por el cliente del frontend. Sin embargo, también incorpora cualquier lógica que hayas escrito en tu backend para hacer que tu frontend sea dinámico. Esto te da la posibilidad de servir a tus usuarios con una interfaz de usuario adaptada a su perfil y requisitos.

Para construir esta capa se utilizan tres tecnologías fundamentales: HTML, CSS y JavaScript. El HTML diseña tu frontend, el CSS le da estilo y el JS le da vida (es decir, controla su comportamiento cuando los usuarios interactúan con él). Además de estas tres tecnologías, puedes utilizar cualquier tipo de framework para facilitar tu desarrollo. Algunos frameworks de frontend comunes son Laravel, React, NextJS, Vue, GatsbyJS, etc.

Capa de Negocio

La capa de negocio es responsable de mantener y gestionar la lógica de funcionamiento de tu aplicación. Suele ser un servicio de backend que acepta las peticiones del cliente y las procesa. Controla a qué puede acceder el usuario y determina cómo se utiliza la infraestructura para atender las peticiones de los usuarios.

En el caso de una aplicación de reserva de hoteles, tu aplicación cliente sirve de portal para que los usuarios escriban los nombres de los hoteles y otros datos relevantes. Sin embargo, en cuanto el usuario hace clic en el botón de búsqueda, la capa de negocio recibe la petición y pone en marcha la lógica para buscar las habitaciones de hotel disponibles que coincidan con sus requisitos. A continuación, el cliente se limita a recibir una lista de habitaciones de hotel sin saber cómo se ha generado esta lista ni siquiera por qué los elementos de la lista están dispuestos de la forma en que se han enviado.

La presencia de una capa de este tipo garantiza que tu lógica de negocio no esté expuesta a tu cliente y, en última instancia, a los usuarios. Aislar la lógica de negocio ayuda enormemente en operaciones sensibles como la gestión de pagos o la gestión de registros sanitarios.

Capa de Persistencia

La capa de persistencia se encarga de controlar el acceso a tus almacenes de datos. Actúa como una capa de abstracción añadida entre tus almacenes de datos y tu capa de negocio. Recibe todas las llamadas relacionadas con los datos de las capas de negocio y las procesa estableciendo conexiones seguras con la base de datos.

Esta capa suele consistir en un servidor de base de datos. Puedes establecer esta capa tú mismo aprovisionando una base de datos y un servidor de bases de datos en tu infraestructura on-prem u optar por una solución remota/gestionada por uno de los principales proveedores de infraestructura en la nube como AWS, GCP, Microsoft Azure, etc.

Componentes de la Aplicación Web

Ahora que entiendes lo que hay en la arquitectura de una aplicación web, vamos a echar un vistazo detallado a cada uno de los componentes que componen una aplicación web. Agruparemos esta discusión en dos grandes apartados: componentes del lado del servidor y componentes del lado del cliente, o componentes del backend y del frontend.

Componentes del Lado del Servidor

Los componentes del lado del servidor son los que residen en el backend de tu aplicación web. No están expuestos directamente a los usuarios y contienen la lógica de negocio y los recursos más importantes de tu aplicación web.

DNS y Enrutamiento

El DNS es responsable de controlar cómo se expone tu aplicación a la web. Los registros DNS son utilizados por los clientes HTTP, que también pueden ser un navegador, para encontrar y enviar solicitudes a los componentes de tu aplicación. El DNS también es utilizado por tus clientes frontend internamente para resolver la ubicación de tus servidores web y endpoints de la API para enviar solicitudes y procesar las operaciones de los usuarios.

El equilibrio de carga es otro componente popular de la arquitectura de las aplicaciones web. Un equilibrador de carga se utiliza para distribuir las peticiones HTTP entre varios servidores web idénticos. La intención de tener varios servidores web es mantener la redundancia que ayuda a aumentar la tolerancia a los fallos, así como distribuir el tráfico para mantener un alto rendimiento.

Los endpoints de la API se utilizan para exponer los servicios del backend a la aplicación del frontend. Estos ayudan a facilitar la comunicación entre el cliente y el servidor, y a veces incluso entre varios servidores.

Almacenamiento de Datos

El almacenamiento de datos es una parte crucial de la mayoría de las aplicaciones modernas, ya que siempre hay algunos datos de la aplicación que deben persistir a través de las sesiones de los usuarios. El almacenamiento de datos es de dos tipos:

• Bases de datos: Las bases de datos se utilizan para almacenar datos para un acceso rápido. Normalmente, admiten el almacenamiento de una pequeña cantidad de datos a los que accede regularmente tu aplicación.

• Almacenes de datos: Los almacenes de datos están pensados para la conservación de datos históricos. Por lo general, no se necesitan con mucha frecuencia en la aplicación, pero se procesan con regularidad para generar información empresarial.

Almacenamiento en Caché

El almacenamiento en caché es una característica opcional que suele implementarse en las arquitecturas de las aplicaciones web para servir el contenido más rápidamente a los usuarios. Una gran parte del contenido de la app suele ser repetitiva durante cierto tiempo, si no siempre. En lugar de acceder a él desde un almacén de datos y procesarlo antes de enviarlo al usuario, a menudo se almacena en caché. Estos son los dos tipos más populares de almacenamiento en caché que se utilizan en las aplicaciones web:

• Almacenamiento de datos en caché: El almacenamiento de datos en caché introduce una forma de que tu aplicación acceda fácil y rápidamente a los datos utilizados regularmente y que no cambian con frecuencia. Tecnologías como Redis y Memcache permiten almacenar datos en caché para ahorrar costosas consultas a la base de datos para recuperar los mismos datos una y otra vez.

• Almacenamiento en caché de páginas web: Una CDN (Content Delivery Network) almacena en caché las páginas web de la misma manera que Redis almacena en caché los datos. Al igual que sólo se almacenan en caché los datos que no cambian a menudo, normalmente sólo se recomienda almacenar en caché las páginas web estáticas. Para las aplicaciones web renderizadas en el lado del servidor, el almacenamiento en caché no sirve de mucho, ya que se supone que su contenido es muy dinámico.

Trabajos y Servicios

Aparte de exponer una interfaz a los usuarios (frontend) y gestionar sus peticiones (backend), hay otra categoría algo menos popular de componentes de aplicaciones web. Los trabajos suelen ser servicios en segundo plano destinados a completar tareas que no son sensibles al tiempo ni a la sincronización.

Los trabajos CRON son aquellos que se ejecutan en un periodo de tiempo fijo una y otra vez. Estos trabajos se programan en el backend para ejecutar rutinas de mantenimiento automáticamente en momentos determinados. Algunos ejemplos comunes de uso de estos trabajos incluyen la eliminación de duplicados/registros antiguos de la base de datos, el envío de correos electrónicos recordatorios a los clientes, etc.

Componentes del Lado del Cliente

Los componentes del lado del cliente son los que se exponen a tus usuarios directa o indirectamente.

Hay principalmente dos tipos de componentes en esta categoría.

Interfaz de Usuario del Frontend

La interfaz de usuario es el aspecto visual de tu aplicación. Es lo que tus usuarios ven y con lo que interactúan para acceder a tus servicios.

La interfaz del frontend se construye principalmente con tres tecnologías populares: HTML, CSS y JavaScript. La interfaz de usuario del frontend puede ser una aplicación en sí misma con su propio ciclo de vida de desarrollo de software.

Estas interfaces de usuario no albergan gran parte de tu lógica de negocio, ya que están expuestas directamente a tus usuarios. Si un usuario malintencionado intenta aplicar ingeniería inversa a tu aplicación de frontend, puede obtener información sobre el funcionamiento de tu negocio y llevar a cabo actividades ilegales como la suplantación de la marca y el robo de datos.

Además, como la interfaz de usuario del frontend está expuesta directamente a los usuarios, deberás optimizarla para que la capacidad de respuesta y el tiempo de carga sean mínimos. A veces esto puede ayudarte a proporcionar una mejor experiencia a tus usuarios, aumentando así el crecimiento de tu negocio.

Lógica Empresarial del Lado del Cliente

A veces puedes necesitar almacenar alguna lógica de negocio en tu cliente para realizar operaciones más sencillas con rapidez. La lógica del lado del cliente, que suele residir en tu aplicación frontend, puede ayudarte a saltarte el viaje al servidor y proporcionar a tus usuarios una experiencia más rápida.

Esta es una característica opcional de los componentes del lado del cliente. En algunos casos, la lógica de negocio de la aplicación se almacena completamente en el lado del cliente (especialmente cuando se construye sin un servidor backend tradicional). Las soluciones modernas como BaaS te ayudan a acceder a operaciones comunes como la autenticación, el almacenamiento de datos, el almacenamiento de archivos, etc., sobre la marcha en tu aplicación frontend.

Hay formas de ofuscar o minificar este código antes de lanzarlo a tus usuarios para minimizar las posibilidades de ingeniería inversa.

Modelos de Componentes de Aplicaciones Web

Hay varios modelos de arquitecturas de aplicaciones web, cada uno de ellos basado en cómo se conectan los servidores web a sus almacenes de datos.

Un Servidor, Una Base de Datos

El modelo más sencillo de todos es un servidor web que se conecta a una instancia de base de datos. Este modelo es fácil de implementar y mantener, y pasar a producción con él tampoco supone ningún esfuerzo.

Debido a su simplicidad, este modelo es adecuado para el aprendizaje y para pequeñas aplicaciones experimentales que no estarán expuestas a un alto tráfico. Los desarrolladores principiantes pueden configurar y trastear fácilmente con estas aplicaciones para aprender los fundamentos del desarrollo de aplicaciones web.

Sin embargo, este modelo no debería utilizarse en producción, ya que es muy poco fiable. Un problema en el servidor o en la base de datos puede provocar tiempos de inactividad y pérdidas de negocio.

Varios Servidores, Una Base de Datos

Este modelo lleva la aplicación a un nivel superior al establecer varios servidores para la redundancia con una única instancia de base de datos común.

Como varios servidores web acceden simultáneamente a la base de datos, pueden producirse problemas de inconsistencia. Para evitarlo, los servidores web están diseñados para no tener estado. Esto significa que los servidores no retienen los datos entre sesiones; simplemente los procesan y los almacenan en la base de datos.

Las aplicaciones realizadas con este modelo son ciertamente más fiables que las del modelo anterior, ya que la presencia de varios servidores web aumenta la tolerancia a los fallos de la aplicación web. Sin embargo, como la base de datos sigue siendo una instancia común, es el eslabón más débil de la arquitectura y puede ser una fuente de fallos.

Múltiples Servidores, Múltiples Bases de Datos

Este modelo es uno de los más comunes y tradicionales en el diseño de aplicaciones web.

En este caso, despliega la lógica de tu aplicación como múltiples instancias idénticas de servidor web agrupadas detrás de un equilibrador de carga. Tu almacén de datos también se mantiene en múltiples instancias de bases de datos para añadir tolerancia a los fallos.

También puedes elegir dividir tu base de datos entre las instancias disponibles para mejorar el rendimiento o mantener duplicados de todo el almacén de datos para la redundancia. En cualquier caso, el fallo de una instancia de tu base de datos no provocará una interrupción completa de la aplicación.

Este modelo es muy apreciado por su fiabilidad y escalabilidad. Sin embargo, desarrollar y mantener aplicaciones con este modelo es relativamente complicado y requiere desarrolladores expertos y de alto coste. Por ello, este modelo sólo se sugiere cuando se construye a gran escala.

Servicios de Aplicaciones

Mientras que los tres modelos mencionados anteriormente son muy adecuados para las aplicaciones monolíticas, hay otro modelo para las aplicaciones modulares.

El modelo de servicios de aplicación descompone una aplicación en módulos más pequeños basados en la funcionalidad del negocio. Estos módulos pueden ser tan pequeños como una función o tan grandes como un servicio.

La idea aquí es hacer que cada función empresarial sea independiente y escalable. Cada uno de estos módulos puede conectarse a la base de datos por sí mismo. Incluso puedes tener instancias de base de datos dedicadas para satisfacer las necesidades de escalabilidad de tus módulos.

Entre las aplicaciones no monolíticas, este modelo es bastante popular. Los monolitos heredados suelen migrar a este modelo para aprovechar sus ventajas de escalabilidad y modularidad. Sin embargo, la gestión de las aplicaciones construidas con este modelo suele requerir desarrolladores experimentados, especialmente con experiencia en DevOps y CI/CD.

Mejores Prácticas para la Arquitectura de Aplicaciones Web

A continuación, te presentamos algunas de las mejores prácticas que puedes implementar en tu proyecto de aplicación web para sacar el máximo provecho de la arquitectura de aplicación web elegida.

1. Haz que tu Frontend sea Responsivo

Esto no se puede recalcar lo suficiente: Procura que el frontend sea siempre responsivo. No importa lo enorme y compleja que sea tu aplicación web internamente, todo está expuesto a tus usuarios a través de las páginas web, aplicaciones y pantallas del frontend.

Si tus usuarios encuentran estas pantallas poco intuitivas o lentas, no se quedarán el tiempo suficiente para ver y admirar la maravilla de ingeniería que es tu aplicación web.

Por lo tanto, diseñar frontales accesibles, fáciles de usar y ligeros es muy importante.

En la red hay muchas buenas prácticas de UI/UX que te ayudarán a entender qué es lo que mejor funciona para tus usuarios. Puedes encontrar profesionales expertos en hacer diseños y arquitecturas fáciles de usar que permitan a tus usuarios sacar el máximo partido a tus aplicaciones.

Aconsejamos pensar seriamente en la capacidad de respuesta de tu frontend antes de lanzar tu producto a tus usuarios.

2. Controla los Tiempos de Carga

Además de ser fáciles de entender, tus interfaces deben cargarse rápidamente.

Según Portent, las mayores tasas de conversión en el comercio electrónico se dan en páginas con tiempos de carga de entre 0 y 2 segundos, y según Unbounce, alrededor del 70% de los consumidores admiten que el tiempo de carga de la página es un factor importante en su decisión de comprar a un vendedor online.

Al diseñar aplicaciones nativas para móviles, normalmente no puedes estar seguro de las especificaciones del dispositivo de tus usuarios. Cualquier dispositivo que no cumpla los requisitos de tu aplicación suele declararse no compatible con ella.

Sin embargo, esto es muy diferente con la web.

Cuando se trata de aplicaciones web, tus usuarios pueden utilizar cualquier cosa, desde el último Macbook M1 Pros de Apple hasta teléfonos Blackberry y Nokia antiguos para ver tu aplicación. Optimizar la experiencia de tu frontend para una gama tan amplia de usuarios a veces puede ser difícil.

Cuando se habla de rendimiento de la interfaz, se piensa en servicios como LightHouse y Google PageSpeed. Deberías utilizar estas herramientas para evaluar tu aplicación frontend antes de desplegarla en producción. La mayoría de estas herramientas ofrecen una lista de consejos prácticos para ayudar a mejorar el rendimiento de la aplicación en la medida de lo posible.

El 5-10% final del rendimiento de la aplicación suele ser específico de tu caso de uso y sólo puede ser arreglado por alguien que conozca bien tu aplicación y sus tecnologías. ¡Nunca está de más invertir en el rendimiento de la web!

3. Siempre que sea Posible, es Preferible la PWA

Como ya hemos comentado, las PWA son los diseños del futuro. Se adaptan bien a la mayoría de los casos de uso, y proporcionan la experiencia más uniforme en las principales plataformas.

Deberías considerar el uso de PWA para tu aplicación con la mayor frecuencia posible. La experiencia nativa a través de la web y el móvil es enormemente impactante para tus usuarios y puede reducir también gran parte de tu propia carga de trabajo.

Las PWA también son rápidas de cargar, fáciles de optimizar y rápidas de construir. Optar por las PWA puede ayudarte a desplazar gran parte de tu atención del desarrollo al negocio desde el principio.

4. Mantén tu Código Base Limpio y Sucinto

Una base de código limpia puede ayudarte a detectar y resolver la mayoría de los problemas antes de que causen daños. Aquí tienes algunos consejos que puedes seguir para asegurarte de que tu código base no te causa más problemas de los que debería.

• Céntrate en la reutilización del código: Mantener copias del mismo código en toda tu base de código no sólo es redundante, sino que también puede provocar discrepancias, haciendo que tu base de código sea difícil de mantener. Céntrate en la reutilización del código siempre que sea posible.

• Planifica la estructura de tu proyecto: Los proyectos de software pueden crecer mucho con el tiempo. Si no empiezas con una estructura planificada de organización de código y recursos, puedes acabar dedicando más tiempo a buscar archivos que a escribir código útil.

• Escribe pruebas unitarias: Cada fragmento de código puede romperse. Probarlo todo manualmente no es factible, así que necesitas una estrategia definida para automatizar las pruebas de tu código. Los ejecutores de pruebas y las herramientas de cobertura de código pueden ayudarte a identificar si tus esfuerzos de pruebas unitarias están dando los resultados deseados.

• Alta modularidad: Cuando escribas código, céntrate siempre en la modularidad. Escribir código estrechamente acoplado a otros trozos de código dificulta las pruebas, la reutilización y la modificación cuando sea necesario.

5. Automatiza tus procesos CI/CD

CI/CD son las siglas de Integración Continua/Despliegue Continuo. Los procesos CI/CD son cruciales para el desarrollo de tu aplicación, ya que te ayudan a construir, probar y desplegar tu proyecto con facilidad.

Sin embargo, no quieres tener que ejecutarlos manualmente cada vez. En lugar de ello, debes establecer procesos que se activen automáticamente en función de las actividades de tu proyecto. Por ejemplo, puedes configurar una canalización que ejecute tus pruebas automáticamente cada vez que envíes el código a tu sistema de control de versiones. También hay muchos casos de uso más complejos, como generar artefactos multiplataforma desde tu repositorio de código cada vez que se crea una versión.

Las posibilidades son infinitas, así que depende de ti averiguar cómo puedes sacar el máximo partido a tus canalizaciones CI/CD.

6. Incorpora Funciones de Seguridad

La mayoría de las aplicaciones modernas están formadas por múltiples componentes. Toma como ejemplo la siguiente aplicación:

Ejemplo de arquitectura de una aplicación web sin servidor.

Las peticiones de los clientes se dirigen a la aplicación a través de una pasarela API. Aunque ésta actualmente sólo permite realizar peticiones directas al módulo de inicio de la app, en el futuro podría permitir el acceso a más componentes sin pasar por el módulo de inicio.

A continuación, el módulo de inicio comprueba un BaaS de autenticación externa antes de permitir el acceso. Una vez autenticado, el cliente puede acceder a las páginas «Actualizar perfil» o «Ver perfil». Estas dos páginas interactúan con una solución de base de datos común y gestionada que maneja los datos del perfil.

Como puedes ver, la aplicación parece una versión muy básica y mínima de un directorio de personas online. Puedes añadir/actualizar tu propio perfil o ver otros perfiles disponibles.

Aquí tienes una leyenda rápida de los distintos componentes de la arquitectura:

• Cajas azules: Módulos de la aplicación, que posiblemente se alojen como microservicios o funciones sin servidor.

• Cajas rojas: Componentes externos de BaaS que proporcionan la autenticación y la base de datos.

• Caja verde: Componente de enrutamiento que modera las solicitudes entrantes del cliente.

• Caja negra: Tu aplicación cliente expuesta al usuario.

Los componentes de cada uno de los colores de arriba son vulnerables a varios tipos de amenazas de seguridad. Aquí tienes algunas construcciones de seguridad que puedes poner en marcha para minimizar tu exposición:

• Módulos de la app (azul): Dado que se trata de funciones sin servidor, aquí tienes algunos consejos para reforzar su seguridad:

  • Aislar los secretos de la aplicación y gestionarlos independientemente de tu código fuente

  • Mantén los controles de acceso mediante servicios IAM

  • Mejora tus esfuerzos de prueba para buscar también amenazas a la seguridad mediante técnicas como SAST

• Servicios externos (rojo):

  • Establece controles de acceso a través de sus módulos IAM para regular el acceso

  • Opta por la limitación de la tasa de la API

  • Para servicios como las bases de datos, establece permisos de control más finos, como quién puede acceder a los datos de los perfiles, quién puede ver los datos de los usuarios, etc. Muchos servicios, como Firebase, proporcionan un conjunto detallado de tales reglas.

• Componente de enrutamiento (verde):

  • Al igual que los demás componentes, implementa controles de acceso

  • Establece la autorización

  • Vuelve a comprobar las mejores prácticas estándar, como el CORS

• Cliente:

  • Asegúrate de que ningún secreto de la aplicación esté disponible para tu cliente

  • Ofusca el código de tu cliente para minimizar las posibilidades de ingeniería inversa

Aunque sólo se trata de unas cuantas sugerencias, sirven para dejar claro que la seguridad de las aplicaciones es complicada, y es tu responsabilidad asegurarte de que no dejas ningún cabo suelto del que puedan tirar los atacantes. No puedes confiar en un componente de seguridad central para proteger tu negocio; la seguridad de las aplicaciones está distribuida por toda su arquitectura.

7. Recoge las Opiniones de los Usuarios

Los comentarios de los usuarios son una herramienta crucial para comprender lo bien que funciona tu aplicación en términos de rendimiento empresarial y técnico. Puedes construir la aplicación más ligera y fluida del mundo, pero si no permite a tus usuarios hacer lo que esperan, todos tus esfuerzos se irán al garete.

Existen múltiples formas de recoger las opiniones de los usuarios. Mientras que una encuesta rápida y anónima es el enfoque convencional, también podrías optar por una solución más sofisticada, como un mapa de calor de la actividad de tus usuarios.

La elección del método de recogida de opiniones es menos importante que tomar medidas sobre las opiniones recogidas. A los clientes les encantan las empresas que escuchan sus problemas. Gigantes como McDonald’s y Tesla lo hacen, y esa es una de las razones por las que siguen teniendo éxito en sus mercados.