Cómo diseñar una aplicación web: una guía sobre arquitectura de software

¿Alguna vez has probado a preparar Pizza en casa? (sí!!! estamos hablando de tu comida favorita…)

¿Qué pasará si no haces una buena masa para la base de tu pizza? Seguro que toda la base de la Pizza se echará a perder y no podrás seguir con la preparación de tu plato favorito. 

How-to-Design-a-Web-Application-A-Guideline-on-Software-Architecture

Ya sea que esté haciendo una pizza o creando algún software, si no obtiene la base correcta, tendrá que comenzar todo de nuevo desde cero. En una aplicación web, la arquitectura de su aplicación es la base y debe elegirse cuidadosamente para construir una aplicación con éxito. Un buen desarrollador elige la arquitectura adecuada para la aplicación para evitar cualquier tipo de cambio importante en el diseño del software o posteriormente en el código de la aplicación. Cuando un desarrollador elige la arquitectura correcta durante la fase de diseño inicial, el proceso de desarrollo se vuelve más fácil y también se pueden ahorrar muchos recursos financieros y de ingeniería. En este artículo, analicemos este tema en detalle y centrémonos en algunos aspectos clave para elegir la arquitectura adecuada para una aplicación web. 

Diferencia entre arquitectura de software y diseño de software

Ambos no son lo mismo… ¡¡¡sí!!! Lo escuchaste bien (no te confundas y entendamos cómo ambos son diferentes).

Arquitectura de software

Los componentes de alto nivel de un sistema, la relación entre estos componentes y cómo funcionan juntos es parte de la arquitectura del software. Es el esqueleto de cualquier aplicación. Por ejemplo:

  • Elegir una arquitectura sin servidor que divida la aplicación en dos componentes: BaaS (backend como servicio) y FaaS (funciones como servicio)
  • Elegir una arquitectura de microservicio donde las diferentes características/tareas se dividen en módulos/bases de código respectivos individuales.

Cuando elige una arquitectura, debe considerar algunas métricas, como el manejo del rendimiento, la tolerancia a fallas, la escalabilidad y la confiabilidad .

Diseño de software

El código que escribe en su aplicación para diferentes módulos, clases, funciones y otras características se considera diseño de software. El diseño de nivel de código define qué módulo está haciendo qué, el alcance de las clases, las funciones y su propósito, etc. Para implementar y administrar este código en un equipo más grande, se usa un lenguaje/patrón común (patrón de diseño de software ) para conceptualizar problemas repetidos. y soluciones Un desarrollador puede volverse más eficiente en la implementación del código si utiliza estos métodos o patrones que ya están definidos por otros. Lea el artículo Patrones de diseño: comprenda la importancia con ejemplos de la vida real para comprender claramente los patrones de diseño de software. 

Patrones de arquitectura de software

1. Cliente-servidor

La arquitectura cliente-servidor es una arquitectura de red y sigue el modelo de solicitud-respuesta . Aquí, el cliente puede ser cualquier dispositivo, como una PC o una estación de trabajo en la que los usuarios ejecutan aplicaciones. Estos clientes envían la solicitud al servidor para obtener información. Los servidores son computadoras poderosas dedicadas a administrar unidades de disco (servidores de archivos), impresoras (servidores de impresión) o tráfico de red (servidores de red). Cuando el servidor recibe la solicitud, la procesa y envía la respuesta al cliente. Facebook, Twitter, Skype, las aplicaciones bancarias y casi todas las empresas de redes sociales siguen esta arquitectura. 

Client-Server-Architecture

Esta arquitectura es una red de computadoras donde cada computadora funciona como un Node y estos Nodes pueden comunicarse entre sí sin ningún uso del servidor central . Cada computadora en la red tendrá las mismas capacidades/responsabilidades. El beneficio de esta arquitectura es que no existe el temor de un solo punto de falla . Si un Node deja de funcionar, el otro Node estará disponible para procesar la solicitud. P2P es la base de la tecnología blockchain.

Peer-to-Peer

 3. Modelo-Vista-Controlador (MVC)

En ingeniería de software, este patrón es muy popular y existe desde hace mucho tiempo. Esta arquitectura se puede utilizar en aplicaciones de escritorio, web o móviles. En MVC separamos toda la lógica de la aplicación en tres componentes. 

  • Modelos (Datos y Lógica): Representa y mantiene los datos de la aplicación en la base de datos. Cómo se almacena la información y cómo se puede recuperar. 
  • Vistas (interfaz de usuario): muestra los datos utilizando el modelo para el usuario, como una salida o una GUI.
  • Controlador (Request Handler): Maneja la solicitud del usuario y actúa como una interfaz entre modelos y vistas.

4. Microservicios

Esta arquitectura divide las tareas/características en módulos/bases de código respectivos separados . Estos módulos se coordinan entre sí para formar un gran servicio completo. Esta arquitectura brinda mucha más flexibilidad al desarrollador porque le permite elegir su lenguaje de programación para diferentes módulos. Las aplicaciones de arquitectura basada en microservicios son más fáciles de mantener, probar e implementar en comparación con la arquitectura monolítica. 

Microservice-Architecture

4. Impulsado por eventos

Las aplicaciones web modernas son populares por usar esta arquitectura. También se conoce como arquitectura sin bloqueo . Permite que las aplicaciones manejen numerosas requests simultáneas con un consumo mínimo de recursos. Es el más adecuado para aplicaciones que necesitan un modelo completamente asíncrono para escalar. 

Event-Driven-Architecture

5 . Arquitectura Maestro-Esclavo

Anteriormente en informática, esta arquitectura se definió en el contexto de la replicación de bases de datos. Por ejemplo, en una base de datos, replicamos los datos/información en tres servidores. Existe la posibilidad de inconsistencia porque uno de estos podría no estar sincronizado con los demás. La arquitectura maestro-esclavo resuelve este problema en el que tratamos una réplica como maestra y el resto se identifica como esclavo. En el escalado vertical, comúnmente usamos un enfoque de replicación donde uno almacena el código maestro y el otro son las réplicas de eso.

Master-Slave-Architecture

6. En capas

Toda la estructura del programa se divide en grupos de subtareas o capas, cada una de las cuales se encuentra en un nivel particular de abstracción. Cada una de las capas es responsable de proporcionar los servicios a la siguiente capa superior. Estas capas son…

  • Capa de presentación
  • Capa de aplicación
  • Capa de lógica de negocios
  • Capa de acceso a datos

¿Cuántos niveles debe tener su aplicación?

1. Aplicación de un solo nivel

ventajas:

  • Sin latencia de red
  • Los datos son fácilmente accesibles sin demora.
  • Garantice la seguridad de los datos.

Desventajas:

  • Menos control sobre la aplicación. Implementar una nueva característica o modificar el código es difícil.
  • Requiere pruebas en profundidad con errores mínimos.

2. Aplicación de dos niveles

ventajas:

  • Menos llamadas de red ya que el código y la interfaz de usuario existen en la misma máquina.
  • Tanto el servidor de la base de datos como la lógica empresarial están físicamente cerca, por lo que ofrece un rendimiento rápido.

Desventajas:

  • El cliente maneja la mayor parte de la lógica de la aplicación, por lo que resulta difícil reutilizar la lógica y controlar la versión del software, también en la redistribución de la versión más nueva.
  • Problema de escalabilidad. Cuando el número de requests aumenta, el rendimiento de la aplicación se degrada.

3. Aplicación de tres niveles

ventajas:

  • Para la actualización de la base de datos, los datos pasados ​​en el nivel medio aseguran su validez y eso elimina la corrupción de datos a través de una aplicación cliente.
  • La lógica empresarial se coloca en un servidor centralizado que garantiza la seguridad de los datos.
  • La escalabilidad de la aplicación se puede ampliar debido a la naturaleza distribuida de los servidores de aplicaciones. No es necesario tener una conexión separada de cada cliente, una conexión de pocos servidores de aplicaciones es suficiente.

Desventajas:

  • Debido al aumento de los puntos de comunicación (cliente a nivel medio al servidor, en lugar de directamente del cliente al servidor), se requiere más esfuerzo para crear una aplicación de tres niveles. Además, se degradará el rendimiento ampliado por herramientas como Visual Basic, PowerBuilder, Delphi.

4. Aplicación de N niveles

ventajas:

  • Todas las ventajas de una arquitectura de tres niveles.
  • La descarga desde el nivel de la base de datos y el nivel del cliente aumenta el rendimiento. 

Desventajas:

  • Los niveles se dividen en componentes y esa es la razón por la que se vuelve difícil implementar y mantener la estructura compleja.

Conclusión

  • Si no desea ninguna latencia de red, opte por una arquitectura de un solo nivel.
  • Si su prioridad es minimizar la latencia de la red y desea un mayor control de los datos dentro de la aplicación, elija una aplicación de dos niveles. 
  • Si desea tener control sobre los datos, control sobre el código o la lógica comercial en su aplicación y su preferencia es la seguridad, elija una aplicación de tres niveles. 
  • Si su principal preocupación es la escalabilidad, elija la arquitectura de N niveles.

Escalado horizontal o vertical: ¿cuál es bueno para una aplicación?

  • Si su aplicación recibe una cantidad mínima de tráfico constante y sabe que la carga de tráfico no aumentará significativamente, es bueno elegir la escala vertical . Puede actualizar el servidor o puede reemplazar el servidor con más capacidad. No hay necesidad de ir con una red distribuida.
  • Si su aplicación es similar a cualquier aplicación de redes sociales y el tráfico diario aumenta con más frecuencia, lo más probable es que aumente exponencialmente en breve. En este caso, la disponibilidad se convierte en la principal preocupación de cualquier aplicación. Por lo tanto, es bueno elegir la escala horizontal

¿Monolítico o Microservicio?

¿Cuándo usar la arquitectura monololítica?

  • Cuando los requisitos son bastante simples y el tráfico es limitado en la aplicación, vaya a la arquitectura monolítica (por ejemplo: aplicación de cálculo de impuestos). Si no ve un aumento exponencial en el tráfico en el futuro, entonces es bueno elegir esta arquitectura.

¿Cuándo usar la arquitectura de microservicios?

  • Es mejor para casos de uso complejos. Si sus aplicaciones reciben una gran cantidad de tráfico y se espera que el tráfico aumente exponencialmente en el futuro, entonces la arquitectura de microservicios es buena.
  • Si está creando una aplicación de red de medios sociales, para diferentes funciones, como mensajería, chat en tiempo real, transmisión de video en vivo, carga de imágenes, me gusta y uso compartido, implemente los componentes por separado. Tenga en cuenta los principios  de responsabilidad única y separación de intereses .

Nota: cuando comienza a crear una aplicación con un solo código base, la mayoría de las veces se convierte en una aplicación enorme. Esta es la razón por la que muchos desarrolladores comienzan con la arquitectura monolítica, pero luego amplían la aplicación a una arquitectura de microservicio. Por lo tanto, elegir una arquitectura depende de sus casos de uso y los requisitos. 

No SQL o SQL?

¿Cuándo elegir bases de datos SQL/relacionales?

  • Si está creando una aplicación basada en transacciones bursátiles, banca o finanzas , elija una base de datos relacional.
  • Las bases de datos relacionales son las más adecuadas para las aplicaciones en las que sus aplicaciones se ocupan de las transacciones o cumplen con las propiedades ACID . Para estas aplicaciones, la consistencia de los datos es extremadamente importante.
  • Las aplicaciones de redes sociales de Facebook almacenan datos con muchas relaciones , por ejemplo. Si los datos en su aplicación tienen muchas relaciones, entonces las bases de datos relacionales son las mejores para elegir en tales casos. Puedes tomar el ejemplo de una persona que vive en una ciudad en particular o alguien que visitó un hotel específico para sus vacaciones. Si está creando aplicaciones de redes sociales de tipo Facebook y necesita almacenar muchas relaciones, vaya a bases de datos relacionales/SQL.

MySQL, Microsoft SQL Server, PostgreSQL, MariaDB, todos estos son ejemplos de bases de datos relacionales populares. 

¿Cuándo elegir una base de datos NoSQL/no relacional?

  • Elija bases de datos no relacionales si su principal preocupación es el escalado de su aplicación. Las bases de datos NoSQL son más adecuadas cuando hay operaciones pesadas de lectura/escritura en su sitio web y necesita lidiar con la gran cantidad de requests de los usuarios. Con NoSQL, es fácil manejar el tráfico concurrente y una gran cantidad de requests con una latencia mínima.
  • Las bases de datos NoSQL también son la mejor opción para casos de uso  de análisis de datos .

MongoDB, Redis, Cassandra, HBase , todos estos son ejemplos de bases de datos populares no relacionales. 

¿Cuál es la tecnología adecuada para la aplicación?

1. Interacción de datos en tiempo real

Elija NodeJS, Tornado (marco de trabajo de Python), Spring Reactor, Play y Akka.io (para el ecosistema de Java ) si está creando una aplicación en la que necesita…

  • Comunicación en tiempo real con el servidor backend. Por ejemplo, una aplicación de transmisión de audio y video como Spotify, Netflix o cualquier tipo de aplicación de mensajería. 
  • Una conexión persistente entre el cliente y el servidor, y una tecnología sin bloqueo en el back-end.

2. Aplicación web punto a punto

  • Para las aplicaciones web peer-to-peer , por ejemplo, el motor de búsqueda distribuido P2P o el servicio de radio P2P Live TV (por ejemplo, LiveStation de Microsoft), puede elegir protocolos JavaScript como DAT e IPFS .
  • Un marco JavaScript freedom.js es adecuado para crear aplicaciones web P2P que funcionan en navegadores web modernos.

3. Aplicación regular basada en CRUD

  • Para aplicaciones simples basadas en CRUD, use PHP Laravel,  Python Django , Spring MVC, Ruby on Rails y ASP .NET MVC.

4. Aplicaciones a pequeña escala

  • Si está creando una aplicación simple como un blog, un formulario en línea, una aplicación simple que se integra con las redes sociales, entonces use PHP . También hay otras opciones, como Spring boot o Ruby on Rails . Estas tecnologías toman menos tiempo de desarrollo o configuración, pero el alojamiento de PHP es mucho más asequible en comparación con otras tecnologías, también es mejor para casos de uso simples.

5. Aplicaciones con uso intensivo de memoria y CPU

  • Los marcos web regulares o los lenguajes de secuencias de comandos son buenos para crear aplicaciones web, pero estos lenguajes no son adecuados para ejecutar un uso intensivo de CPU, uso intensivo de memoria o para realizar tareas informáticas pesadas en el back-end. Para todas las tareas anteriores y el procesamiento de big data, el procesamiento paralelo o la ejecución de monitoreo y análisis en grandes cantidades de datos, C++ es el lenguaje más utilizado en la comunidad tecnológica. Facilita la manipulación de memoria de bajo nivel y los desarrolladores pueden escribir sistemas distribuidos con más control sobre la memoria. La mayoría de las criptomonedas están escritas en C++ .
  • Rust es similar a C++, que proporciona un alto rendimiento y una concurrencia segura. Las industrias también están utilizando Java, Scala y Erlang. Java es bueno para sistemas empresariales a gran escala.
  • El lenguaje de programación Go es bueno para máquinas multinúcleo y para manejar una gran cantidad de datos.
  • Julia es un lenguaje programado dinámicamente con una función de alto rendimiento. Es adecuado para la aplicación de cálculos en ejecución y análisis numérico. 

Conclusión

Cualesquiera que sean los puntos que hemos discutido a lo largo de este artículo, es importante recordarlos cuando comienza con la arquitectura de software. Antes de ensuciarse las manos con el código, asegúrese de elegir la arquitectura de software correcta, la base de datos correcta, la tecnología correcta y la opción de escalabilidad correcta. Tenga en cuenta todos los puntos anteriores y le ayudará en el largo plazo. 

Publicación traducida automáticamente

Artículo escrito por anuupadhyay y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *