\u00bfQu\u00e9 Es la Arquitectura de las Aplicaciones Web?<\/h2>\n
Para iniciar el debate, empecemos con la definici\u00f3n de arquitectura de aplicaciones web.<\/p>\n
En palabras sencillas, la arquitectura de aplicaciones web es un esquema de c\u00f3mo interact\u00faan entre s\u00ed los distintos componentes de tu aplicaci\u00f3n web.<\/p>\n
Puede ser tan simple como definir la relaci\u00f3n entre el cliente y el servidor. Tambi\u00e9n 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\u00e1gina orientados al usuario.<\/p>\n
Dicho esto, rara vez se trata de elegir el lenguaje de programaci\u00f3n<\/a> en el que escribir\u00e1s tu c\u00f3digo.<\/p>\n La forma de dise\u00f1ar tu aplicaci\u00f3n web desempe\u00f1a un papel clave tanto en su usabilidad como en la optimizaci\u00f3n de sus costes. Este es el aspecto de un ejemplo de arquitectura de aplicaci\u00f3n web sobre el papel:<\/p>\n La arquitectura de una aplicaci\u00f3n web es, sin duda, una de las partes m\u00e1s importantes de tu aplicaci\u00f3n web. Si eliges desarrollar tu aplicaci\u00f3n web con una arquitectura espec\u00edfica en mente, seguro que obtendr\u00e1s muchos beneficios a la hora de mantener y hacer crecer tu aplicaci\u00f3n.<\/p>\n Sin embargo, la elecci\u00f3n de la arquitectura adecuada ampl\u00eda a\u00fan m\u00e1s estos beneficios.<\/p>\n Estas son algunas de las principales razones por las que deber\u00edas considerar seriamente adoptar una arquitectura de aplicaciones web.<\/p>\n Tu aplicaci\u00f3n es una puerta de entrada clave para tu negocio, y las necesidades empresariales evolucionan con los cambios del mercado. Para mantener el ritmo, necesitar\u00e1s que tu aplicaci\u00f3n sea lo suficientemente flexible como para adaptarse a las necesidades cambiantes de tu negocio. Y si construyes una aplicaci\u00f3n sin tener en cuenta la posibilidad de flexibilidad, es probable que en un futuro desperdicies cada vez m\u00e1s tiempo y esfuerzo haciendo peque\u00f1os ajustes en tu aplicaci\u00f3n.<\/p>\n Una arquitectura de aplicaci\u00f3n web adecuada ya tiene en cuenta algunos de los cambios que tu negocio podr\u00eda necesitar en el futuro. Por ejemplo, si sabes que est\u00e1s construyendo una aplicaci\u00f3n de comercio electr\u00f3nico que un d\u00eda escalar\u00e1 y ofrecer\u00e1 una amplia gama de servicios a un gran n\u00famero de clientes, elegir una arquitectura de microservicios en lugar de una monol\u00edtica te proporcionar\u00e1 m\u00e1s flexibilidad.<\/p>\n Por otro lado, si est\u00e1s construyendo una aplicaci\u00f3n interna para tu empresa con s\u00f3lo uno o dos requisitos fijos, puedes optar por un monolito m\u00e1s sencillo para acelerar el desarrollo y mantener tu c\u00f3digo base limpio.<\/p>\n Como hemos mencionado anteriormente, la arquitectura correcta de la aplicaci\u00f3n web te proporciona una hoja de ruta m\u00e1s adecuada para el desarrollo. La arquitectura proporciona suficiente modularidad en tu sistema para aislar los componentes seg\u00fan sea necesario, y obtienes la libertad de elegir la estructura de proyecto adecuada para cada uno de tus m\u00f3dulos y componentes seg\u00fan sea necesario.<\/p>\n Si te sumerges en el desarrollo de una aplicaci\u00f3n sin una arquitectura en mente, te arriesgas a perder tiempo y dinero reorganizando tus componentes y estableciendo nuevas reglas que faciliten la colaboraci\u00f3n entre los miembros de tu equipo<\/a> \u2014 tiempo y dinero que de otro modo podr\u00edas haber invertido en otra cosa.<\/p>\n Adem\u00e1s de escribir el c\u00f3digo de tu aplicaci\u00f3n, tambi\u00e9n pasar\u00e1s una cantidad considerable de tiempo gestion\u00e1ndolo. Organizar los archivos de tu proyecto, dividir tu aplicaci\u00f3n en m\u00f3dulos y establecer canalizaciones personalizadas son s\u00f3lo algunas de las tareas que requieren un mantenimiento activo para garantizar un desarrollo fluido.<\/p>\n Una arquitectura de aplicaci\u00f3n web adecuada te facilita la realizaci\u00f3n de cambios. Puedes aplicar las mejores pr\u00e1cticas espec\u00edficas de cada componente, separar los puntos de dolor de tu aplicaci\u00f3n y mantener cada funci\u00f3n 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\u00e1s sencillo.<\/p>\n Seguir una arquitectura predefinida tambi\u00e9n te facilita desarrollar tus aplicaciones m\u00e1s r\u00e1pidamente. La arquitectura adecuada, combinada con una buena estrategia de control de versiones<\/a>, puede permitir a tus desarrolladores trabajar en paralelo y crear funciones m\u00e1s r\u00e1pidamente.<\/p>\n La arquitectura de una aplicaci\u00f3n web tambi\u00e9n asegura el futuro de tu aplicaci\u00f3n. Una vez que definas una estrategia s\u00f3lida sobre c\u00f3mo organizar los componentes de tu aplicaci\u00f3n, podr\u00e1s migrar f\u00e1cilmente esos componentes a tecnolog\u00edas m\u00e1s nuevas, uno por uno, sin tener que rehacer toda la aplicaci\u00f3n.<\/p>\n La mayor\u00eda de las arquitecturas de aplicaciones web tienen en cuenta la seguridad al estructurar los componentes. Los desarrolladores pueden planificar, con antelaci\u00f3n, las medidas y pr\u00e1cticas que deben aplicar para mejorar la seguridad de la aplicaci\u00f3n<\/a> antes de ponerla a disposici\u00f3n de los usuarios.<\/p>\n Por ejemplo, crear una aplicaci\u00f3n de streaming de v\u00eddeo<\/a> OTT que ofrezca contenidos gratuitos y de pago utilizando microservicios tiene m\u00e1s sentido, ya que la arquitectura de microservicios te permite dividir tu aplicaci\u00f3n en componentes que se adapten al negocio, como la autenticaci\u00f3n del usuario<\/a> y el streaming de contenidos gratuitos o de pago. Si tu m\u00f3dulo de autenticaci\u00f3n de usuarios deja de funcionar, puedes configurar f\u00e1cilmente tu aplicaci\u00f3n para restringir el acceso al m\u00f3dulo de contenido de pago<\/a> hasta que se restablezca la autenticaci\u00f3n, mientras que el m\u00f3dulo de contenido gratuito sigue estando disponible para tus usuarios.<\/p>\n Si esta misma aplicaci\u00f3n estuviera dise\u00f1ada como un monolito perfectamente integrado, un servicio de autenticaci\u00f3n ca\u00eddo significar\u00eda una aplicaci\u00f3n ca\u00edda<\/a> o un contenido de pago disponible de forma gratuita \u2014\u00a0 resultados que querr\u00e1s evitar a toda costa.<\/p>\n Antes de hablar de c\u00f3mo funciona la arquitectura de las aplicaciones web, es importante entender c\u00f3mo funciona un sitio web sencillo:<\/p>\n Si quieres profundizar un poco m\u00e1s, as\u00ed es como una aplicaci\u00f3n web<\/em> gestionar\u00eda una solicitud:<\/p>\n Ahora que tienes una idea b\u00e1sica de lo que es la arquitectura de las aplicaciones web, vamos a echar un vistazo detallado a algunos de los tipos m\u00e1s populares de arquitectura de aplicaciones web que se utilizan en la red.<\/p>\n La arquitectura de una aplicaci\u00f3n de una sola p\u00e1gina (SPA) es tan sencilla como su nombre: toda la aplicaci\u00f3n se basa en una sola p\u00e1gina. Una vez que el usuario accede a tu aplicaci\u00f3n, no necesita navegar a ninguna otra p\u00e1gina web. La aplicaci\u00f3n se hace lo suficientemente din\u00e1mica como para obtener y renderizar pantallas que satisfagan los requisitos de los usuarios mientras navegan por la propia aplicaci\u00f3n.<\/p>\n Las SPA son estupendas cuando se trata de proporcionar una experiencia r\u00e1pida y sin fisuras a los usuarios finales o consumidores. Sin embargo, carecen del toque de un sitio web tradicional, y pueden ser dif\u00edciles de optimizar para el SEO<\/a>.<\/p>\n Algunos de los pros de la arquitectura SPA son:<\/p>\n Algunos de los inconvenientes de la arquitectura SPA son:<\/p>\n La arquitectura de la Aplicaci\u00f3n Web Progresiva (PWA) se basa en la Arquitectura de P\u00e1gina \u00danica proporcionando capacidades offline para tu aplicaci\u00f3n web. Tecnolog\u00edas como Capacitor e Ionic se utilizan para crear PWA que pueden proporcionar a los usuarios una experiencia uniforme<\/a> en todas las plataformas.<\/p>\n Al igual que las SPA, las PWA son fluidas y sin fisuras. Con la capacidad a\u00f1adida de instalarse en los dispositivos de los usuarios (a trav\u00e9s de service workers), tus usuarios obtienen una experiencia m\u00e1s uniforme con tu aplicaci\u00f3n.<\/p>\n Al mismo tiempo, puede ser dif\u00edcil optimizar estas aplicaciones para el SEO, y las actualizaciones de las aplicaciones instaladas pueden ser dif\u00edciles de impulsar.<\/p>\n Hay muchas ventajas de la arquitectura PWA, entre ellas:<\/p>\n Algunos de los contras de la arquitectura PWA pueden ser:<\/p>\n En la renderizaci\u00f3n del lado del servidor (SSR), las p\u00e1ginas web del frontend se renderizan en un servidor backend despu\u00e9s de ser solicitadas por el usuario. Esto ayuda a reducir la carga en el dispositivo del cliente, ya que recibe una p\u00e1gina web est\u00e1tica de HTML, CSS y JS.<\/p>\n Las aplicaciones SSR son muy populares entre los blogs y los sitios web de comercio electr\u00f3nico. Esto se debe a que hacen que la gesti\u00f3n de enlaces y el SEO sean bastante sencillos. Adem\u00e1s, la primera representaci\u00f3n de las aplicaciones SSR es bastante r\u00e1pida, ya que el cliente no tiene que procesar ning\u00fan c\u00f3digo JS para representar las pantallas.<\/p>\n A continuaci\u00f3n se enumeran algunas de las ventajas de la arquitectura SSR:<\/p>\n Algunos de los inconvenientes de utilizar la arquitectura SSR son:<\/p>\n La arquitectura de aplicaciones pre-renderizadas tambi\u00e9n se conoce como arquitectura de generaci\u00f3n de sitios est\u00e1ticos. En esta arquitectura, las p\u00e1ginas web del frontend de la aplicaci\u00f3n se generan previamente y se almacenan como archivos HTML, CSS y JS planos en el servidor. Una vez que el usuario solicita una p\u00e1gina, \u00e9sta se obtiene directamente y se le muestra. Esto hace que la aplicaci\u00f3n web sea muy r\u00e1pida, con tiempos de carga m\u00ednimos de cualquier tipo. Sin embargo, esta arquitectura aumenta el tiempo de construcci\u00f3n de la aplicaci\u00f3n, ya que las p\u00e1ginas web se renderizan durante el proceso de construcci\u00f3n.<\/p>\n Las aplicaciones web prerrenderizadas son estupendas para cuando quieres generar contenido est\u00e1tico, como blogs o detalles de productos que no cambian a menudo. Tambi\u00e9n puedes utilizar plantillas para simplificar el dise\u00f1o de tu p\u00e1gina web. Sin embargo, es casi imposible crear aplicaciones web din\u00e1micas con esta arquitectura.Si quieres construir una p\u00e1gina de b\u00fasqueda que tome la consulta en su ruta (algo as\u00ed como Dado que cada posible ruta de la aplicaci\u00f3n se pre-renderiza durante el proceso de construcci\u00f3n, es imposible tener rutas din\u00e1micas como las anteriores, ya que hay infinitas posibilidades que no pueden pre-renderizarse durante la construcci\u00f3n (y tampoco tiene sentido hacerlo).<\/p>\n Algunas de las principales ventajas de la arquitectura de aplicaciones prerrenderizadas son:<\/p>\n Como cualquier modelo de arquitectura, la pre-renderizada tiene sus inconvenientes:<\/p>\n Las aplicaciones isom\u00f3rficas 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\u00f3n 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\u00e1s r\u00e1pido y eficiente por parte del cliente. Esto convierte esencialmente la aplicaci\u00f3n en una aplicaci\u00f3n de una sola p\u00e1gina.<\/p>\n Isomorphic re\u00fane lo mejor de ambos mundos. El procesamiento y la interfaz de usuario del cliente son superr\u00e1pidos, gracias a la SPA. Tambi\u00e9n obtienes un renderizado inicial r\u00e1pido y un soporte completo de SEO y enlaces, gracias al renderizado del lado del servidor.<\/p>\n \u00c9stas son algunas de las ventajas de utilizar una arquitectura de aplicaci\u00f3n isom\u00f3rfica:<\/p>\n Algunos de los contras de la arquitectura de aplicaci\u00f3n isom\u00f3rfica pueden ser:<\/p>\n La arquitectura orientada a servicios es una de las alternativas m\u00e1s 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\u00e1n d\u00e9bilmente acoplados e interact\u00faan entre s\u00ed mediante el paso de mensajes.<\/p>\n La arquitectura orientada a servicios a\u00f1ade estabilidad y escalabilidad al stack tecnol\u00f3gico de tu aplicaci\u00f3n. Sin embargo, el tama\u00f1o de los servicios en la SOA no est\u00e1n claramente definidos y suelen estar vinculados a los componentes de negocio, no a los componentes t\u00e9cnicos; de ah\u00ed que el mantenimiento pueda ser a veces un problema.<\/p>\n Las principales ventajas de la arquitectura orientada a servicios son:<\/p>\n Aqu\u00ed tienes una lista de los posibles inconvenientes de utilizar la arquitectura orientada a servicios:<\/p>\n La arquitectura de microservicios fue dise\u00f1ada para resolver los problemas de la arquitectura orientada a servicios. Los microservicios son componentes a\u00fan m\u00e1s modulares que encajan entre s\u00ed para construir una aplicaci\u00f3n web. Sin embargo, los microservicios se centran en mantener cada componente peque\u00f1o y con un contexto limitado. Contexto delimitado significa esencialmente que cada microservicio tiene su c\u00f3digo y sus datos acoplados con m\u00ednimas dependencias de otros microservicios.<\/p>\n La arquitectura de microservicios es probablemente la mejor arquitectura para construir aplicaciones que pretenden escalar alg\u00fan d\u00eda a miles y millones de usuarios. Cada componente es resistente, escalable y f\u00e1cil de mantener. Sin embargo, el mantenimiento del ciclo de vida de DevOps para una aplicaci\u00f3n basada en microservicios requiere esfuerzos adicionales, por lo que podr\u00eda no ser adecuado para casos de uso m\u00e1s peque\u00f1os.<\/p>\n Algunas de las ventajas de la arquitectura de microservicios son:<\/p>\n Un inconveniente de la arquitectura de microservicios puede ser:<\/p>\n 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\u00f3n en t\u00e9rminos de las funciones que debe realizar. A continuaci\u00f3n, estas funciones se alojan en plataformas FaaS (Function-as-a-Service) como funciones que se invocan a medida que llegan las solicitudes.<\/p>\n A diferencia de la mayor\u00eda 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\u00edan las funciones \u2014 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\u00edcil llevar a cabo tareas de larga duraci\u00f3n utilizando estos componentes.<\/p>\n Estas son las principales ventajas de la arquitectura sin servidor:<\/p>\n A continuaci\u00f3n se presentan algunos de los inconvenientes de la arquitectura sin servidor:<\/p>\n Aunque las arquitecturas de aplicaciones web que has visto anteriormente pueden parecer muy diferentes entre s\u00ed, sus componentes pueden agruparse l\u00f3gicamente en capas definidas que ayudan a alcanzar un objetivo empresarial.<\/p>\n La capa de presentaci\u00f3n representa todo lo que en una aplicaci\u00f3n web se expone a los usuarios finales. Principalmente, la capa de presentaci\u00f3n est\u00e1 compuesta por el cliente del frontend. Sin embargo, tambi\u00e9n incorpora cualquier l\u00f3gica que hayas escrito en tu backend para hacer que tu frontend sea din\u00e1mico. Esto te da la posibilidad de servir a tus usuarios con una interfaz de usuario adaptada a su perfil y requisitos.<\/p>\n Para construir esta capa se utilizan tres tecnolog\u00edas fundamentales: HTML, CSS y JavaScript. El HTML dise\u00f1a tu frontend, el CSS le da estilo y el JS le da vida (es decir, controla su comportamiento cuando los usuarios interact\u00faan con \u00e9l). Adem\u00e1s de estas tres tecnolog\u00edas, puedes utilizar cualquier tipo de framework<\/a> para facilitar tu desarrollo. Algunos frameworks de frontend comunes son Laravel<\/a>, React, NextJS, Vue, GatsbyJS, etc.<\/p>\n La capa de negocio es responsable de mantener y gestionar la l\u00f3gica de funcionamiento de tu aplicaci\u00f3n. Suele ser un servicio de backend que acepta las peticiones del cliente y las procesa. Controla a qu\u00e9 puede acceder el usuario y determina c\u00f3mo se utiliza la infraestructura para atender las peticiones de los usuarios.<\/p>\n En el caso de una aplicaci\u00f3n de reserva de hoteles, tu aplicaci\u00f3n 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\u00f3n de b\u00fasqueda, la capa de negocio recibe la petici\u00f3n y pone en marcha la l\u00f3gica para buscar las habitaciones de hotel disponibles que coincidan con sus requisitos. A continuaci\u00f3n, el cliente se limita a recibir una lista de habitaciones de hotel sin saber c\u00f3mo se ha generado esta lista ni siquiera por qu\u00e9 los elementos de la lista est\u00e1n dispuestos de la forma en que se han enviado.<\/p>\n La presencia de una capa de este tipo garantiza que tu l\u00f3gica de negocio no est\u00e9 expuesta a tu cliente y, en \u00faltima instancia, a los usuarios. Aislar la l\u00f3gica de negocio ayuda enormemente en operaciones sensibles como la gesti\u00f3n de pagos o la gesti\u00f3n de registros sanitarios.<\/p>\n La capa de persistencia se encarga de controlar el acceso a tus almacenes de datos. Act\u00faa como una capa de abstracci\u00f3n a\u00f1adida 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.<\/p>\n Esta capa suele consistir en un servidor de base de datos<\/a>. Puedes establecer esta capa t\u00fa mismo aprovisionando una base de datos y un servidor de bases de datos en tu infraestructura on-prem u optar por una soluci\u00f3n remota\/gestionada por uno de los principales proveedores de infraestructura en la nube como AWS, GCP, Microsoft Azure, etc.<\/p>\n Ahora que entiendes lo que hay en la arquitectura de una aplicaci\u00f3n web, vamos a echar un vistazo detallado a cada uno de los componentes que componen una aplicaci\u00f3n web. Agruparemos esta discusi\u00f3n en dos grandes apartados: componentes del lado del servidor y componentes del lado del cliente, o componentes del backend y del frontend<\/a>.<\/p>\n Los componentes del lado del servidor son los que residen en el backend de tu aplicaci\u00f3n web. No est\u00e1n expuestos directamente a los usuarios y contienen la l\u00f3gica de negocio y los recursos m\u00e1s importantes de tu aplicaci\u00f3n web.<\/p>\n El DNS es responsable de controlar c\u00f3mo se expone tu aplicaci\u00f3n a la web. Los registros DNS son utilizados por los clientes HTTP, que tambi\u00e9n pueden ser un navegador, para encontrar y enviar solicitudes a los componentes de tu aplicaci\u00f3n. El DNS tambi\u00e9n es utilizado por tus clientes frontend internamente para resolver la ubicaci\u00f3n de tus servidores web y endpoints de la API para enviar solicitudes y procesar las operaciones de los usuarios.<\/p>\n 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\u00e9nticos. La intenci\u00f3n de tener varios servidores web es mantener la redundancia que ayuda a aumentar la tolerancia a los fallos, as\u00ed como distribuir el tr\u00e1fico para mantener un alto rendimiento.<\/p>\n Los endpoints de la API se utilizan para exponer los servicios del backend a la aplicaci\u00f3n del frontend. Estos ayudan a facilitar la comunicaci\u00f3n entre el cliente y el servidor, y a veces incluso entre varios servidores.<\/p>\n El almacenamiento de datos es una parte crucial de la mayor\u00eda de las aplicaciones modernas, ya que siempre hay algunos datos de la aplicaci\u00f3n que deben persistir a trav\u00e9s de las sesiones de los usuarios. El almacenamiento de datos es de dos tipos:<\/p>\n El almacenamiento en cach\u00e9 es una caracter\u00edstica opcional que suele implementarse en las arquitecturas de las aplicaciones web para servir el contenido m\u00e1s r\u00e1pidamente 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 \u00e9l desde un almac\u00e9n de datos y procesarlo antes de enviarlo al usuario, a menudo se almacena en cach\u00e9. Estos son los dos tipos m\u00e1s populares de almacenamiento en cach\u00e9 que se utilizan en las aplicaciones web:<\/p>\n Aparte de exponer una interfaz a los usuarios (frontend) y gestionar sus peticiones (backend), hay otra categor\u00eda 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\u00f3n.<\/p>\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\u00e1ticamente en momentos determinados. Algunos ejemplos comunes de uso de estos trabajos incluyen la eliminaci\u00f3n de duplicados\/registros antiguos de la base de datos, el env\u00edo de correos electr\u00f3nicos recordatorios a los clientes, etc.<\/p>\n Los componentes del lado del cliente son los que se exponen a tus usuarios directa o indirectamente.<\/p>\n Hay principalmente dos tipos de componentes en esta categor\u00eda.<\/p>\n La interfaz de usuario es el aspecto visual de tu aplicaci\u00f3n. Es lo que tus usuarios ven y con lo que interact\u00faan para acceder a tus servicios.<\/p>\n La interfaz del frontend se construye principalmente con tres tecnolog\u00edas populares: HTML, CSS y JavaScript<\/a>. La interfaz de usuario del frontend puede ser una aplicaci\u00f3n en s\u00ed misma con su propio ciclo de vida de desarrollo de software.<\/p>\n Estas interfaces de usuario no albergan gran parte de tu l\u00f3gica de negocio, ya que est\u00e1n expuestas directamente a tus usuarios. Si un usuario malintencionado intenta aplicar ingenier\u00eda inversa a tu aplicaci\u00f3n de frontend, puede obtener informaci\u00f3n sobre el funcionamiento de tu negocio y llevar a cabo actividades ilegales como la suplantaci\u00f3n de la marca<\/a> y el robo de datos.<\/p>\n Adem\u00e1s, como la interfaz de usuario del frontend est\u00e1 expuesta directamente a los usuarios, deber\u00e1s optimizarla para que la capacidad de respuesta y el tiempo de carga sean m\u00ednimos<\/a>. A veces esto puede ayudarte a proporcionar una mejor experiencia a tus usuarios, aumentando as\u00ed el crecimiento de tu negocio.<\/p>\n A veces puedes necesitar almacenar alguna l\u00f3gica de negocio en tu cliente para realizar operaciones m\u00e1s sencillas con rapidez. La l\u00f3gica del lado del cliente, que suele residir en tu aplicaci\u00f3n frontend, puede ayudarte a saltarte el viaje al servidor y proporcionar a tus usuarios una experiencia m\u00e1s r\u00e1pida.<\/p>\n Esta es una caracter\u00edstica opcional de los componentes del lado del cliente. En algunos casos, la l\u00f3gica de negocio de la aplicaci\u00f3n se almacena completamente en el lado del cliente (especialmente cuando se construye sin un servidor backend tradicional<\/a>). Las soluciones modernas como BaaS te ayudan a acceder a operaciones comunes como la autenticaci\u00f3n, el almacenamiento de datos, el almacenamiento de archivos, etc., sobre la marcha en tu aplicaci\u00f3n frontend.<\/p>\n Hay formas de ofuscar o minificar este c\u00f3digo<\/a> antes de lanzarlo a tus usuarios para minimizar las posibilidades de ingenier\u00eda inversa.<\/p>\n Hay varios modelos de arquitecturas de aplicaciones web, cada uno de ellos basado en c\u00f3mo se conectan los servidores web a sus almacenes de datos.<\/p>\n El modelo m\u00e1s sencillo de todos es un servidor web que se conecta a una instancia de base de datos. Este modelo es f\u00e1cil de implementar y mantener, y pasar a producci\u00f3n con \u00e9l tampoco supone ning\u00fan esfuerzo.<\/p>\n Debido a su simplicidad, este modelo es adecuado para el aprendizaje y para peque\u00f1as aplicaciones experimentales que no estar\u00e1n expuestas a un alto tr\u00e1fico. Los desarrolladores principiantes pueden configurar y trastear f\u00e1cilmente con estas aplicaciones para aprender los fundamentos del desarrollo de aplicaciones web<\/a>.<\/p>\n Sin embargo, este modelo no deber\u00eda utilizarse en producci\u00f3n, ya que es muy poco fiable. Un problema en el servidor o en la base de datos puede provocar tiempos de inactividad y p\u00e9rdidas de negocio.<\/p>\n Este modelo lleva la aplicaci\u00f3n a un nivel superior al establecer varios servidores para la redundancia con una \u00fanica instancia de base de datos com\u00fan.<\/p>\n Como varios servidores web acceden simult\u00e1neamente a la base de datos, pueden producirse problemas de inconsistencia. Para evitarlo, los servidores web est\u00e1n dise\u00f1ados 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.<\/p>\n Las aplicaciones realizadas con este modelo son ciertamente m\u00e1s fiables que las del modelo anterior, ya que la presencia de varios servidores web aumenta la tolerancia a los fallos de la aplicaci\u00f3n web. Sin embargo, como la base de datos sigue siendo una instancia com\u00fan, es el eslab\u00f3n m\u00e1s d\u00e9bil de la arquitectura y puede ser una fuente de fallos.<\/p>\n Este modelo es uno de los m\u00e1s comunes y tradicionales en el dise\u00f1o de aplicaciones web.<\/p>\n En este caso, despliega la l\u00f3gica de tu aplicaci\u00f3n como m\u00faltiples instancias id\u00e9nticas de servidor web agrupadas detr\u00e1s de un equilibrador de carga. Tu almac\u00e9n de datos tambi\u00e9n se mantiene en m\u00faltiples instancias de bases de datos para a\u00f1adir tolerancia a los fallos.<\/p>\n Tambi\u00e9n puedes elegir dividir tu base de datos entre las instancias disponibles para mejorar el rendimiento o mantener duplicados de todo el almac\u00e9n de datos para la redundancia. En cualquier caso, el fallo de una instancia de tu base de datos no provocar\u00e1 una interrupci\u00f3n completa de la aplicaci\u00f3n.<\/p>\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<\/a>. Por ello, este modelo s\u00f3lo se sugiere cuando se construye a gran escala.<\/p>\n Mientras que los tres modelos mencionados anteriormente son muy adecuados para las aplicaciones monol\u00edticas, hay otro modelo para las aplicaciones modulares.<\/p>\n El modelo de servicios de aplicaci\u00f3n descompone una aplicaci\u00f3n en m\u00f3dulos m\u00e1s peque\u00f1os basados en la funcionalidad del negocio. Estos m\u00f3dulos pueden ser tan peque\u00f1os como una funci\u00f3n o tan grandes como un servicio.<\/p>\n La idea aqu\u00ed es hacer que cada funci\u00f3n empresarial sea independiente y escalable. Cada uno de estos m\u00f3dulos puede conectarse a la base de datos por s\u00ed mismo. Incluso puedes tener instancias de base de datos dedicadas para satisfacer las necesidades de escalabilidad de tus m\u00f3dulos.<\/p>\n Entre las aplicaciones no monol\u00edticas, 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\u00f3n de las aplicaciones construidas con este modelo suele requerir desarrolladores experimentados<\/a>, especialmente con experiencia en DevOps y CI\/CD.<\/p>\n A continuaci\u00f3n, te presentamos algunas de las mejores pr\u00e1cticas que puedes implementar en tu proyecto de aplicaci\u00f3n web para sacar el m\u00e1ximo provecho de la arquitectura de aplicaci\u00f3n web elegida.<\/p>\n Esto no se puede recalcar lo suficiente: Procura que el frontend sea siempre responsivo<\/a>. No importa lo enorme y compleja que sea tu aplicaci\u00f3n web internamente, todo est\u00e1 expuesto a tus usuarios a trav\u00e9s de las p\u00e1ginas web, aplicaciones y pantallas del frontend.<\/p>\n Si tus usuarios encuentran estas pantallas poco intuitivas o lentas, no se quedar\u00e1n el tiempo suficiente para ver y admirar la maravilla de ingenier\u00eda que es tu aplicaci\u00f3n web.<\/p>\n Por lo tanto, dise\u00f1ar frontales accesibles, f\u00e1ciles de usar y ligeros es muy importante.<\/p>\n En la red hay muchas buenas pr\u00e1cticas de UI\/UX<\/a> que te ayudar\u00e1n a entender qu\u00e9 es lo que mejor funciona para tus usuarios. Puedes encontrar profesionales expertos en hacer dise\u00f1os y arquitecturas f\u00e1ciles de usar que permitan a tus usuarios sacar el m\u00e1ximo partido a tus aplicaciones.<\/p>\n Aconsejamos pensar seriamente en la capacidad de respuesta de tu frontend antes de lanzar tu producto a tus usuarios.<\/p>\n Adem\u00e1s de ser f\u00e1ciles de entender, tus interfaces deben cargarse r\u00e1pidamente<\/a>.<\/p>\n Seg\u00fan Portent<\/a>, las mayores tasas de conversi\u00f3n en el comercio electr\u00f3nico se dan en p\u00e1ginas con tiempos de carga de entre 0 y 2 segundos, y seg\u00fan Unbounce<\/a>, alrededor del 70% de los consumidores admiten que el tiempo de carga de la p\u00e1gina es un factor importante en su decisi\u00f3n de comprar a un vendedor online.<\/p>\n Al dise\u00f1ar aplicaciones nativas para m\u00f3viles, normalmente no puedes estar seguro de las especificaciones del dispositivo de tus usuarios. Cualquier dispositivo que no cumpla los requisitos de tu aplicaci\u00f3n suele declararse no compatible con ella.<\/p>\n Sin embargo, esto es muy diferente con la web.<\/p>\n Cuando se trata de aplicaciones web, tus usuarios pueden utilizar cualquier cosa, desde el \u00faltimo Macbook M1 Pros de Apple hasta tel\u00e9fonos Blackberry y Nokia antiguos para ver tu aplicaci\u00f3n. Optimizar la experiencia de tu frontend para una gama tan amplia de usuarios a veces puede ser dif\u00edcil.<\/p>\n Cuando se habla de rendimiento de la interfaz, se piensa en servicios como LightHouse y Google PageSpeed<\/a>. Deber\u00edas utilizar estas herramientas<\/a> para evaluar tu aplicaci\u00f3n frontend antes de desplegarla en producci\u00f3n. La mayor\u00eda de estas herramientas ofrecen una lista de consejos pr\u00e1cticos para ayudar a mejorar el rendimiento de la aplicaci\u00f3n en la medida de lo posible.<\/p>\n El 5-10% final del rendimiento de la aplicaci\u00f3n suele ser espec\u00edfico de tu caso de uso y s\u00f3lo puede ser arreglado por alguien que conozca bien tu aplicaci\u00f3n y sus tecnolog\u00edas. \u00a1Nunca est\u00e1 de m\u00e1s invertir en el rendimiento de la web<\/a>!<\/p>\n Como ya hemos comentado, las PWA son los dise\u00f1os del futuro. Se adaptan bien a la mayor\u00eda de los casos de uso, y proporcionan la experiencia m\u00e1s uniforme en las principales plataformas.<\/p>\n Deber\u00edas considerar el uso de PWA para tu aplicaci\u00f3n con la mayor frecuencia posible. La experiencia nativa a trav\u00e9s de la web y el m\u00f3vil es enormemente impactante para tus usuarios y puede reducir tambi\u00e9n gran parte de tu propia carga de trabajo.<\/p>\n Las PWA tambi\u00e9n son r\u00e1pidas de cargar, f\u00e1ciles de optimizar y r\u00e1pidas de construir. Optar por las PWA puede ayudarte a desplazar gran parte de tu atenci\u00f3n del desarrollo al negocio desde el principio.<\/p>\n Una base de c\u00f3digo limpia puede ayudarte a detectar y resolver la mayor\u00eda de los problemas antes de que causen da\u00f1os. Aqu\u00ed tienes algunos consejos que puedes seguir para asegurarte de que tu c\u00f3digo base no te causa m\u00e1s problemas de los que deber\u00eda.<\/p>\n CI\/CD son las siglas de Integraci\u00f3n Continua\/Despliegue Continuo. Los procesos CI\/CD son cruciales para el desarrollo de tu aplicaci\u00f3n, ya que te ayudan a construir, probar y desplegar tu proyecto con facilidad.<\/p>\n Sin embargo, no quieres tener que ejecutarlos manualmente cada vez. En lugar de ello, debes establecer procesos que se activen autom\u00e1ticamente en funci\u00f3n de las actividades de tu proyecto. Por ejemplo, puedes configurar una canalizaci\u00f3n que ejecute tus pruebas autom\u00e1ticamente cada vez que env\u00edes el c\u00f3digo a tu sistema de control de versiones<\/a>. Tambi\u00e9n hay muchos casos de uso m\u00e1s complejos, como generar artefactos multiplataforma desde tu repositorio de c\u00f3digo cada vez que se crea una versi\u00f3n.<\/p>\n Las posibilidades son infinitas, as\u00ed que depende de ti averiguar c\u00f3mo puedes sacar el m\u00e1ximo partido a tus canalizaciones CI\/CD.<\/p>\n La mayor\u00eda de las aplicaciones modernas est\u00e1n formadas por m\u00faltiples componentes. Toma como ejemplo la siguiente aplicaci\u00f3n:<\/p>\n Las peticiones de los clientes se dirigen a la aplicaci\u00f3n a trav\u00e9s de una pasarela API. Aunque \u00e9sta actualmente s\u00f3lo permite realizar peticiones directas al m\u00f3dulo de inicio de la app, en el futuro podr\u00eda permitir el acceso a m\u00e1s componentes sin pasar por el m\u00f3dulo de inicio.<\/p>\n A continuaci\u00f3n, el m\u00f3dulo de inicio comprueba un BaaS de autenticaci\u00f3n externa antes de permitir el acceso. Una vez autenticado, el cliente puede acceder a las p\u00e1ginas \u00abActualizar perfil\u00bb o \u00abVer perfil\u00bb. Estas dos p\u00e1ginas interact\u00faan con una soluci\u00f3n de base de datos com\u00fan y gestionada que maneja los datos del perfil.<\/p>\n Como puedes ver, la aplicaci\u00f3n parece una versi\u00f3n muy b\u00e1sica y m\u00ednima de un directorio de personas online<\/a>. Puedes a\u00f1adir\/actualizar tu propio perfil o ver otros perfiles disponibles.<\/p>\n Aqu\u00ed tienes una leyenda r\u00e1pida de los distintos componentes de la arquitectura:<\/p>\n Los componentes de cada uno de los colores de arriba son vulnerables a varios tipos de amenazas de seguridad. Aqu\u00ed tienes algunas construcciones de seguridad que puedes poner en marcha para minimizar tu exposici\u00f3n:<\/p>\n Aunque s\u00f3lo 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\u00fan 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\u00e1 distribuida por toda su arquitectura.<\/p>\n Los comentarios de los usuarios<\/a> son una herramienta crucial para comprender lo bien que funciona tu aplicaci\u00f3n en t\u00e9rminos de rendimiento empresarial y t\u00e9cnico. Puedes construir la aplicaci\u00f3n m\u00e1s ligera y fluida del mundo, pero si no permite a tus usuarios hacer lo que esperan, todos tus esfuerzos se ir\u00e1n al garete.<\/p>\n Existen m\u00faltiples formas de recoger las opiniones de los usuarios. Mientras que una encuesta r\u00e1pida y an\u00f3nima<\/a> es el enfoque convencional, tambi\u00e9n podr\u00edas optar por una soluci\u00f3n m\u00e1s sofisticada, como un mapa de calor de la actividad de tus usuarios.<\/p>\n![\"Diagrama](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2022\/10\/web-app-architecture-components.jpg\")
\u00bfPor Qu\u00e9 es Importante la Arquitectura de las Aplicaciones Web?<\/h2>\n
Se Adapta F\u00e1cilmente a las Necesidades del Negocio<\/h3>\n
Desarrollo Organizado<\/h3>\n
Mejor Gesti\u00f3n de la Base de C\u00f3digo<\/h3>\n
Seguridad Mejorada<\/h3>\n
\u00bfC\u00f3mo Funciona la Arquitectura de las Aplicaciones Web?<\/h2>\n
\n
\n
Tipos de Arquitectura de Aplicaciones Web<\/h2>\n
Arquitectura de Una Sola P\u00e1gina<\/h3>\n
Ventajas de la Arquitectura SPA<\/h4>\n
\n
Inconvenientes de la Arquitectura SPA<\/h4>\n
\n
Arquitectura de Aplicaciones Web Progresivas<\/h3>\n
Ventajas de la Arquitectura PWA<\/h4>\n
\n
Contras de la Arquitectura PWA<\/h4>\n
\n
Arquitectura de Renderizado del Lado del Servidor<\/h3>\n
Ventajas de la Arquitectura SSR<\/h4>\n
\n
Contras de la Arquitectura SSR<\/h4>\n
\n
Arquitectura de Aplicaciones Prerrenderizadas<\/h3>\n
https:\/\/myapp.com\/search\/foo+bar<\/code>), est\u00e1s en el lugar equivocado.<\/p>\nVentajas de la Arquitectura Prerrenderizada<\/h4>\n
\n
Contras de la Arquitectura Prerrenderizada<\/h4>\n
\n
Arquitectura de Aplicaciones Isom\u00f3rficas<\/h3>\n
Ventajas de la Arquitectura Isom\u00f3rfica<\/h4>\n
\n
Contras de la Arquitectura Isom\u00f3rfica<\/h4>\n
\n
Arquitectura Orientada al Servicio<\/h3>\n
Ventajas de la Arquitectura Orientada a Servicios<\/h4>\n
\n
Contras de la Arquitectura Orientada a Servicios<\/h4>\n
\n
Arquitectura de Microservicios<\/h3>\n
Ventajas de la Arquitectura de Microservicios<\/h4>\n
\n
Contras de la Arquitectura de Microservicios<\/h4>\n
\n
Arquitectura Sin Servidor<\/h3>\n
Ventajas de la Arquitectura Sin Servidor<\/h4>\n
\n
Inconvenientes de la Arquitectura sin Servidor<\/h4>\n
\n
Capas de la Arquitectura de Aplicaciones Web<\/h2>\n
Capa de Presentaci\u00f3n<\/h3>\n
Capa de Negocio<\/h3>\n
Capa de Persistencia<\/h3>\n
Componentes de la Aplicaci\u00f3n Web<\/h2>\n
Componentes del Lado del Servidor<\/h3>\n
DNS y Enrutamiento<\/h4>\n
Almacenamiento de Datos<\/h4>\n
\n
Almacenamiento en Cach\u00e9<\/h4>\n
\n
Trabajos y Servicios<\/h4>\n
Componentes del Lado del Cliente<\/h3>\n
Interfaz de Usuario del Frontend<\/h4>\n
L\u00f3gica Empresarial del Lado del Cliente<\/h4>\n
Modelos de Componentes de Aplicaciones Web<\/h3>\n
Un Servidor, Una Base de Datos<\/h4>\n
Varios Servidores, Una Base de Datos<\/h4>\n
M\u00faltiples Servidores, M\u00faltiples Bases de Datos<\/h4>\n
Servicios de Aplicaciones<\/h4>\n
Mejores Pr\u00e1cticas para la Arquitectura de Aplicaciones Web<\/h2>\n
1. Haz que tu Frontend sea Responsivo<\/h3>\n
2. Controla los Tiempos de Carga<\/h3>\n
3. Siempre que sea Posible, es Preferible la PWA<\/h3>\n
4. Mant\u00e9n tu C\u00f3digo Base Limpio y Sucinto<\/h3>\n
\n
5. Automatiza tus procesos CI\/CD<\/h3>\n
6. Incorpora Funciones de Seguridad<\/h3>\n
![\"Diagrama](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2022\/09\/example-serverless-architecture.png\")
\n
\n
\n
\n
\n
\n
7. Recoge las Opiniones de los Usuarios<\/h3>\n