DEV Community: David Jiménez

Diseñando el Sistema de Ingesta de Datos para la Baliza V-16 de la DGT

David Jiménez — Sun, 25 Jan 2026 17:31:48 +0000

La Dirección General de Tráfico (DGT) de España ha establecido como obligatorio el uso de la baliza V-16 en carretera a partir de este 2026. Más allá de toda la polémica en cuanto a la utilidad de la medida, este post tiene por objetivo proponer un sistema que dé soporte a estos dispositivos IoT.

⚠️ Nota: Este post es largo y 100% escrito a mano (0% IA). Si quieres saltar directamente a la arquitectura propuesta haz click aquí. Aunque te recomiendo leerlo entero ;)

Capítulo 0: Metodología

Este post va a seguir una metodología de varios pasos:

Entender el Problema y detectar limitaciones
Identificar a los Principales Actores
Definir Requisitos Funcionales
Definir Requisitos No Funcionales
Establecer una API de alto nivel (diagrama de flujo)
Diseñar para los Requisitos Funcionales
Ajustar para los Requisitos No Funcionales

Estos puntos no se corresponden uno a uno con los capítulos pero me parece importante dejar esta intro para que se entienda la metodología de diseño que voy a seguir.

Capítulo 1: Los primeros requisitos.

El equipo de la DGT 3.0 recibe un aviso: "A partir de 2026 tendrá que estar operativo el sistema para recibir eventos de la Baliza V-16. Todos los coches de España deberán disponer de una y hacer uso de ella en caso de emergencia en carretera."

La información, aunque no es demasiado extensa, ya deja entrever algunos retos técnicos. Aquí algunas de las primeras preguntas y datos clave:

¿Debemos conectar las balizas directamente a nuestro sistema?

Esto lo discutiremos más adelante y veremos qué se ha decidido finalmente. Spoiler: NO

¿A qué volumen de usuarios debemos dar soporte?

Haciendo una búsqueda rápida, según datos de 2023 en España había 23 millones de automóviles asegurados. Poniéndonos en la peor situación, imaginemos que todos circulan todos los días y que tenemos una tasa diaria de incidencias del 0,1%. Eso serían 23.000 vehículos enviando señales durante el día. Obviamente esto es una barbaridad, pero como primera aproximación nos podemos hacer a la idea de que el volumen de datos va a ser grande.

¿Cómo de importante es la información y cómo de crítico es el sistema?

La seguridad en carretera es algo primordial. Necesitamos un sistema robusto y con alta disponibilidad. Perder un evento puede marcar la diferencia entre tener un coche señalizado y no tenerlo.

¿De qué base tecnológica partimos?

Sinceramente, no he encontrado mucho. Este ejemplo parte de la premisa de que la DGT dispone de un cloud que nos permita desplegar microservicios. Como se trata del diseño del sistema, los detalles específicos sobre proveedores los dejaremos a un lado.

Capítulo 2: Empezando a Pensar el Sistema

¿Por qué no conectar las balizas a la DGT directamente? La respuesta es otra pregunta: Si la API fuese abierta, ¿cómo asegurarías que un actor malintencionado no intenta engañarte y llenar el mapa de señales?

Definitivamente esta opción es poco viable. Por eso la DGT ha habilitado la API de ingesta de datos solo para empresas verificadas previamente (y entiendo que serán además las que tengan balizas certificadas). De su propia documentación y especificación:

Por supuesto, esta decisión tiene un impacto en las características del sistema:

Hemos simplificado la gestión de ataques DDoS, tenemos un sistema más sencillo y seguro.
Pero hemos sacado de nuestro control una parte de la estabilidad del sistema. Si el cloud del proveedor de las balizas cae, no recibiremos eventos.

Siguiente tema: cómo identificar las incidencias.

Queremos saber qué incidencias tenemos en tiempo real y eso técnicamente implica saber qué balizas están activas. Una solución simple podría ser un sistema basado en 2 eventos: uno de encendido (start) y otro de apagado de la baliza (end)

Pero, ¿qué pasaría si alguno se pierde? Podría haber faltas de coherencia: eventos de final que llegan sin haber empezado, eventos de inicio que nunca terminan... En este caso una solución es añadir un tercer evento, de tipo "ping", que se repita en el tiempo y que nos permita solventar posibles errores en la red, pérdidas de mensajes o incluso fallos del hardware de la baliza.

Esta segunda solución nos permite establecer un Time-To-Live, un periodo de tiempo durante el cual asumimos que la baliza está activa, si pasado ese periodo la baliza no envía más mensajes, incluso sin haber enviado el evento de final, podemos asumir que la incidencia ha finalizado.

Un poco más de Matemáticas

La documentación de la DGT establece que el formato del evento debe ser el siguiente:

{
    "actionid": "1",
    "detection_time": "2020-02-24T07:17:27Z",
    "lon": -3.5 ,
    "lat": 40.5,
    "device_event_type": 1,
    "device_event_type_value": 1,
    "information_quality": 1
}

Esto son 189 Bytes.

La baliza debe tener batería suficiente para media hora. Suponiendo un mensaje "ping" cada 30 segundos esto nos deja con 60 mensajes totales por cada incidencia.

Nota del David del futuro: la especificación oficial establece este ping cada 100 segundos, pero tampoco es relevante.

Tamaño Incidencia = 189 B * 60 = 11340 B

No es mucho. Continuando con nuestra suposición de 23.000 incidencias diarias, el volumen total diario asciende a 260 MB diarios. Anualmente: 94GB.

No es una cifra astronómica, con la tecnología actual el almacenamiento no será un problema. Además, esto es el tamaño del mensaje JSON, en base de datos habrá menos duplicidades (las keys no se guardan, solo los valores).

Capítulo 3: Requisitos Funcionales

Ahora que tenemos una idea de cómo hacer que esto funcione, toca establecer qué es lo que el sistema tiene que hacer.

Tenemos identificados a nuestros dos principales usuarios:

Proveedores de Datos V-16
Consumidores de la plataforma DGT 3.0

El sistema:

debe permitir a los Proveedores de Datos V-16 iniciar sesión y recibir un token de acceso temporal.
debe permitir a los Proveedores de Datos V-16 enviar los eventos de las diferentes balizas e informarles de la recepción del mismo.
debe permitir a los Consumidores de la plataforma DGT 3.0 obtener los datos de incidencias en tiempo real y obtener actualizaciones sobre esos datos.
debe permitir a los Consumidores de la plataforma DGT 3.0 la consulta de datos históricos de incidencias.

Requisitos Excluidos del Proyecto

Para este ejemplo he dejado fuera el registro de las Entidades proveedoras de Datos V-16, dado que necesitan de una certificación manual y no es relevante para el problema real: el manejo de grandes volúmenes de mensajes en tiempo real.

También queda fuera la gestión de usuarios de la plataforma DGT 3.0 (registro y login), dado que es un sistema que ya existe. Simplemente aparecerá en nuestros esquemas pero no profundizaré en él.

Capítulo 4: Requisitos No Funcionales

Como ya hemos visto en el capítulo 2, necesitamos un sistema robusto y rápido, que refleje lo más fielmente posible la realidad de las carreteras.

Por eso:

Las confirmaciones de recepción de eventos deben realizarse en el menor tiempo posible. Objetivo: <500 ms.
Las incidencias deben aparecer en la plataforma en menos de 5 segundos desde que se iniciaron.
Disponibilidad del sistema: SLA 99,99% (menos de 1 hora de downtime anual)

Capítulo 5: Diseño del sistema para cumplir con los requisitos funcionales.

Antes de entrar al diagrama de arquitectura, no está de más pararse a plantear cómo serán las interacciones en el sistema. Para ello he preparado este diagrama de flujo:

Básicamente tenemos a nuestros dos tipos de clientes:

V-16 Data Providers
DGT 3.0 Data Consumers
Y a nosotros mismos (la DGT 3.0)

Junto a las acciones e interacciones con nuestro sistema. Vamos a ir construyendo poco a poco el sistema.

5.1 - El Login de Proveedores

Este es sencillo. Para el Login usaremos un servicio preexistente de Users y Auth.

De la documentación oficial de la DGT:

Como ves existe una especificación muy concreta, pero no entraré en ella para centrarme en el diseño del sistema.

5.2 - La Ingesta de Eventos

Para este segundo flujo vamos a disponer de un total de tres microservicios.

El servicio "Event Validator & Ingestor" validará el evento recibido y, en caso de ser correcto, lo enviará a una cola de mensajes para ser consumido por los otros dos servicios. Esta validación será rápida ya que solo incluye el formato y pequeñas comprobaciones: Dependiendo de si queremos devolver un error en caso de recibir alertas de un evento del que no hemos recibido su evento de inicio, podemos añadir una llamada interna a nuestro servicio de Device Presence.
El servicio de "Device Presence" se enfoca en los eventos activos. Hace uso de una base de datos key/value en memoria (por ejemplo Redis) muy rápida, perfecta para almacenar las incidencias activas y permitir su consulta con bajas latencias.
El servicio de "Incidents History" se enfoca en la visión histórica. En este caso he elegido una base de datos SQL para almacenar la información a largo plazo. La idea es permitir la consulta para datos estadísticos y de mejora de carreteras (por ejemplo detectando puntos calientes).

Además, al añadir el "Event Validator & Ingestor", he considerado conveniente añadir un API Gateway para exponer de manera unificada tanto este como el servicio de Usuarios. Esto además nos permitirá cumplir con los criterios de seguridad relativos a las IPs desde las que se accede a la plataforma.

El uso de la cola de mensajería en este caso está justificado por varios motivos:

Nos permite enviar el evento desde el "Event Ingestor" a dos microservicios diferentes.
Nos permite desacoplar los servicios y asegurar que no se pierda ningún evento incluso aunque alguno de los servicios de almacenamiento pueda llegar a caer o estar saturado.
También da cumplimiento a ciertos requisitos no funcionales (lo veremos más adelante).

De momento con esto habríamos cumplido con los requisitos del primer grupo de clientes, los proveedores de datos V-16.

5.3 - Información en tiempo Real para los usuarios de DGT 3.0

Para la conexión de nuestros usuarios utilizaremos el servicio de Usuarios y Auth, y crearemos un servicio en exclusiva para el tiempo real "Real Time Incidents Service". ¿Por qué uno nuevo y no el "Device Presence Service"? Para mantener a este stateless.

El servicio de Real Time va a mantener conexiones abiertas (Web-Sockets o Server Sent Events). Para evitar meter esta carga a nuestro servicio de almacenamiento, vamos a mantenerlos separados. El servicio de tiempo real pedirá al de almacenamiento las incidencias activas y escuchará de una cola los cambios publicados por el servicio de Device Presence Service.

Y con esto ya tendríamos la arquitectura completa cumpliendo con los requisitos funcionales:

Capítulo 6: Perfilando el Sistema para Cumplir con los Requisitos No Funcionales.

Los vuelvo a traer aquí para refrescar la memoria:

Las confirmaciones de recepción de eventos deben realizarse en el menor tiempo posible. Objetivo: <500 ms.

Las incidencias deben aparecer en la plataforma en menos de 5 segundos desde que se iniciaron.

Disponibilidad del sistema: SLA 99,99% (menos de 1 hora de downtime anual)

Para cumplir con nuestro primer requisito ya tenemos casi todo. Al haber desacoplado el "Event Ingestor" del servicio de Almacenamiento, podemos responder rápidamente sin tener que esperar a guardar el evento.

Como extra, podemos redundar el servicio y añadir un Balanceador de Carga (Load Balancer) para asegurar disponibilidad y poder hacer frente a incrementos estacionales, por ejemplo las operaciones entrada y salida de vacaciones.

Los dos últimos también los tenemos bastante encaminados. Al utilizar una base de datos clave-valor en memoria, las operaciones de lectura y escritura son muy rápidas. El sistema de colas además nos permite leer los eventos desde diferentes instancias del servicio.

En general, podemos duplicar tanto los servicios como las bases de datos para asegurar la alta disponibilidad y el escalado en caso de ser necesario. Esto dejará a nuestras bases de datos con una configuración AP en referencia al teorema CAP (Availability + Partition Tolerance). Tendremos por tanto consistencia eventual.

El sistema queda diseñado finalmente de la siguiente manera:

Capítulo 7: Últimos comentarios y puntos de mejora.

Hay ciertos temas en los que no he profundizado, más que nada porque ya están definidos en la documentación de la DGT y por tanto no aportaban mucho valor. Un dato clave para entender más a fondo todo esto es el actionid:

Durante todo el ciclo de vida de la incidencia existe un identificador único para cada baliza e incidencia. Es decir, una vez se apaga la baliza, el siguiente mensaje tendrá un ID de incidencia nuevo.

Un último apunte. Externalizar la recepción desde las balizas no evita que los propios proveedores no puedan ser víctimas del ataque y por tanto nosotros también como receptores finales de los eventos. No me he centrado en ello pero se podría implementar un servicio de análisis de transacciones para detectar posible actividad inusual (por ejemplo mensajes con localizaciones que no corresponden con carreteras) y de esta forma asegurar la calidad de los datos.

Y con esto voy terminando. No sé cómo estará implementado realmente el cloud de la DGT, sería interesante conocerlo. Sin embargo, desde fuera hay algunos detalles que me han llamado la atención en el diseño (ya más a bajo nivel) y para los que voy a dejar propuestas de mejora:

Inconsistencias en el Naming

El primero de ellos es la consistencia (o falta de ella) en el nombrado de las variables:

Tenemos idcompany y actionid. ¿Por qué no mantener la coherencia y tener el id delante o detrás en ambas?

idcompany y idaction
companyid y actionid (mi favorita)

Por otro lado, en estas no se separan las palabras, sin embargo en las últimas variables utilizan snake_case. ¿Por qué no algo como?

action_id y company_id

Un nombre polémico

actionid no parece muy representativo. En su propia definición:

Identificador único del evento anonimizando al dispositivo de origen, desde la activación a la desactivación

Quizá habría sido una mejor opción incidence_id o session_id. Algo que represente un poco mejor la idea de que este id debe ser único y constante durante el tiempo que dure la incidencia.

Un endpoint cuestionable

Okey, no hace falta que sea una API RESTful, pero mi comentario viene de aquí:

El método http ya es POST me parece en cierto modo redundante volver a meterlo en el nombre del endpoint (postincidence).

Un dominio poco institucional

Esto ya se ha comentado en algunas fuentes críticas con esta nueva medida, pero sí que es cierto que la API se ha desplegado en un dominio que no parece a primera vista de la DGT:

Sí que es cierto que es un dominio compartido por algunos de los otros servicios de la DGT 3.0, pero quizá no habría estado mal haberlo implementado como subdominio bajo el dominio dgt.es.

Despedida

Y ya estaría. Si te ha parecido interesante el post dale un like y comenta algo. Te aseguro que ha llevado un trabajo escribirlo y me encantará leer y discutir cualquier decisión de diseño. Hasta la próxima 🚀🫶

Recursos y Referencias

Documentación API V-16:

https://github.com/dgt30-esp/Caso-de-uso-1

Especificación Técnica de la baliza V-16

https://www.dgt.es/export/sites/web-DGT/.galleries/downloads/muevete-con-seguridad/tecnologia-e-innovacion/certificados-v16/SENAL-V-16_vf_ES.pdf

Tauri v2: Dos nuevos conceptos que debes conocer antes de actualizar tus apps a la nueva versión

David Jiménez — Sat, 17 Aug 2024 12:27:41 +0000

Tauri es un framework para crear aplicaciones multiplataforma que se presenta como la alternativa más ligera y segura a Electron. Gracias a que está escrito en Rust, permite crear aplicaciones más rápidas y ejecutables mucho más pequeños 🤏. Tras varios meses en versión beta, a principios de Agosto el equipo detrás de Tauri anunció la publicación de la Release Candidate de la versión 2 del framework y la muy próxima publicación de la versión estable. En este artículo veremos dos conceptos clave para entender esta nueva versión que viene cargada de novedades y con el foco puesto en la seguridad y la developer experience.

Plugins

Los plugins no son exactamente algo nuevo en Tauri. En la primera versión del framework ya contábamos con soporte para algunos plugins muy útiles (single-instance, sql, log, ...), sin embargo, en esta nueva versión, Tauri ha movido muchas de sus APIs a plugins externos, lo que permite un mayor control sobre lo que se instala y usa, así como una disminución del tamaño de los ejecutables.

Algunos de los nuevos plugins disponibles en la web de Tauri v2

Además de haber una gran cantidad de nuevos plugins disponibles, Tauri v2 incorpora un nuevo comando que permite instalar el plugin (añadir a package.json, Cargo.toml, inicializarlo en el archivo main.rs...) de manera automática ✨. Por ejemplo, este sería el comando para instalar el plugin deep-link:

npm run tauri add deep-link

Si aún así ninguno de estos plugins consigue lo que necesitas, la nueva versión de Tauri pone a los desarrolladores muy fácil el crear nuevas extensiones para el framework. 10/10 💫

Capabilities

Por otro lado, Tauri sigue poniendo el foco en la seguridad en el desarrollo de aplicaciones. Por ello, en esta nueva versión ha migrado su antiguo sistema de permisos a un sistema que permite ser mucho más específico en el uso de las APIs que utilizamos.

En la versión 2, el equipo de Tauri nos habla de Capabilities: un sistema de permisos que, al igual que se hacía a través del archivo tauri.config.json, permite definir qué APIs deben estar disponibles, pero también en qué plataforma, en qué ventanas concretas de la aplicación y sobre qué archivos (en el caso de ciertas APIs con acceso al sistema de archivos). Estos permisos además se pueden definir en diferentes archivos, lo que permite organizar el código de una forma más visual e intuitiva según lo necesite el desarrollador.

Ejemplo de un Archivo de Capabilities

Aunque seguramente ya te hayas hecho una idea, los permisos que comienzan por core: hacen referencia a Capabilities nativas de Tauri, mientras que las que pertenecen a plugins no lo hacen. Esta es una novedad publicada en la Release Candidate y es muy útil de cara a diferenciar los tipos de permisos que manejamos.

¿Qué te han parecido estos dos conceptos? ¿Ya has comenzado a migrar tus apps a las versión 2 de Tauri? Deja en comentarios qué otras novedades te parecen interesantes de la próxima versión de Tauri 🚀

Creating Your First Tauri App with React: A Beginner's Guide

David Jiménez — Wed, 05 Apr 2023 14:44:03 +0000

Hello everyone, I'm excited to share with you a tutorial on how to create your first Tauri app with React. My name is David, and I've been creating multiple apps recently with Tauri (and I love it). Tauri is a lightweight and secure Rust framework for creating cross-platform desktop applications. It allows you to use web technologies such as HTML, CSS, and JavaScript/TypeScript to build desktop apps, and supports multiple platforms, including Windows, macOS, and Linux.

In this tutorial, we'll go through the steps to create a Tauri app with React from scratch. I'll assume that you have some basic knowledge of React, although we are not going to do anything complicated. At the end of this tutorial, you'll have created a desktop app that will look like this:

Prerequisites:

Rust: You can download Rust from https://www.rust-lang.org/tools/install
Node.js: You can download Node.js from https://nodejs.org/en/
pnpm: (or your favourite package manager)

Step 1: Creating the Project Structure with create-tauri-app

Tauri provides a powerful cli tool to create projects from scratch. The first step is to create a new Tauri project using the create-tauri-app command. Open your terminal and run the following command:

$ pnpm create tauri-app

NOTE: You can find the correct command for your package manager here

The tool will ask you about the project technologies that you want to use. In my case:

Now let's follow the steps provided in the output:

$ cd tldrawapp
$ pnpm install

With this commands, we have installed the needed dependencies to work in our project.

You can run pnpm tauri dev to compile your project and see the template app working:

Before continuing, let's delete the generated code that we are not interested in. You can use VSCode and two extensions, tauri-vscode, and rust-analyzer, to do so.

The generated project has two important folders:

src: for the frontend (HTML, JS, CSS)
src-tauri: for the backend (rust)

We'll mainly work in src but let's remove some boilerplate from src-tauri:

Remove some code to make src-tauri/src/main.rs simpler. You don't need to do what we are doing, just remove unnecessary code to make it look like this:

// Prevents additional console window on Windows in release, DO NOT REMOVE!!
#![cfg_attr(not(debug_assertions), windows_subsystem = "windows")]

fn main() {
    tauri::Builder::default()
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

Now let's remove unnecessary code from the frontend: icons, default styles and some react code.

Delete src/styles.css, src/App.css, the src/assets folder and the svg files from public folder.
Remove the imports of the styles in the tsx files.
Delete all the content of the App component

Your file structure should look like this now:

And the content in the files:

App.tsx

function App() {
  return <h1>Welcome to Tauri!</h1>
}

export default App;

main.tsx

import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App";

ReactDOM.createRoot(document.getElementById("root") as HTMLElement).render(
  <React.StrictMode>
    <App />
  </React.StrictMode>
);

The app should look like this:

Step 2: Install and Use TLDraw

Next, we'll install the TLDraw library for drawing in our Tauri app. In your terminal, run the following command to install the package in the project:

$ pnpm add @tldraw/tldraw -E

We can now import the editor component in our App.tsx file and use it.

App.tsx

import { Tldraw } from "@tldraw/tldraw"

function App() {
  return <div>
    <Tldraw />
  </div>
}

export default App;

With this simple step we can see we have made a great advance in our app:

But it looks ugly for now. Let's add some styles! Create a new file in src:

styles.css

html,
* {
  box-sizing: border-box;
}

body {
  overscroll-behavior: none;
  margin: 0px;
  padding: 0px;
  font-size: 1em;
  font-family: Arial, Helvetica, sans-serif;
}

And then import it from main.tsx:

main.tsx

import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App";
import "./styles.css";

ReactDOM.createRoot(document.getElementById("root") as HTMLElement).render(
  <React.StrictMode>
    <App />
  </React.StrictMode>
);

The app now looks ✨ amazing ✨ and ready to publish:

NOTE: The app is missing some important styles, but I wanted to keep this simple and easy

Step 3: Set Up the Project for Creating the Executable

Before we can create the executable for our app, we need to configure the Tauri settings in the tauri.conf.json file. Open the file and modify the following configurations:

In the package entry:
- Change the productName field as you want.
- Change the version field to ../package.json: this will make Tauri use the version of the package.json so you don't need to update it in both files.
In the tauri entry:
- allowList: Tauri is a very secure environment for developing apps and it disables some web APIs by default. We must turn on some features for our app to work fine:
- Set dialog API to enable all features (this will allow our app to use the alert() and other related functions
- Change the bundle entry to customize your app identifier
- Modify the windows entry and change the app window title

The final configuration should look like this:
tauri.conf.json

{
  "build": {
    "beforeDevCommand": "pnpm dev",
    "beforeBuildCommand": "pnpm build",
    "devPath": "http://localhost:1420",
    "distDir": "../dist",
    "withGlobalTauri": false
  },
  "package": {
    "productName": "MyApp",
    "version": "../package.json"
  },
  "tauri": {
    "allowlist": {
      "all": false,
      "shell": {
        "all": false,
        "open": true
      },
      "dialog": {
        "all": true
      }
    },
    "bundle": {
      "active": true,
      "icon": [
        "icons/32x32.png",
        "icons/128x128.png",
        "icons/128x128@2x.png",
        "icons/icon.icns",
        "icons/icon.ico"
      ],
      "identifier": "my.tauri.app",
      "targets": "all"
    },
    "security": {
      "csp": null
    },
    "updater": {
      "active": false
    },
    "windows": [
      {
        "fullscreen": false,
        "resizable": true,
        "title": "My fisrt Tauri App",
        "width": 800,
        "height": 600
      }
    ]
  }
}

NOTE: keep in mind that if you are using a different package manager the first entries might be different.

Step 4: Build the executable

Now that our app is ready, we can generate the executables with:

pnpm tauri build

This will generate a executable file for your OS that you can share with your friends.

Download the code

All the code is available in this github repo :)

dubisdev / tauri-tutorial-tldraw

The repo containing the project with the TLDraw files

Tauri + React Tutorial

This repo contains the code for my Tauri + React Tutorial

View on GitHub

Outro

Thanks for reading this tutorial on creating your first Tauri app with React! I hope you found it helpful. If you have any questions or comments, feel free to leave them below.

If you enjoyed this tutorial, please consider supporting me by giving it a like, sharing it with your friends, or following me on my social media channels. I'll be sharing more tutorials, tips, and tricks on Tauri, React, and other web technologies that you won't want to miss!

dubisdev (David Jiménez) · GitHub

Creating apps :) 📚 SSME Student at URJC 🔧 JavaScript & TypeScript developer 🧠 @AddTodoist - dubisdev

github.com

dubis.dev

twitter.com

Cómo integrar Google Analytics en NextJS para cumplir con la Ley de Protección de Datos

David Jiménez — Sat, 09 Oct 2021 20:14:32 +0000

¿Qué vamos a hacer?

En este post configuraremos Google Analytics en una página web creada con NextJS, teniendo en cuenta la autorización del usuario para la recogida de datos y el uso de cookies.

Requisitos previos

Antes de comenzar con el código, necesitarás tener acceso a los siguientes recursos:

Archivo _document.js
Archivo _app.js

Puedes consultar la documentación oficial para saber qué son y cómo configurarlos en tu proyecto.

También deberás tener acceso a una cuenta de Google analytics y deberás crear un nuevo proyecto de GA y obtener la ID de seguimiento.

Configurar Google Analytics en la web

Configurando los scripts de Google Analytics

Lo primero que deberemos hacer es configurar los scripts de GA en el archivo _document.js. Estos scripts son los que se encargan de configurar la instancia de GA a nivel global en nuestro sitio web. Para ello abrimos el archivo _document.js y añadimos las siguientes líneas de código en el elemento head:

<script async src={`https://www.googletagmanager.com/gtag/js?id=${process.env.GOOGLE_ANALYTICS}`} />
<script dangerouslySetInnerHTML={{
    __html:`
        window.dataLayer = window.dataLayer || [];
        function gtag(){dataLayer.push(arguments);}

        gtag('consent', 'update', {
            'analytics_storage': 'granted'
        });

        gtag('js', new Date());

        gtag('config', '${process.env.GOOGLE_ANALYTICS}', {
            page_path: window.location.pathname,
        });
        `,
        }} />

El archivo final debería quedar similar a esto:

import Document, { Html, Head, Main, NextScript } from "next/document";

class MyDocument extends Document {
    static async getInitialProps(ctx) {
        const initialProps = await Document.getInitialProps(ctx);
        return { ...initialProps };
    }

    render() {
        return (
            <Html>
                <Head>
                    <script async src={`https://www.googletagmanager.com/gtag/js?id=${process.env.GOOGLE_ANALYTICS}`} />
                    <script
                        dangerouslySetInnerHTML={{
                            __html:`
                            window.dataLayer = window.dataLayer || [];
                            function gtag(){dataLayer.push(arguments);}

                            gtag('consent', 'update', {
                                'analytics_storage': 'granted'
                            });

                            gtag('js', new Date());

                            gtag('config', '${process.env.GOOGLE_ANALYTICS}', {
                                page_path: window.location.pathname,
                            });
                            `,
                        }}
                    />
                </Head>
                <body>
                    <Main />
                    <NextScript />
                </body>
            </Html>
        );
    }
}

export default MyDocument;

Como ves, estamos utilizando una variable de entorno, que configuraremos más adelante, donde se almacenará el ID de seguimiento de Google Analytics.

Además, para poder detectar los diferentes eventos que ocurren en la página, es necesario añadir las siguientes líneas al archivo _app.js:

import { useEffect } from "react";
import { useRouter } from "next/router";

//dentro del componente App
const router = useRouter();

useEffect(() => {
    const handleRouteChange = (url) => {
        window.gtag("config", process.env.GOOGLE_ANALYTICS, {
            page_path: url,
        });
    };
    router.events.on("routeChangeComplete", handleRouteChange);
    return () => {
        router.events.off("routeChangeComplete", handleRouteChange);
    };
}, [router.events]);

El archivo final quedará similar a esto:

import "../styles/globals.css";
import { useEffect } from "react";
import { useRouter } from "next/router";

function App({ Component, pageProps }) {
    const router = useRouter();

    useEffect(() => {
        const handleRouteChange = (url) => {
            window.gtag("config", process.env.GOOGLE_ANALYTICS, {
                page_path: url,
            });
        };
        router.events.on("routeChangeComplete", handleRouteChange);
        return () => {
            router.events.off("routeChangeComplete", handleRouteChange);
        };
    }, [router.events]);

    return <Component {...pageProps} />

}

export default App;

Pidiendo permiso al usuario: renderizado condicional de los scripts de GA.

Con esto ya tenemos Google Analytics funcionando en nuestro sitio web. Pero ahora debemos tener en cuenta que Google Analtics solo debe ser utilizado tras el consentimineto del usuario, por lo que procederemos a añadir los elementos necesarios para pedir ese permiso.

El primer cambio que debemos realizar es configurar los scripts de analytics para que no se carguen automáticamente. Para ello volveremos al archivo _document.js y añadiremos un condicional a nuestro código:

<script
    dangerouslySetInnerHTML={{
        __html: `
            window.dataLayer = window.dataLayer || [];
            function gtag(){dataLayer.push(arguments);}

            //configuramos el permiso como denegado en primera instancia
            gtag('consent', 'default', {
                'analytics_storage': 'denied'
            });

            gtag('js', new Date());

            //comprobamos el consentimiento
            if( consentimiento ) {
                gtag('consent', 'update', {
                'analytics_storage': 'granted'
                });
            }

            gtag('config', '${process.env.GOOGLE_ANALYTICS}', {
                page_path: window.location.pathname,
            });
        `,
    }}
/>

Ahora no se cargan automáticamente los scripts sino que dependerá del consentimiento del usuario.

Es el momento de preguntar al usuario si desea o no que realicemos seguimiento de sus datos. Para ello, podemos utilizar algún componente de React ya existente que nos permita preguntar al usuario y almacenar sus preferencias en una cookie de preferencias.

En este caso utilizaremos la librería react-cookie-consent.

Podemos instalarla a través de la consola en nuestro proyecto:

npm install react-cookie-consent

# o utilizando yarn

yarn add react-cookie-consent

Una vez instalado debemos añadir el componente de forma global, de manera que, entre donde entre el usuario, se le pregunte por sus preferencias, en caso de no tener un registro previo de las mismas. Este componente se encarga automáticamente de comprobar si ya hay una cookie previa de preferencias por lo que será muy facil implementar el sistema.

Para añadirlo de forma global lo añadimos al componente App de nuestra web:

import "../styles/globals.css";
import { useEffect } from "react";
import { useRouter } from "next/router";
import CookieConsent from "react-cookie-consent";

function App({ Component, pageProps }) {
const router = useRouter();

    useEffect(() => {
        const handleRouteChange = (url) => {
            window.gtag("config", process.env.GOOGLE_ANALYTICS, {
                page_path: url,
            });
        };
        router.events.on("routeChangeComplete", handleRouteChange);
        return () => {
            router.events.off("routeChangeComplete", handleRouteChange);
        };
    }, [router.events]);

    return (
        <>
            <Component {...pageProps} />
            <CookieConsent
            location="bottom"
            buttonText="Sí, utilizar cookies."
            onAccept={() => location.reload()}
            cookieName="CookieConsent"
            expires={150}
            enableDeclineButton="true"
            declineButtonText="No, no utilizar cookies"
            >
            Poner aquí el mensaje sobre el uso de cookies
            <a href="#enlace_hacia_politica_de_cookies">Política de Cookies</a>.
        </CookieConsent>
        </>
    );

}

export default App;

Puedes cosultar el repo del componente para configurarlo a tu gusto.

Ya tenemos la capacidad de crear una cookie de preferencias y de preguntarle al usuario qué es lo que quiere. Ahora debemos volver al archivo _document.js e introducir la función que nos devuelva el valor de la cookie de preferencias, para saber si debemos cargar el script de rastreo o no.

Añadimos lo siguiente en el archivo _document.js:

<script
    dangerouslySetInnerHTML={{
        __html: `
        window.dataLayer = window.dataLayer || [];
        function gtag(){dataLayer.push(arguments);}
        //this defaults to denying
        gtag('consent', 'default', {
            'analytics_storage': 'denied'
        });

        gtag('js', new Date());

        //este función es la que nos devuelve el valor de la cookie de preferencias
        function getCookie() {
            const value = "; " + document.cookie;
            const parts = value.split("; CookieConsent=");
            if (parts.length === 2) return parts.pop().split(';').shift();
        }

        //únicamente si el valor es true, se cargan los scripts de Google Analytics.
        if(getCookie() === "true"){
            gtag('consent', 'update', {
                'analytics_storage': 'granted'
            });
        }

        gtag('config', '${process.env.GOOGLE_ANALYTICS}', {
            page_path: window.location.pathname,
        });
        `,
    }}
/>

Con esto ya tendremos todo funcionando 🚀. Ahora deberás hacer un deploy en Vercel y configurar la variable de entorno GOOGLE_ANALYTICS con el valor del ID de rastreo de tu sitio web.
Tras añadir la variable de entorno deberás de hacer otro despliegue para que estas san tenidas en cuenta en tu sitio web.

Código completo

Puedes ver todo el código en el siguiente repositorio:

dubisdev / nextjs-analytics-rgpd

This is a Next.js project bootstrapped with create-next-app.

Getting Started

First, run the development server:

npm run dev
# or
yarn dev

Open http://localhost:3000 with your browser to see the result.

You can start editing the page by modifying pages/index.js. The page auto-updates as you edit the file.

API routes can be accessed on http://localhost:3000/api/hello. This endpoint can be edited in pages/api/hello.js.

The pages/api directory is mapped to /api/*. Files in this directory are treated as API routes instead of React pages.

Learn More

To learn more about Next.js, take a look at the following resources:

Next.js Documentation - learn about Next.js features and API.
Learn Next.js - an interactive Next.js tutorial.

You can check out the Next.js GitHub repository - your feedback and contributions are welcome!

Deploy on Vercel

The easiest way to deploy your Next.js app is to use the Vercel Platform from…

View on GitHub

Crear una página de Política de Cookies

¡Espera un momento! Todavía queda un paso importante: crear una página donde expliques el uso que se le da a las cookies y las instrucciones para revocar los permisos y/o borrar los datos en caso de ser necesario.

Como idea, puedes echarle un vistazo a la publicación de la Agencia Estatal de Protección de Datos para saber qué debe incluir.

Exención de responsabilidades

Este post contiene información general sobre la configuración de Google Analytics y el cumplimiento con la legislación vigente de España al día de la fecha. Los requisitos legales podrían ser diferentes atendiendo al tipo de empresa, localización y finalidad de la recogida de datos, por lo que es importante que se revise y consulte con una persona experta las necesidades legales de cada sitio web.

Connecting to MongoDB from ESB Mule

David Jiménez — Sat, 09 Oct 2021 19:59:48 +0000

I recently discovered Anypoint Studio and the first question that came up to me was: how can I access my MongoDB cluster?
This is the fastest solution I have found :)

Create the Mule Project

Configure an HTTP Listener

With the sole purpose of being able to test our project later, I have added and configured an HTTP Listener:

Install and configure the MongoDB connector

Open the Mule Palette view and select Search in Exchange.
In the search box type "mongo" and search "MongoDB Connector" in the Available Modules tab. Then select it and click add and finish.

Make sure you choose the 6.3 version or higher.
Navigate to Global Elements tab.
Select Create > Connector Configuration > MongoDB config
In the General tab select "Connection string" as connection option.
Some libraries must be installed. Just click Configure... > Add Recommended Libraries

Now we must include the connection string from our MongoDB atlas clusters.

Get your Connection String

Go to your MongoDB Atlas project
Select connect
Choose "Connect your application" and select Java as your application language (this is just for getting the connection string).
Then copy the connection string and follow the MongoDB instructions (Replace password...)
Paste it to the Mule Connection string textbox...
Select Test Connection to test if alll is working well

[If you are having issues check the project allowed IPs and the database allowed users in your MongoDB settings]

Try it!

From the Mule pallete add Create Collection and Insert document elements and select as Connector_Configuration the config we have just created.
Configure both elements with the collection name and the document you want to insert...
Run the project, go to the HTTP listener url and then to your MongoDB collection list...

And that's all! I hope this information is useful for your projects :)