DEV Community: Jesus Gonzalez

Create OHLC Candles with Python (Pandas + Plotly)

Jesus Gonzalez — Fri, 10 Oct 2025 15:35:48 +0000

Many market datasets come as raw trade ticks (timestamp, price, size). To analyze trends we first convert ticks into OHLC candles. This tiny Python script builds 1‑minute candles with Pandas and plots them with Plotly.

How it works

Generate trade ticks at 1‑second resolution
Resample to a 1‑minute interval and compute open, high, low, close, and volume
Plot a candlestick chart

Open in Colab (public): paste the code below into https://colab.new and run.

import numpy as np, pandas as pd, plotly.graph_objects as go

FREQ, MINS = '1min', 10  # interval and number of candles
start = pd.Timestamp('2025-01-01 10:00:00', tz='UTC')
idx = pd.date_range(start, periods=MINS*60, freq='s', tz='UTC')

rng = np.random.default_rng(42)
price = 100 + rng.normal(0, 0.03, len(idx)).cumsum()
qty   = np.maximum(1, np.rint(rng.normal(2.0, 0.8, len(idx))))
df = pd.DataFrame({'price': price, 'qty': qty}, index=idx)

candles = pd.DataFrame({
    'open':  df['price'].resample(FREQ).first(),
    'high':  df['price'].resample(FREQ).max(),
    'low':   df['price'].resample(FREQ).min(),
    'close': df['price'].resample(FREQ).last(),
    'vol':   df['qty'].resample(FREQ).sum(),
}).dropna()

fig = go.Figure(go.Candlestick(
    x=candles.index, open=candles['open'], high=candles['high'],
    low=candles['low'], close=candles['close']))
fig.update_layout(template='plotly_dark', height=420,
                  title=f'{MINS}m Candles ({FREQ})')
fig.show()

Exploring Random Number Generation with Different Distributions in Python

Jesus Gonzalez — Sat, 28 Oct 2023 07:44:18 +0000

Generating random numbers with different distributions is a fascinating topic that has applications in many areas, from computer simulations to machine learning.

What are distributions?
In statistics, a distribution describes the likelihood of an event occurring. In the context of random numbers, a distribution describes how likely each number is to be selected.

For this article i generated random numbers with 3 different distributions: Uniform, Normal and Exponential.

Uniform Distribution
The uniform distribution is the simplest of all distributions. In a uniform distribution, all numbers within a specific range have the same likelihood of being selected. It is useful when you want all possible outcomes to be equally likely.

np.random.uniform(low=1, high=1000, size=10000)

In real life, the uniform distribution is often used in computer simulations (e.g. Monte Carlo method) and games where you want all outcomes to be equally likely.

Normal Distribution
Also known as the Gaussian distribution, is probably the most well-known of all distributions. In a normal distribution, numbers near the middle of the range have a higher likelihood of being selected, while numbers at the ends of the range have a lower likelihood.

random.normal(loc=500, scale=100, size=10000)

In real life, the normal distribution is used in a wide variety of fields including statistics, physics and engineering. It’s useful when you’re working with data that clusters around an average.

Exponential Distribution
The exponential distribution is a bit different. In an exponential distribution, smaller numbers have a higher likelihood of being selected and this likelihood decreases exponentially as the numbers increase.

random.exponential(scale=100, size=10000)

In real life, the exponential distribution is often used in queueing theory and in modeling the lifetime of certain products and materials.

This graphs represent the results and allow see which numbers are more likehood to be selected in the different distributions:

The Uniform Distribution shows an almost constant bar across the full range (0-1000), indicating that each number within this range has roughly equal probability of being selected.

The Normal Distribution shows a “bell curve”, indicating that numbers near the middle of the range (around 500) have a higher probability of being selected while numbers at the ends of the range have a lower probability..

The Exponential Distribution shows a rapidly decreasing curve, indicating that smaller numbers have a higher probability of being selected and this probability decreases exponentially as the numbers increase.

Full Code

import numpy as np
import matplotlib.pyplot as plt

# Define the number of samples and the range of the random numbers
num_samples = 10000
low, high = 1, 1000

# Generate random numbers with different distributions
uniform_dist = np.random.uniform(low=low, high=high, size=num_samples)
normal_dist = np.random.normal(loc=high/2, scale=(high-low)/10, size=num_samples)
exponential_dist = np.random.exponential(scale=(high-low)/10, size=num_samples) 

plt_uniform_dist = np.clip(uniform_dist, low, high)
plt_normal_dist = np.clip(normal_dist, low, high)
plt_exponential_dist = np.clip(exponential_dist, low, high)

plt.figure(figsize=(15, 5))

plt.subplot(1, 3, 1)
plt.hist(plt_uniform_dist, bins=50, color='c')
plt.title('Uniform Distribution')

plt.subplot(1, 3, 2)
plt.hist(plt_normal_dist, bins=50, color='m')
plt.title('Normal Distribution')

plt.subplot(1, 3, 3)
plt.hist(plt_exponential_dist, bins=50, color='y')
plt.title('Exponential Distribution')

plt.tight_layout()
plt.show()

Reverse the elements of a Singly Linked List using a Stack

Jesus Gonzalez — Mon, 01 Nov 2021 15:49:38 +0000

Reverse the elements of a Singly Linked List using a Stack as an approach

It is not the most efficient way to solve this problem but it is good to know other ways to solve it by helping us with other data structures

https://play.golang.org/p/Obbq73zUrD2

The Go Playground - standard input

Jesus Gonzalez — Tue, 18 May 2021 11:15:42 +0000

📌 When you use The Go Playground, you cannot make interactive programs like this one because it does not allow the input of values by standard input interactively:
https://play.golang.org/p/lvkXx7aB-XV

the program will terminate and will not allow you to enter any value.

📌 Go playground can write on standard output and standard error. Anyway can still receive a value from standard input not interactively.
https://play.golang.org/p/r-uvWSb8UiV

📌 it operates on an in-memory file system, which will allow assigning a value that stores it in memory as standard input. https://github.com/orbs-network/go-nacl-experiment

📝 Playground documentation: Inside the Go Playground https://blog.golang.org/playground

Line filter program that removes digits

Jesus Gonzalez — Fri, 14 May 2021 15:13:53 +0000

📌 A filter is a program that gets data from standard input, performs some manipulation of the data, and then writes its results to standard output.
Auxiliary input may come from command line flags or configuration files, while auxiliary output may go to standard error.

📌 Most common functions:

▶️ Convert data to a different format
▶️ Add printer instructions to the beginning of each document
▶️ Add, delete, or modify data in a document

📌 Unix has many filter programs, most common are: cat, cut, grep,

Go Playground: https://play.golang.org/p/s8FwQRkZXdr

Enviar correos por GMAIL utilizando el paquete SMTP de GO

Jesus Gonzalez — Mon, 29 Jun 2020 23:56:56 +0000

El paquete implementa SMTP (Simple Mail Transfer Protocol), el cual es un protocolo de comunicación para transmisión
de correos electrónicos. En su documentación se encuentra un ejemplo, que se adaptará a un formato listo para producción, aplicando testing unitarios, integración que comprobarán los componentes en conjunto y de cobertura.

Lo primero es crearse un directorio, con 2 archivos de extensión .go, uno para el código normal de GO, otro para los testings. Debería quedar como la imagen:

El nombre del archivo de testing debe cumplir el patrón especifico exigido por el lenguaje, de esta manera se ejecutaran solamente aquellos dedicados a esa función, el cual es el siguiente: tunombrepreferido_test.go .

Se empezará el desarrollo con un primer test a lo mas resaltante del articulo: Enviar Correos Electrónicos .

    package email

    import (
            "fmt"
            "net/smtp"
            "reflect"
            "strings"
            "testing"
    )

    func TestSendEmail(t *testing.T) {
            assertThat := func(assumption, addr string, auth smtp.Auth, from string, to []string, msg []byte, expectedOutput string) {
                    actualOutput := sendEmail(addr, auth, from, to, msg)
                    if actualOutput != expectedOutput {
                            t.Errorf("Error! Outputs are not equal Actual %v Expected %v", actualOutput, expectedOutput)
                    }
            }
            addr := "smtp.gmail.com:587"

            auth := smtp.PlainAuth("", "your-email@gmail.com", "your-password", "smtp.gmail.com")

            from := "your-email@gmail.com"

            to := []string{"to-email-1@gmail.com", "to-email-2@hotmail.com"}
            concatenate := strings.Join(to, ", ")
            toMsg := fmt.Sprintf("To: %v\r\n", concatenate)

            subject := "Test Subject"
            subjectMsg := fmt.Sprintf("Subject: %v\r\n", subject)

            body := "Example body."
            bodyMsg := fmt.Sprintf("%v\r\n", body)

            msg := []byte(toMsg + subjectMsg + "\r\n" + bodyMsg)
            assertThat("Should send email from user's GMAIL account to any email and return a message of successful sent", addr, auth, from, to, msg, "email sent successfully")
    }

Las funciones de igual manera se rigen por un respectivo patrón TestXxx( t *testing.T) donde Xxx es el nombre de cada una.

El testing de arriba se aprobará si el correo fue enviado y retorna el mensaje de exito esperado, si devuelve un mensaje diferente indicara que ocurrio un error y no se aprobó, la funcion a evaluar es sendEmail(), que contendra la misión de enviar los correos electrónicos y se agregara en el archivo email.go::

    func sendEmail(addr string, auth smtp.Auth, from string, to []string, message []byte) string {
            err := smtp.SendMail(addr, auth, from, to, message)
            if err != nil {
                    log.Printf("Error!: %s", err)
                    return "Error! sending mail"
            }
            return "email sent successfully"
    }

Necesita de unos parámetros para realizar el objetivo, como se le esta evaluando a ella solamente se aplicara la tecnica test double, se inicializaran objetos falsos simulando a valores reales para poder correr el testing con el comando:

    $ go test

Existen muchas probabilidades que falle al primer intento, debido a que no se ha configurado la cuenta a utilizar de GMAIL. Se necesitara modificar los siguientes aspectos:

Desactivar el mecanismo de seguridad de autentificacion 2-step.
Activar la opcion de permitir acceso a aplicaciones menos seguras, se esta trabajando localmente, y no se tiene el certificado TLS, GMAIL rechazará la conexion si no se realiza este paso.

Si ya se hicieron los cambios, los posibles errores pueden ser que las credenciales esten erroneas (el correo o la contraseña).

Se ejecuta nuevamente y deberia indicar que la prueba fue aprobada y el correo en la bandeja de entrada a quien fue dirigido.
Recuerda que GMAIL tiene un limite diario para el envio de correos, si se sobrepasa no se podria enviar mas o entrarian en la bandeja de SPAM(Limites).

A continuacion crearan tests a los objectos falsos. Los primeros evaluaran a las funciones que obtendran la address y el email desde donde se enviaran los correos, se creara un archivo .env para almacenar variables importantes o sensibles, se podra acceder a el con la libreria godotenv.

    func TestGetAddressSMTP(t *testing.T) {
            assertThat := func(assumption, expectedAddress string) {
                    actualAddress := getAddressSMTP()
                    if actualAddress != expectedAddress {
                            t.Errorf("Error! Outputs are not equal Actual %v Expected %v", actualAddress, expectedAddress)
                    }
            }
            assertThat("Should get from a environment variable the smtp address", "smtp.gmail.com:587")
    }

    func TestGetEmailFrom(t *testing.T) {
            assertThat := func(assumption, expectedEmail string) {
                    actualEmail := getEmailFrom()
                    if actualEmail != expectedEmail {
                            t.Errorf("Error! Outputs are not equal Actual %v Expected %v", actualEmail, expectedEmail)
                    }
            }
            assertThat("Should return the email from where the messages will be sent.", "your-email@gmail.com")
    }

Las funciones en el email.go

    func getAddressSMTP() string {
            return os.Getenv("address")
    }

    func getEmailFrom() string {
            return os.Getenv("username")
    }

Y variables en .env

    address=smtp.gmail.com:587
    username=your-email@gmail.com

Se ejecutara el comando nuevamente:

    $ go test

Los nuevos test deberian ser aprobados porque los valores esperados son iguales a los obtenidos.

Ahora se evaluara la funcion encargada de la autentificacion de las credenciales de la cuenta a utilizar:

    func TestPlainAuth(t *testing.T) {
            assertThat := func(assumption string, expectedAuth smtp.Auth) {
                    actualAuth := plainAuth()
                    if !reflect.DeepEqual(actualAuth, expectedAuth) {
                            t.Errorf("Error! Outputs are not equal Actual %v Expected %v", actualAuth, expectedAuth)
                    }
            }
            expectedAuth := smtp.PlainAuth("", "your-email@gmail.com", "your-password", "smtp.gmail.com")
            assertThat("Should returns an Auth that implements the PLAIN authentication mechanism", expectedAuth)
    }

El paquete de SMTP contiene 2 metodos de autenficacion el utilizado en este articulo PlainAuth y CRAMMD5Auth, el ultimo es un poco mas seguro porque implementa un mecanismo de seguridad pero lamentablemente no es soportado por GMAIL.

En el archivo email.go

    func plainAuth() smtp.Auth {
            return smtp.PlainAuth(os.Getenv("identity"), os.Getenv("username"), os.Getenv("password"), os.Getenv("host"))
    }

Utiliza mas variables almacenadas en .env, aqui sobresale lo importante que es tener datos tan sensibles como la contraseña del correo en un archivo que no debe subirse al repositorio y como una constante en el código directamente.

    address=smtp.gmail.com:587
    identity=""
    username=your-email@gmail.com
    password=your-password
    host=smtp.gmail.com

Se vuelve a ejecutar el comando para asegurarse que la funcion retorna un objeto Auth como el esperado.

    $ go test

De los ultimos objetos falsos que se crearon fue el de msg, el cual contiene los correos a quienes va dirigido, el tema y el cuerpo del mensaje.

    func TestGenerateMessage(t *testing.T) {
            assertThat := func(assumption string, emailList []string, subject string, body string, expectedMsg []byte) {
                    actualMsg := joinMessageStructure(emailList, subject, body)
                    if !reflect.DeepEqual(actualMsg, expectedMsg) {
                            t.Errorf("Error! Outputs are not equal Actual %v Expected %v", actualMsg, expectedMsg)
                    }
            }
            to := []string{"to-email-1@gmail.com", "to-email-2@hotmail.com"}
            concatenate := strings.Join(to, ", ")
            toMsg := fmt.Sprintf("To: %v\r\n", concatenate)

            subject := "Test Subject"
            subjectMsg := fmt.Sprintf("Subject: %v\r\n", subject)

            body := "Example body."
            bodyMsg := fmt.Sprintf("%v\r\n", body)

            expectedMsg := []byte(toMsg + subjectMsg + "\r\n" + bodyMsg)
            assertThat("Should receive the emails, subject, body and should return an array of bytes being the message", to, subject, body, expectedMsg)
    }

En el archivo email.go la funcion a evaluar unira todos los datos, retornando un array de bytes que representa la estructura.

    func joinMessageStructure(emailList []string, subject string, body string) []byte {
            concatenate := strings.Join(emailList, ", ")
            toMsg := fmt.Sprintf("To: %v\r\n", concatenate)

            subjectMsg := fmt.Sprintf("Subject: %v\r\n", subject)

            bodyMsg := fmt.Sprintf("%v\r\n", body)

            return []byte(toMsg + subjectMsg + "\r\n" + bodyMsg)
    }

Se ejecuta:

    $ go test

Ahora se evaluaran a los componentes en conjunto con un test de integracion:

    func TestIntegrationSMTP(t *testing.T) {
            assertThat := func(assumption string, emailList []string, subject string, body string, expectedOutput string) {
                    address := getAddressSMTP()
                    auth := plainAuth()
                    emailFrom := getEmailFrom()
                    msg := joinMessageStructure(emailList, subject, body)
                    actualOutput := sendEmail(address, auth, emailFrom, emailList, msg)
                    if actualOutput != expectedOutput {
                            t.Errorf("Error! Outputs are not equal Actual %v Expected %v", actualOutput, expectedOutput)
                    }
            }
            to := []string{"to-email-1@gmail.com", "to-email-2@hotmail.com"}
            subject := "Test Subject"
            body := "Example body."
            assertThat("Should get data from different units and send email", to, subject, body, "email sent successfully")
    }

Todavia se necesita de objetos que son falsos, pero ellos en un caso real pueden ser obtenidos por funciones encargadas de capturar esos datos dependiendo de la aplicacion que se esta desarrolando Ejemplo: pueden venir de una peticion que le hicieron a una API o por input de una aplicacion CLI, etc. El proposito es que el correo sea enviado y retorne el mensaje esperado para aprobar el test.

Por ultimo se hara un test coverage (cobertura de pruebas). Nos indicara el porcentaje que se cubren en el código con los tests. Se realiza con el comando:

    $ go test -cover

Arrojara un resultado de:

No se cubre el 100% del código, se esta cubriendo un 81.2%. El anterior comando no nos indica cuales son las partes que no se cubren, en cambio los siguientes generaran un archivo HTML con el código evaluado y coloreado:

    $ go test -coverprofile=coverage.out
    $ go tool cover -func=coverage.out
    $ go tool cover -html=coverage.out

Las partes en rojo, son zonas que no estan siendo evaluadas por los testing, existe un debate donde hay un grupo que sostienen que se deben cubrir el 100% del código y el otro donde solo se deben cubrir los casos necesarios, En el código del articulo los casos que faltan por cubrir son los casos se generan errores en las funciones, no son necesarios porque ya tienen su mecanismo de devolver un mensaje de error en caso que haya ocurrido algo diferente a su proposito.

El código final esta mejor preparado para ir a produccion, porque cada funcion tiene una sola responsabilidad, se instauro un archivo especial para las variables sensibles por seguridad y fue testeada cada funcion, asi que ya se conoce como sera su comportamiento.

Si tienen una sugerencia o encuentran un error en el código por favor hagamelo saber.

Espero que les haya gustado.

NOTA : Debes reemplazar la configuracion con su correo, contraseña en los distintos archivos para que funcione correctamente.

Link del repositorio del archivo con Go Modules para el manejo de dependencias 👇

https://github.com/gonzalezlrjesus/email-smtp

Archivo final email.go:

Archivo de testings email_test.go:

Archivo de variables .env

Como subir una API desarrollada con el lenguaje GO a Heroku

Jesus Gonzalez — Mon, 23 Mar 2020 16:15:33 +0000

Cuando se está en el proceso de desarrollo de una API, se realizan pruebas internas para verificar el funcionamiento de los distintos componentes de la misma. Luego que la fase de pruebas haya concluido se debe subir a un servidor, desde donde los usuarios para la cual fue desarrollada puedan consumir sus servicios. Existen muchas empresas las cuales ofrecen alojar la API, pero cada una ofrece diferentes paquetes de funcionabilidades, dependiendo de los requerimientos se decidirá cual empresa se adapta mejor. En este tutorial se indicaran los pasos necesarios para subir la API a Heroku.

La API constara de una única función, debido a que el objetivo de este tutorial es indicar como debe configurarse un proyecto localmente para que esté en condiciones de ser aceptado por el servicio heroku.

Para el proyecto se utilizó el lenguaje GO versión: go1.13.7

La función ListenAndServe inicia un servidor HTTP con la dirección :8000 cuando se trabaja localmente se utiliza el puerto 8000, pero cuando ya se encuentre alojada en el servicio el puerto lo decidirá Heroku por ende tiene esa validación, un único endpoint de acceso /hello por el cual se pueden hacer peticiones el cual devolverá el mensaje: “Hello, World!”.

A pesar de que el proyecto no posee ninguna dependencia como: Gorilla, bcrypt , entre otras. Lo normal es que los servicios web tengan dependencias para propósitos específicos. Para su manejo es necesario instalar una herramienta que las administrara, algunas de ellas son Godep, Dep y Go Modules.

El manejador seleccionado a utilizar es Godep. Para su instalación se debe cumplir los siguientes pasos:

Dentro de la carpeta del proyecto se deberá abrir la consola y ejecutar el siguiente comando:
go get -u github.com/tools/godep

El cual lo descargara e instalara, para validar su instalación se ejecuta: godep version
Debería mostrar la versión que se instaló.

De lo contrario mostrara un error como el siguiente:

Para corregir ese error se necesita agregar la dirección de la carpeta donde se almacenan los archive BIN a la variable PATH de Windows.

Ahora se ejecutara Godep que organizara las dependencias.
godep save ./...

De no mostrar ningún mensaje de error, se generaran dos carpetas: Godeps y Vendor, la API no cuenta con dependencias por lo cual no se generara la carpeta Vendor. En el caso de la carpeta Godeps se creara un archivo JSON automáticamente donde se almacenara la lista de las dependencias que se utilizan en la aplicación.

Las nuevas carpetas deben ser almacenadas en un repositorio GIT. Se iniciara con el comando : git init

Se debe hacer commit a los cambios, primero el comando git add . , luego git commit –m “Agregando dependencias”

Lo siguiente es crearse una cuenta en heroku a través de este link: Registrarse

Y luego descargar e instalar el CLI con el cual se podrá subir el código a la recién creada cuenta de Heroku: Descargar CLI.
Para verificar que la instalación del CLI fue exitosa se ingresa el comando: heroku –versión se deberá mostrar la versión de heroku instalada en la computadora.

Para continuar con el proceso se debe iniciar sesión sincronizando el proyecto con la cuenta. La sincronización se hace con el comando heroku login el cual abrirá una ventana en un navegador para que se inicie sesión en la cuenta de heroku.

Si desea conocer si la autenticación fue exitosa se ejecuta el comando
heroku auth:token le deberá mostrar el token asignado.

Para este siguiente paso se debe crear una aplicación en Heroku la cual será la que recibirá el código y se generara automáticamente un repositorio GIT específico para la nueva aplicación en heroku. heroku create [nombre-app]

Se puede observar la recién creada aplicación en el panel de la cuenta de heroku.

Y el nuevo repositorio GIT con git remote –v

Ahora para finalizar se debe enviar el código a la aplicación en heroku:
git push heroku master

Si todo fue enviado correctamente a partir desde este momento los usuarios pueden hacer uso de la API.

Nota: Ese mismo comando se debe ejecutar cada vez que se realice un cambio en el código localmente y se desee enviar a la aplicación en heroku.

Si desea conocer cuántas versiones tiene la aplicación en heroku, se puede observar con heroku releases y para conocer con más detalle a una específica versión se utiliza heroku releases:info [versión-release]

Heroku implementa una medida de protección de sus servicios, limita la cantidad de envíos de código a la aplicación que se encuentra en sus servicios de un número de 75 peticiones por usuario, por aplicación y por hora. Si desea conocer más acerca de una implementación de la medida en el lenguaje GO lo puede leer aquí:
Como limitar las peticiones a una api.

Si usted tiene alguna pregunta, sugerencia o corrección, ¡estaría encantado conocerla!

Como limitar las peticiones a una API

Jesus Gonzalez — Mon, 09 Mar 2020 18:13:48 +0000

Cuando se desarrolla una API es importante que en todo momento esté disponible para ser utilizada por los usuarios, pero la verdad es que cuando una API sale a producción siempre aparecen factores que alteran su estabilidad.

Uno de esos factores son los ataques DDoS, los cuales muchas veces son producidos por errores en aplicaciones que utilizan los servicios ofrecidos por la API o usuarios particulares, que realizan demasiadas solicitudes de información sobrecargando los recursos de los servidores (CPU, Discos Duros, Memoria).

Para estos casos es necesario agregarle algunas medidas de defensa a la API.
Una medida es aplicarle un limitante a las peticiones, el cual permite un número determinado de solicitudes que puedan realizar los usuarios a la API durante un rango específico de tiempo.

Esta limitante puede ser aplicada en varias formas a las solicitudes, dependiendo de lo que se desea lograr.

Usuario: Limitar la cantidad de solicitudes por token asignados a usuarios o por IP de dispositivos.
Geográficamente: Limitar solicitudes que provengan de regiones (países, estados, etc.) en particular.
Horario: Algunos servicios ofrecidos por la API solo pueden utilizarse por los usuarios en un horario específico.
Servidor: Disminuir las solicitudes de un servidor para otro servidor.

Existen varios algoritmos utilizados para implementar una limitante:

Token Bucket
Leaky Bucket
Sliding Window

Para la implementación utilice la librería Tollbooth la cual usa el algoritmo Leaky Bucket para limitar las solicitudes.

Desarrolle un unico endpoint de una API devolverá un array de Usuarios en formato JSON. Ya teniendo la API funcional y testeada podemos pasar a la parte de integrar el limitante que permitirá como máximo 1 petición por segundo. Lo que quiere decir es que dentro de un tiempo de 1 segundo, solamente una petición podrá ser atendida por la API, las demás peticiones serán rechazadas y se devolverá una respuesta con el código HTTP 429 según la RFC 6585 lo define como “Too many Request” y un mensaje indicando el error que ocurrió.

Con el limitante podemos asegurar que la API nos entregara un flujo de datos sin sobrecargar el servidor y evitar costes adicionales por un aumento de consumo de recursos por proveedores de hosting que cobran por uso.
Para una mejor confiabilidad es recomendable también aplicar medidas de control en las aplicaciones del lado de los clientes.