TFG — Javier Mengual — 2026

DoliMiddlewareApi

Tu frontend merece algo mejor que strings rotos

El frontend no debería tener que lidiar con esto

Dolibarr funciona. Pero su API devuelve un desastre que no puedes entregarle a un frontend moderno y decir "aquí tienes, apañatelas".

Lo que te da Dolibarr

IDs como "string"
Fechas en timestamp Unix
Estados que son números: "1"
snake_case inconsistente
Credenciales volando por ahí

Lo que tu frontend merece

IDs como int
Fechas ISO 8601
Estados legibles: "unpaid"
camelCase
Un JWT y ya está

Un escudo entre tu app y el caos

El patrón BFF —Backend for Frontend— no es un proxy. Es una capa que traduce, protege y enriquece. Tu frontend habla con él, y él se ocupa de lo demás.

Dolibarr
⟶
BFF
⟶
Tu frontend
  • El frontend nunca habla con Dolibarr directamente
  • Si el ERP cambia algo, tocas un sitio, no cincuenta
  • Y puedes meterle cosas que Dolibarr jamás va a tener

Así funciona

Arquitectura

¿Por qué .NET 10?

Si voy a poner una API en producción, quiero dormir tranquilo tres años.

LTS hasta 2028

Tres años de soporte. Me da igual lo que pase meantime.

Rendimiento

Lo suficientemente rápido para que la latencia no sea un problema.

Todo incluido

JWT, rate limiting, health checks, OpenAPI. Sin buscar librerías raras.

Lo que cubre

Auth — login, JWT

Facturas — CRUD, líneas, pagos, estado

Clientes — con contactos incluidos

Proveedor — facturas de proveedor

Bancos — cuentas y movimientos

Documentos — PDFs de facturas

Setup — diccionarios, país, compañía

Notificaciones — webhooks

Sí, gran parte es 1:1 con Dolibarr. Pero el BFF añade lo que el ERP no tiene: tipos correctos, estados legibles, enriquecimiento con nombres de cliente y notificaciones.

De francés y strings... a inglés y tipos

Dolibarr

{
  "statut":    "1",
  "total_ttc": "150.50",
  "date":      "1715673600",
  "socid":     "3"
}

BFF

{
  "status":   "unpaid",
  "total":    150.50,
  "date":     "2024-05-14",
  "clientId": 3
}

Mismo dato. Otro mundo.

Documentación automática

Swagger UI

OpenAPI 3.1 generado al arrancar. Cada endpoint documentado.

La contraseña nunca sale del servidor

El frontend maneja un JWT. La API key de Dolibarr queda atrapada dentro del BFF. Si alguien intercepta el token del usuario, caduca en 8 horas y no tiene acceso al ERP.

1 — Login

El usuario se autentica. El BFF recibe la API key de Dolibarr y la guarda en memoria.

2 — JWT

El BFF genera un JWT para el navegador. La API key nunca sale de ahí.

3 — Cada petición

El JWT lleva un sessionId. Con ese sessionId se busca la API key en caché y se inyecta al vuelo.

Cada usuario tiene su propia API key aislada. Si se cachease en el HttpClient, todos compartirían la misma.

Lo que un wrapper puede hacer que el ERP no

Al poner una capa por delante, puedes añadirle cosas que Dolibarr nunca va a tener. El ejemplo más claro: cuando una factura cambia de estado, el equipo se entera al momento. Sin abrir el sistema, sin mirar nada.

Teams, Slack, lo que sea

Configuras una URL y avisa donde quieras. Hoy es Teams, mañana puede ser Telegram, email, lo que haga falta.

La interfaz ya está

Añadir un canal nuevo es implementar una interfaz. El resto del código ni se toca. Así se escala un wrapper de verdad.

Un comando y funciona

docker compose up

services:
  mysql:
    image: mysql:8.0
    environment:
      MYSQL_DATABASE: dolibarr
    volumes: [mysql_data:/var/lib/mysql]

  dolibarr:
    image: dolibarr/dolibarr:latest
    depends_on: [mysql]
    ports: ["80:80"]

  bff:
    build: ./DoliMiddlewareApi
    depends_on: [dolibarr]
    ports: ["5001:8080"]

MySQL, Dolibarr, el BFF. Tres contenedores, un comando.

Preguntas