Skip to content

Commit

Permalink
added latency
Browse files Browse the repository at this point in the history
  • Loading branch information
clsource committed Feb 29, 2024
1 parent a562d5b commit 2d5c3dd
Show file tree
Hide file tree
Showing 94 changed files with 764 additions and 63 deletions.
2 changes: 2 additions & 0 deletions book/bibliography.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -12,5 +12,7 @@ Una lista de recursos complementarios y referenciales.

- [[tejiendolared]] Tim Berners-Lee. 'Tejiendo la Red'. ISBN 84-323-1040-9

- [[systemdesign]] Alex Xu. 'System Design Interview: An Insider’s Guide'. ISBN 979-8664653403.

//.Sitios Web
//- [[[googlepython]]] Google. 'Python Class' http://code.google.com/edu/languages/google-python-class/
77 changes: 66 additions & 11 deletions book/chapters/patterns/chapter.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -53,39 +53,94 @@ En este sentido, podemos decir que los Microservicios son todo lo contrario a la
* https://reactiveprogramming.io/blog/es/estilos-arquitectonicos/eda[Event Driven]
* https://reactiveprogramming.io/blog/es/estilos-arquitectonicos/microkernel[MicroKernel]

=== Patrón MVC
=== Patrón Modelo Vista Controlador

MVC (Modelo-Vista-Controlador) es un patrón en el diseño de software comúnmente utilizado para implementar interfaces de usuario, datos y lógica de control. Enfatiza una separación entre la lógica de negocios y su visualización. Esta "separación de preocupaciones" proporciona una mejor división del trabajo y una mejora de mantenimiento. Algunos otros patrones de diseño se basan en MVC, como MVVM (Modelo-Vista-modelo de vista), MVP (Modelo-Vista-Presentador) y MVW (Modelo-Vista-Whatever).
MVC (Modelo-Vista-Controlador) es un patrón en el diseño de software comúnmente utilizado para implementar interfaces de usuario, datos y lógica de control. Enfatiza una separación entre la lógica de negocios y su visualización. Esta "separación de preocupaciones" proporciona una mejor división del trabajo y una mejora de mantenimiento. Algunos otros patrones de diseño se basan en MVC, como MVVM (Modelo-Vista-VistaModelo), MVP (Modelo-Vista-Presentador) y MVW (Modelo-Vista-Whatever).

Las tres partes del patrón de diseño de software MVC se pueden describir de la siguiente manera:
El patrón Modelo-Vista-Controlador (MVC), es uno de los primeros que se debería aprender. Es tan fundamental que ha sobrevivido décadas en la industria y sus ideas se han esparcido por muchas plataformas. Es el padre de muchos otros patrones derivados como MVVM (Modelo-Vista-VistaModelo), entre otros.

* Modelo: Maneja datos y lógica de negocios.
* Vista: Se encarga del disseño y presentación.
* Controlador: Enruta comandos a los modelos y vistas.
image::mvc1.png[MVC]

Este patrón es esencial debido a que ayuda a responder una de las preguntas más comunes: _¿Dónde debería poner esta pieza de código?_.

El patrón _MVC_ es uno de arquitectura. Entrega un mapa de la estructura de la aplicación y como su nombre dice, consiste en tres capas: modelo, vista y controlador.

El siguiente diagrama de Apple muestra un poco la relación de las vistas y controladores.

image:applemvc.png[Apple MVC]

- https://developer.apple.com/library/archive/featuredarticles/ViewControllerPGforiPhoneOS/index.html

El principal problema de MVC y por qué razón nacieron otros patrones derivados es debido a la tendencia de que los controladores crecían de forma exponencial. Incluso llegando a ser llamado Massive View Controllers, por la cantidad de responsabilidades que tenían que cumplir.

==== Modelo

El modelo define qué datos debe contener la aplicación. Si el estado de estos datos cambia, el modelo generalmente notificará a la vista (para que la pantalla pueda cambiar según sea necesario) y, a veces, el controlador (si se necesita una lógica diferente para controlar la vista actualizada).
La capa modelo (_model_), es la capa que maneja los datos y la lógica de negocios, independiente de su representación visual. Define qué datos debe contener la aplicación. Si el estado de estos datos cambia, el modelo generalmente notificará a la vista (para que la pantalla pueda cambiar según sea necesario) y, a veces, el controlador (si se necesita una lógica diferente para controlar la vista actualizada).

Volviendo a nuestra aplicación de lista de compras, el modelo especificará qué datos deben contener los artículos de la lista (artículo, precio, etc.) y qué artículos de la lista ya están presentes.

==== Vista

La vista define cómo se deben mostrar los datos de la aplicación.

En nuestra aplicación de lista de compras, la vista definiría cómo se presenta la lista al usuario y recibiría los datos para mostrar desde el modelo.
La capa vista (_view_) es la que muestra la información al usuario y permite interacciones, independiente de la capa de datos. La vista define cómo se deben mostrar los datos de la aplicación. En nuestra aplicación de lista de compras, la vista definiría cómo se presenta la lista al usuario y recibiría los datos para mostrar desde el modelo.

==== Controlador

El controlador contiene una lógica que actualiza el modelo y/o vista en respuesta a las entradas de los usuarios de la aplicación.
La capa controlador (_controller_) es la que actúa como puente entre modelo y vista. Almacena y manipula el estado de la aplicación y proporciona datos a las vista, interpreta las acciones del usuario según las reglas de negocio. El controlador contiene una lógica que actualiza el modelo y/o vista en respuesta a las entradas de los usuarios de la aplicación.

Entonces, por ejemplo, nuestra lista de compras podría tener formularios de entrada y botones que nos permitan agregar o eliminar artículos. Estas acciones requieren que se actualice el modelo, por lo que la entrada se envía al controlador, que luego manipula el modelo según corresponda, que luego envía datos actualizados a la vista.

Sin embargo, es posible que también se desee actualizar la vista para mostrar los datos en un formato diferente, por ejemplo, cambiar el orden de los artículos de menor a mayor precio o en orden alfabético. En este caso, el controlador podría manejar esto directamente sin necesidad de actualizar el modelo.

image::mvc.png[MVC]

=== Patrón Modelo Vista Vista-Modelo

El patrón Modelo-Vista-VistaModelo (_MVVM_), es un patrón de arquitectura que facilita estructurar la aplicación dividiéndola en tres roles.

image::mvvm.png[MVVM]

- El modelo (_model_): representa los datos y lógica de negocio de la aplicación.
- La vista (_view_): Muestra la información al usuario y permite la interacción.
- La vista-modelo (_view-model_): Actúa como puente entre las capas de vista y modelo. Contiene el estado de la vista y maneja la lógica de interacciones.

==== ¿Diferencias entre MVC y MVVM?

Al comparar los patrones de _MVC_ y _MVVM_ es notable la similitud y son casi idénticos.

La principal diferencia radica en que _MVC_ hace énfasis en los controladores. Encargados de manejar las interacciones para varias vistas. En cambio en _MVVM_ la vista-modelo es un único componente que controla el comportamiento y estado de una única vista. Comúnmente representado como un componente.

Otra diferencia es la forma de comunicación entre la vista y su controlador. En _MVC_ la vista y el controlador tienen funciones definidas que son llamadas de forma imperativa para informar sobre una acción o requerir actualizar la información en la vista. Por otra parte en _MVVM_ la vista y la vista-modelo están unidas por un mecanismo de enlazado (binding) que automáticamente informa sobre interacciones realizadas en la vista y cambios ocurridos en la vista-modelo. Estos mecanismos de enlazado varían según la plataforma.

Las capas de _MVC_ interactúan y son interpretadas dependiendo de algunos factores como:

- La plataforma donde se implementa.
- La experiencia del profesional y su interpretación del patrón.
- La moda del día (Los devs igual pueden seguir modas).

El patrón Modelo-Vista-VistaModelo (_MVVM_) es principalmente una versión de _MVC_ bajo un nombre diferente.

Si bien hay ligeras diferencias, perfectamente se pueden utilizar los conceptos de _MVC_ y _MVVM_ de forma unificada sin problemas.

=== La Importancia de MVC y MVVM

El utilizar un patrón de arquitectura como _MVVM_ con roles claramente definidos nos ayudan cumplir principios de diseño como la separación de conceptos. Lo que es una piedra angular para mantener código bien organizado, fácilmente entendible y que sus pruebas unitarias son viables de implementar.

Utilizar patrones de arquitectura como _MVVM_ es sumamente importante. A pesar de que los frameworks otorgen herramientas innovadoras para elaborar aplicaciones, si no utilizamos patrones de arquitectura el código se irá acumulando, aumentando de complejidad, para finalmente crear monolitos masivos que son difíciles de mantener y probar.

El hecho de que algunos frameworks manejen automáticamente la actualización de las vistas no justifica abandonar las buenas prácticas en el desarrollo de software que han existido por décadas en múltiples plataformas.

=== Más allá de MVC

Los patrones de arquitectura como _MVC_ y _MVVM_ tienen su foco en aplicaciones donde principalmente tenemos interacciones de usuario (UX), pero muchas veces las aplicaciones deben comunicar con servicios externos y otros elementos que necesitan otras formas de gestionar la arquitectura de código.

Para esto se recomienda utilizar patrones como los definidos en el Diseño Orientado a Dominio (Domain Driven Design) y arquitectura Hexagonal.

=== Lectura Complementaria

* https://developer.mozilla.org/es/docs/Glossary/MVC
* https://es.wikipedia.org/wiki/Modelo%E2%80%93vista%E2%80%93controlador
* https://matteomanferdini.com/mvvm-swiftui/
* https://en.wikipedia.org/wiki/Separation_of_concerns
* https://en.wikipedia.org/wiki/Coupling_(computer_programming)
* https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)
* https://en.wikipedia.org/wiki/Domain-driven_design
40 changes: 40 additions & 0 deletions book/chapters/systemd/chapter.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,44 @@ problemas de diseño de software con más confianza y aplicar principios de dise

El diseño de sistemas es un tema enorme. Cada uno tiene un enfoque diferente ya que no existen pautas paso a paso.

=== Estimación de Costos

Una estimación es un ejercicio de calcular los costos y requerimientos de un sistema de forma que se pueda tener una idea y referencia sobre el funcionamiento y costos futuros del mismo.

Estimar nos permite validar si la solución está dentro de los parámetros aceptables y analizar su factibilidad técnica y económica. La estimación es suficiente con que sea cercana al valor real, debido a que muchas variables pueden afectar los costos en el futuro.

Para poder estimar se necesitan algunas nociones y métricas básicas que pueden ser aplicadas a cualquier sistema.

==== Unidad de Volumen de Datos

El almacenamiento y transferencia de datos comunmente se mide en _Bytes_ y potencias de 2, debido a que un caracter _ASCII_ es 1 byte (8 bits).

La siguiente tabla muestra la unidad de volumen de datos.

|===
| Potencia | Valor Aproximado | Nombre | Abreviación
| 1 | 1 Uno (bit) | Bit | b
| 8 | 8 Ocho (bits) | Byte | B
| 10 | 1 Mil (bits)| Kilobyte | 1 KB
| 20 | 1 Millón (bits)| Megabyte | 1 MB
| 30 | 1 Mil Millón (bits)| Gigabyte | 1 GB
| 40 | 1 Billón (bits)| Terabyte | 1 TB
| 50 | 1 Cuatrillón (bits)| Petabyte | 1 PB
|===

==== Números de Latencia

La latencia nos indica cuánto se demora un proceso desde que se hace la petición hasta recibir una respuesta. A mayor cantidad de latencia, mayor será el tiempo que necesitemos esperar para obtener una respuesta. El tiempo de retraso de las latencias puede crear ineficiencias, especialmente en las operaciones en tiempo real.

Los siguientes gráficos contienen números aproximados, ya que según el avance tecnológico pueden variar con los años.

Basado en los números de Jeff Dean y Peter Norvig (http://norvig.com/21-days.html#answers).


image::latenciagrafico.png[Latencia Gráfico]

image::latencia.jpg[Latencia]

=== Escalado horizontal y vertical

La escalabilidad se refiere a la capacidad de una aplicación para manejar y soportar una mayor carga de trabajo sin sacrificar la latencia. Una aplicación necesita una potencia informática sólida para escalar bien. Los servidores deben ser lo suficientemente potentes para manejar mayores cargas de tráfico. Hay dos formas principales de escalar una aplicación: horizontalmente y verticalmente.
Expand Down Expand Up @@ -83,3 +121,5 @@ image::cache.png[]
* https://www.educative.io/courses/web-application-software-architecture-101
* https://www.geeksforgeeks.org/database-sharding-a-system-design-concept/
* https://www.educative.io/path/scalability-system-design
* https://aws.amazon.com/es/what-is/latency/
* Libro System Design Interview <<systemdesign>>.
Binary file added book/images/patterns/applemvc.avif
Binary file not shown.
Binary file added book/images/patterns/applemvc.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added book/images/patterns/mvc1.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added book/images/patterns/mvvm.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added book/images/systemd/latencia.jpg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added book/images/systemd/latenciagrafico.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading

0 comments on commit 2d5c3dd

Please sign in to comment.