boilerplate code
This commit is contained in:
@@ -33,4 +33,27 @@ lo cual significa que se está suscribiendo al canal `hello`. Y en otra escribir
|
||||
`nats pub "hello" "Hola mundo!"`, lo cual significa que está escribiendo el
|
||||
mensaje `Hola mundo!` en el canal `hello`.
|
||||
|
||||

|
||||

|
||||
|
||||
### Creación de la aplicación
|
||||
|
||||
La parte fácil es hacer todo el _boilerplate_, hecho en solo _commit_, que no es
|
||||
lo ideal pero lo dicho, es puro relleno, mucho código ya viene escrito de la
|
||||
librería `gopher-toolbox`. En este punto el proyecto compila pero hay error en
|
||||
tiempo de ejecución por la falta de implementaciones en el repositorio.
|
||||
|
||||
### Empezando por el repositorio
|
||||
|
||||
El almacenamiento de los datos se ha optado por el uso de `TimescaleDB`, una
|
||||
extensión de `PostgreSQL`, el motivo es porque ya he trabajado mucho con ese
|
||||
motor y tengo los _drivers_ ya escritos. Tengo entendido que está optimizado
|
||||
para trabajar con grandes cantidades de datos de series temporales, lo que viene
|
||||
siendo valores de sensores por ejemplo.
|
||||
|
||||
Por otro lado también hay un sistema de caché muy rudimentario, en memoria que
|
||||
es un mapa de valores.
|
||||
|
||||
Para el registro de valores y mantener ambos se ha usado el patrón decorador que
|
||||
bajo un mismo _struct_ se incluye las dos implementaciones y se llama a ambas
|
||||
funciones. Desde la capa servicios sólo tiene que llamar al decorador sin saber
|
||||
los detalles de la implementación.
|
||||
|
||||
Reference in New Issue
Block a user