DEV Community: AbianS

Tu agente de IA tiene memoria de pez. Así lo solucioné.

AbianS — Tue, 13 Jan 2026 22:10:19 +0000

Si usas Claude Code, Cursor, Copilot o cualquier agente de IA para programar, seguro te ha pasado esto:

Le explicas a tu agente que en tu proyecto siempre usas Zustand para el estado, que los endpoints van en /api/v1/, que nunca uses any en TypeScript... y a los 20 minutos te genera código con Redux, rutas en /api/ y un any que te hace llorar.

El agente olvidó todo.

Y no es culpa suya. Estos agentes no tienen memoria persistente. Cada sesión es borrón y cuenta nueva.

El problema real

Cuando trabajas con agentes de IA en proyectos reales, te encuentras con esto:

Repetir las mismas instrucciones — "Usa Bun, no Node", "Los tests van con Vitest", "El formato de commits es conventional commits"... una y otra vez.
Decisiones que se pierden — Ayer decidiste usar un patrón específico después de 30 minutos de análisis. Hoy el agente no tiene ni idea y te propone algo completamente diferente.
Errores que se repiten — El agente intentó un approach que falló. ¿Crees que lo recuerda mañana? Spoiler: no.
Contexto del proyecto inexistente — El agente no sabe que tu función calculateTax() tiene un bug conocido, o que el módulo de pagos está deprecado.

Es como trabajar con un desarrollador que tiene amnesia cada mañana.

"¿Y si uso un archivo CLAUDE.md con todo el contexto?"

Es la solución más común. Muchos creamos archivos .md con instrucciones del proyecto:

# CLAUDE.md
- Usar Bun en lugar de Node
- Los tests van con bun test
- Siempre usar TypeScript strict
- La base de datos es SQLite
- Los endpoints siguen el patrón /api/v1/...

El problema: no escala.

Los modelos de IA tienen un límite de contexto (tokens). Cada vez que inicias una sesión, ese archivo .md consume parte de ese límite. Y aquí viene el problema:

Proyectos pequeños: Funciona bien. Tu CLAUDE.md tiene 500 tokens, el agente tiene espacio de sobra.
Proyectos medianos: Empiezas a añadir más reglas, decisiones arquitectónicas, patrones... El archivo crece a 5,000 tokens.
Proyectos grandes: Tu contexto del proyecto compite con el código que necesitas que el agente analice. Tienes que elegir: ¿contexto del proyecto o código relevante?

┌─────────────────────────────────────┐
│          LÍMITE DE CONTEXTO          │
├─────────────────────────────────────┤
│   CLAUDE.md (crece sin control)     │  ← Compite por espacio
├─────────────────────────────────────┤
│   Código actual del proyecto         │  ← Lo que realmente importa
├─────────────────────────────────────┤
│   Tu conversación con el agente      │
└─────────────────────────────────────┘

Además, un archivo .md estático tiene otros problemas:

No es selectivo — Carga TODO aunque solo necesites una parte
No aprende — No puede registrar qué funcionó y qué no
No evoluciona — Tienes que actualizarlo manualmente
Sin búsqueda semántica — Si buscas "manejo de estado", no encuentra "Zustand para store global"

Lo que necesitas es memoria dinámica que:

Cargue solo lo relevante para la tarea actual
Aprenda de errores pasados
Se actualice automáticamente
Entienda el contexto semántico

La solución: darle memoria al agente

Creé code-recall, un servidor MCP (Model Context Protocol) que actúa como la memoria persistente de tu agente de IA.

¿Qué es MCP? Es un protocolo que permite a los agentes de IA conectarse con herramientas externas. Claude Code, Cursor y otros ya lo soportan nativamente.

¿Qué puede recordar?

Decisiones de arquitectura:

"Decidimos usar SQLite en lugar de PostgreSQL porque el proyecto es local-first y no necesita un servidor de base de datos."

Patrones del proyecto:

"En este proyecto, todos los componentes de UI van en src/components/ui/ y siguen el patrón de composición."

Warnings importantes:

"NUNCA modificar la función legacyAuth() — está deprecada pero 15 servicios dependen de ella."

Aprendizajes de errores:

"Intentamos usar fs.watch para hot-reload pero fallaba en macOS. La solución fue usar chokidar."

Reglas automáticas (Guardrails)

Además de memorias, puedes definir reglas que el agente debe seguir:

Trigger: "creando un endpoint de API"
Must do:
  - Agregar validación de input con Zod
  - Escribir tests de integración
  - Documentar en OpenAPI
Must NOT:
  - Usar `any` en los tipos
  - Retornar errores como strings
Ask first:
  - ¿Requiere autenticación?

Cada vez que el agente detecta que está creando un endpoint, automáticamente recuerda estas reglas.

Cómo funciona por dentro

code-recall usa búsqueda semántica, no keywords. Esto significa que si guardaste:

"Usar Zustand para manejo de estado global"

Y luego preguntas sobre "state management" o "dónde guardar datos de la sesión", el sistema entiende que es relevante y lo recupera.

La arquitectura:

SQLite — Base de datos local, sin servidores externos
sqlite-vec — Extensión para búsqueda vectorial
Embeddings locales — Modelo MiniLM que corre 100% en tu máquina (sin enviar datos a ningún lado)
Bun — Runtime ultrarrápido

Todo corre localmente. Tus memorias no salen de tu computadora.

Instalación en 2 minutos

Requisitos

Bun instalado (curl -fsSL https://bun.sh/install | bash)

Instalar

bun install -g code-recall

Configurar con Claude Code

Añade esto a tu configuración de MCP (~/.claude/claude_desktop_config.json):

{
  "mcpServers": {
    "code-recall": {
      "command": "bunx",
      "args": ["code-recall"]
    }
  }
}

Reinicia Claude Code y listo.

Uso en la práctica

Una vez configurado, el agente tiene acceso a estas herramientas:

Guardar una decisión

"Guarda que decidimos usar React Query para data fetching
porque necesitamos cache automático y revalidación"

El agente llama a store_observation internamente.

Buscar contexto

"¿Qué decisiones hemos tomado sobre manejo de estado?"

El agente busca semánticamente en tus memorias.

Crear una regla

"Crea una regla: cuando modifique componentes de UI,
siempre debo verificar accesibilidad con jest-axe"

Verificar reglas antes de actuar

"Voy a crear un nuevo hook de React,
¿hay alguna regla que deba seguir?"

Analizar estructura de código

"Analiza la estructura de src/services/auth.ts"

Extrae clases, funciones, interfaces y tipos del archivo.

Automatizando todo con Skills

Usar las herramientas manualmente está bien, pero ¿no sería mejor que el agente automáticamente consultara la memoria antes de hacer cambios?

Para eso creé una Skill de Claude Code. Las Skills son instrucciones que enseñan a Claude cuándo y cómo usar herramientas específicas.

Instalación de la Skill

# Desde la raíz de tu proyecto
mkdir -p .claude/skills/code-recall
curl -o .claude/skills/code-recall/SKILL.md \
  https://raw.githubusercontent.com/AbianS/code-recall/main/.claude/skills/code-recall/SKILL.md

¿Qué hace la Skill?

Una vez instalada, Claude automáticamente:

Al inicio de sesión:

→ Llama a get_briefing() para cargar el contexto del proyecto
→ Ve estadísticas, warnings activos y errores pasados

Antes de hacer cambios:

→ Ejecuta search_memory() para buscar decisiones relacionadas
→ Ejecuta check_rules() para verificar qué reglas aplican

Después de tomar decisiones:

→ Guarda la decisión con store_observation()
→ Incluye el razonamiento para referencia futura

Después de implementar:

→ Registra si funcionó o falló con record_outcome()
→ Los fallos se priorizan en búsquedas futuras

Ejemplo real

Sin la Skill, tendrías que decir:

"Antes de crear este endpoint, busca si hay decisiones sobre autenticación y verifica las reglas de APIs"

Con la Skill instalada, simplemente dices:

"Crea un endpoint para obtener el perfil del usuario"

Y Claude automáticamente:

Busca decisiones pasadas sobre endpoints y autenticación
Verifica las reglas que aplican a "crear endpoint"
Te muestra: "Encontré que usamos JWT y hay una regla que requiere rate limiting"
Implementa siguiendo el contexto
Guarda la decisión si es relevante

Es la diferencia entre tener un asistente al que debes recordarle todo vs. uno que ya conoce el proyecto.

El flujo ideal

Inicio del proyecto: Defines las reglas base y decisiones de arquitectura
Durante el desarrollo: El agente consulta automáticamente antes de generar código
Cuando algo falla: Guardas el aprendizaje para no repetir el error
Sesiones futuras: Todo el contexto persiste, sin repetir explicaciones

Resultados reales

Desde que uso code-recall en mis proyectos:

Cero repeticiones de instrucciones básicas del proyecto
Consistencia en el código generado (mismo estilo, mismos patrones)
Menos errores porque el agente recuerda qué no funcionó antes
Onboarding más rápido cuando vuelvo a un proyecto después de semanas

Open Source

code-recall es completamente open source y gratuito.

GitHub: github.com/AbianS/code-recall
npm: bun install -g code-recall

Si te parece útil, una estrella en GitHub ayuda mucho.

TL;DR

Los agentes de IA olvidan todo entre sesiones. code-recall es un servidor MCP que les da memoria persistente:

Guarda decisiones, patrones, warnings y aprendizajes
Define reglas que el agente debe seguir automáticamente
Búsqueda semántica (entiende contexto, no solo keywords)
100% local, tus datos no salen de tu máquina
Instalación en 2 minutos

bun install -g code-recall

Dale memoria a tu agente. Tu yo del futuro te lo agradecerá.

Algoritmo de Levenshtein en TypeScript: Búsqueda Inteligente con Tolerancia a Errores

AbianS — Mon, 10 Nov 2025 20:03:14 +0000

Cómo implementar fuzzy matching para que tus usuarios encuentren lo que buscan, aunque lo escriban mal

El problema: búsquedas que no encuentran nada

¿Alguna vez te has encontrado con esto?

const userSearch = "Oppenhaimer";  // Usuario se equivocó en una letra
const movieTitle = "Oppenheimer";

if (userSearch === movieTitle) {
  console.log("¡Encontrado!");
} else {
  console.log("No se encontró nada"); // 😭
}

Resultado: No se encuentra nada. Tu usuario se va frustrado a la competencia.

Hoy vamos a solucionar esto con el algoritmo de distancia de Levenshtein. Implementación completa en TypeScript, casos de uso reales y optimizaciones incluidas.

¿Qué es la distancia de Levenshtein?

La distancia de Levenshtein es, básicamente, cuántas operaciones necesitas para transformar una palabra en otra. Las operaciones permitidas son:

Insertar una letra
Eliminar una letra
Sustituir una letra

Ejemplo visual:

"kitten" → "sitting"

k → s  (sustituir)    = "sitten"
e → i  (sustituir)    = "sittin"
+ g    (insertar)     = "sitting"

Distancia: 3 operaciones

Esto nos da un número mágico que podemos convertir en un porcentaje de similitud. Y con ese porcentaje, podemos hacer cosas muy interesantes.

Caso de uso real: Buscador tolerante a errores

Tienes una web donde los usuarios buscan películas, pero escriben:

"Interestelar" en lugar de "Interstellar"
"El señor de los anillos" sin acentos ni mayúsculas
"Oppenhaimer" con un error de tipeo

Necesitas un sistema que encuentre resultados aunque no sean exactos.

Búsqueda tradicional (❌ La que NO queremos)

const movies = [
  "The Dark Knight",
  "Inception",
  "Interstellar",
  "The Prestige"
];

const search = "Interestelar"; // Usuario se equivocó

// Búsqueda exacta
const result = movies.find(m => m.toLowerCase() === search.toLowerCase());
console.log(result); // undefined 😢

Búsqueda con Levenshtein (✅ La que SÍ queremos)

const search = "Interestelar";

const results = movies
  .map(movie => ({
    title: movie,
    similarity: calculateSimilarity(search, movie)
  }))
  .sort((a, b) => b.similarity - a.similarity);

console.log(results[0]);
// { title: "Interstellar", similarity: 91 } ✨

Implementación paso a paso

Paso 1: Normalización de texto

Primero normalizamos (quitar acentos, minúsculas, etc.):

function normalizeText(text: string): string {
  return text
    .toLowerCase()
    .normalize("NFD")                    // Descompone acentos
    .replace(/[\u0300-\u036f]/g, "")    // Elimina diacríticos
    .replace(/[^a-z0-9\s]/g, "")        // Quita caracteres especiales
    .replace(/\s+/g, " ")
    .trim();
}

Paso 2: Algoritmo de Levenshtein

Usamos programación dinámica con una matriz:

function levenshteinDistance(str1: string, str2: string): number {
  const s1 = normalizeText(str1);
  const s2 = normalizeText(str2);

  if (s1 === s2) return 0;

  const matrix: number[][] = [];

  // Inicializar matriz
  for (let i = 0; i <= s2.length; i++) matrix[i] = [i];
  for (let j = 0; j <= s1.length; j++) matrix[0][j] = j;

  // Llenar matriz calculando mínimo costo
  for (let i = 1; i <= s2.length; i++) {
    for (let j = 1; j <= s1.length; j++) {
      if (s2[i - 1] === s1[j - 1]) {
        matrix[i][j] = matrix[i - 1][j - 1]; // Sin costo
      } else {
        matrix[i][j] = Math.min(
          matrix[i - 1][j - 1] + 1,  // Sustitución
          matrix[i][j - 1] + 1,      // Inserción
          matrix[i - 1][j] + 1       // Eliminación
        );
      }
    }
  }

  return matrix[s2.length][s1.length];
}

Paso 3: Convertir a porcentaje

function calculateSimilarity(str1: string, str2: string): number {
  const s1 = normalizeText(str1);
  const s2 = normalizeText(str2);

  if (s1 === s2) return 100;

  const distance = levenshteinDistance(str1, str2);
  const maxLength = Math.max(s1.length, s2.length);
  const similarity = ((maxLength - distance) / maxLength) * 100;

  return Math.round(similarity);
}

// Ejemplos
calculateSimilarity("Oppenheimer", "Oppenhaimer");   // 91%
calculateSimilarity("Interstellar", "Interestelar"); // 91%
calculateSimilarity("Batman", "Superman");           // 29%

Buscador inteligente completo

interface Movie {
  id: string;
  title: string;
  originalTitle: string;
}

function findBestMatch(query: string, movies: Movie[]) {
  const matches = movies.map(movie => {
    const titleScore = calculateSimilarity(query, movie.title);
    const originalScore = movie.originalTitle
      ? calculateSimilarity(query, movie.originalTitle)
      : 0;

    return {
      movie,
      score: Math.max(titleScore, originalScore)
    };
  });

  matches.sort((a, b) => b.score - a.score);
  const best = matches[0];

  return best.score >= 60 ? best : null;
}

const movies = [
  { id: "1", title: "El Caballero Oscuro", originalTitle: "The Dark Knight" },
  { id: "2", title: "Origen", originalTitle: "Inception" },
  { id: "3", title: "Interestelar", originalTitle: "Interstellar" }
];

findBestMatch("Interstellar", movies);
// { movie: {...}, score: 100 }

findBestMatch("Interestelar", movies);
// { movie: {...}, score: 91 }

findBestMatch("Dark Knight", movies);
// { movie: {...}, score: 75 }

Optimizaciones clave

Threshold inteligente

function getSmartThreshold(queryLength: number): number {
  if (queryLength <= 3) return 90;  // Palabras cortas: estricto
  if (queryLength <= 10) return 70;
  return 60;  // Palabras largas: tolerante
}

Cache de resultados

const cache = new Map<string, number>();

function getCachedSimilarity(str1: string, str2: string): number {
  const key = `${str1}:${str2}`;
  if (cache.has(key)) return cache.get(key)!;

  const result = calculateSimilarity(str1, str2);
  cache.set(key, result);
  return result;
}

Pre-filtrado para datasets grandes

function smartSearch(query: string, movies: Movie[]) {
  // Pre-filtro por primera letra
  const firstLetter = normalizeText(query)[0];
  const filtered = movies.filter(m => 
    normalizeText(m.title)[0] === firstLetter
  );

  return findBestMatch(query, filtered);
}

Otros casos de uso

Autocompletado inteligente

function getSuggestions(input: string, items: string[]) {
  return items
    .map(item => ({ item, score: calculateSimilarity(input, item) }))
    .filter(({ score }) => score > 70)
    .sort((a, b) => b.score - a.score)
    .slice(0, 5)
    .map(({ item }) => item);
}

getSuggestions("gith", ["github", "gitlab", "bitbucket"]);
// ["github", "gitlab"]

Corrección de comandos CLI

// Usuario escribe: git comit
// Output: ❌ Comando 'comit' no encontrado
//         💡 ¿Quisiste decir 'commit'?

function suggestCommand(typo: string, validCommands: string[]) {
  const best = findBestMatch(typo, validCommands.map(c => ({ 
    id: c, 
    title: c, 
    originalTitle: c 
  })));

  if (best && best.score > 70) {
    console.log(`💡 ¿Quisiste decir '${best.movie.title}'?`);
  }
}

Deduplicación de usuarios

function findDuplicates(users: User[]) {
  const duplicates = [];

  for (let i = 0; i < users.length; i++) {
    for (let j = i + 1; j < users.length; j++) {
      const emailScore = calculateSimilarity(users[i].email, users[j].email);
      const nameScore = calculateSimilarity(users[i].name, users[j].name);

      if (emailScore > 90 || nameScore > 95) {
        duplicates.push([users[i], users[j]]);
      }
    }
  }

  return duplicates;
}

Performance

Complejidad: O(n × m) - donde n y m son longitudes de strings

Benchmarks:

2 palabras (10 chars): ~0.01ms ✅
2 títulos (30 chars): ~0.05ms ✅
100 películas vs 1 búsqueda: ~5ms ✅
10,000 películas: ~500ms ⚠️

Para datasets grandes:

Pre-filtrado por primera letra
Indexación (Elasticsearch)
Worker threads en paralelo

Código completo listo para usar

// utils/similarity.ts

export function normalizeText(text: string): string {
  return text
    .toLowerCase()
    .normalize("NFD")
    .replace(/[\u0300-\u036f]/g, "")
    .replace(/[^a-z0-9\s]/g, "")
    .replace(/\s+/g, " ")
    .trim();
}

export function calculateSimilarity(str1: string, str2: string): number {
  const s1 = normalizeText(str1);
  const s2 = normalizeText(str2);

  if (s1 === s2) return 100;

  const matrix: number[][] = [];

  for (let i = 0; i <= s2.length; i++) matrix[i] = [i];
  for (let j = 0; j <= s1.length; j++) matrix[0][j] = j;

  for (let i = 1; i <= s2.length; i++) {
    for (let j = 1; j <= s1.length; j++) {
      if (s2[i - 1] === s1[j - 1]) {
        matrix[i][j] = matrix[i - 1][j - 1];
      } else {
        matrix[i][j] = Math.min(
          matrix[i - 1][j - 1] + 1,
          matrix[i][j - 1] + 1,
          matrix[i - 1][j] + 1
        );
      }
    }
  }

  const distance = matrix[s2.length][s1.length];
  const maxLength = Math.max(s1.length, s2.length);

  return Math.round(((maxLength - distance) / maxLength) * 100);
}

export function findClosest<T>(
  query: string,
  items: T[],
  getKey: (item: T) => string
) {
  const matches = items.map(item => ({
    item,
    score: calculateSimilarity(query, getKey(item))
  }));

  matches.sort((a, b) => b.score - a.score);
  return matches[0].score > 60 ? matches[0] : null;
}

Conclusión

El algoritmo de Levenshtein mejora drásticamente la UX de cualquier sistema de búsqueda.

Resumen:

✅ Algoritmo simple pero poderoso
✅ Fácil de implementar en TypeScript
✅ Múltiples casos de uso (búsquedas, CLI, deduplicación)
✅ Performance aceptable con optimizaciones

Próximos pasos:

Implementa en tu proyecto
Ajusta thresholds según tu caso de uso
Combina con Elasticsearch para datasets grandes
Mide el impacto en conversión/satisfacción

Recursos:

¿Implementaste fuzzy matching en tu proyecto? ¡Comparte tu experiencia en los comentarios! 👇

Sígueme para más artículos sobre TypeScript, arquitectura y patrones de diseño. 🚀

Make Your App Grow Painlessly: How I Escaped Repetitive Code Thanks to the Provider Pattern

AbianS — Thu, 16 Oct 2025 15:43:16 +0000

A few days ago I wrote about Docker DB Manager, a desktop application that simplifies managing database containers in Docker.

But there was a problem: every time I added support for a new database, I had to write duplicate code in both Rust and TypeScript. It was tedious, error-prone, and frustrating.

Today I'll tell you how I completely transformed the architecture using the Provider pattern, turning the addition of new databases into something as simple as writing a TypeScript class.

What is the Provider Pattern?

The Provider pattern is a design pattern that allows you to delegate the responsibility of providing specific functionality to interchangeable components. Instead of having centralized logic with conditionals for each case, each provider implements a common interface and handles its own configuration and behavior.

The core idea: Instead of asking "what type are you?" and acting accordingly, we ask the object: "what do you need?" and it provides it.

This pattern is especially useful when:

You have multiple implementations of the same functionality
Each implementation has its own specific logic
You want to add new implementations without modifying existing code
You need to keep the code decoupled and scalable

The Problem: Duplicate Code Everywhere

Backend in Rust with Specific Logic

In docker.rs I had a giant method with a match statement for each database:

pub fn build_docker_command(
    &self,
    request: &CreateDatabaseRequest,
    volume_name: &Option<String>,
) -> Result<Vec<String>, String> {
    let mut args = vec![
        "run".to_string(),
        "-d".to_string(),
        "--name".to_string(),
        request.name.clone(),
        "-p".to_string(),
        format!("{}:{}", request.port, self.get_default_port(&request.db_type)),
    ];

    // Añadir volumen si persist_data es true
    if let Some(vol_name) = volume_name {
        args.push("-v".to_string());
        args.push(format!("{}:{}", vol_name, self.get_data_path(&request.db_type)));
    }

    // Variables de entorno según el tipo de base de datos
    match request.db_type.as_str() {
        "PostgreSQL" => {
            args.push("-e".to_string());
            args.push(format!("POSTGRES_PASSWORD={}", request.password));

            if let Some(username) = &request.username {
                if username != "postgres" {
                    args.push("-e".to_string());
                    args.push(format!("POSTGRES_USER={}", username));
                }
            }
            // ... más configuración específica de PostgreSQL
        }
        "MySQL" => {
            args.push("-e".to_string());
            args.push(format!("MYSQL_ROOT_PASSWORD={}", request.password));
            // ... más configuración específica de MySQL
        }
        "MongoDB" => {
            // ... configuración específica de MongoDB
        }
        "Redis" => {
            // ... configuración específica de Redis
        }
        // ... más casos para cada base de datos
        _ => return Err(format!("Database type not supported: {}", request.db_type)),
    }

    Ok(args)
}

Frontend with Infinite Conditionals

// En container-configuration-step.tsx (¡561 líneas!)
function ContainerConfigurationStep() {
  // Campos diferentes según el tipo de base de datos
  if (selectedDatabase === 'PostgreSQL') {
    return (
      <div>
        <Input label="Username" defaultValue="postgres" />
        <Input label="Password" type="password" />
        <Select label="Host Auth Method">
          <option>md5</option>
          <option>scram-sha-256</option>
        </Select>
        {/* ... 100 líneas más de configuración específica */}
      </div>
    )
  }

  if (selectedDatabase === 'MySQL') {
    return (
      <div>
        <Input label="Root Password" type="password" />
        <Select label="Character Set">
          <option>utf8mb4</option>
          <option>utf8</option>
        </Select>
        {/* ... otra configuración específica */}
      </div>
    )
  }

  // ... más ifs para MongoDB, Redis, etc.
}

The Real Cost

Adding MariaDB meant touching 19 different files and about 3-4 hours of work. Each change required modifying both Rust and TypeScript, keeping types in sync, and testing everything manually.

The Solution: Apply the Provider Pattern

The key transformation: Instead of having centralized logic that knows about all databases, each database becomes a provider that describes itself.

This is exactly the Provider pattern in action. Let's see how:

Step 1: Define the Contract with an Interface

The first step is to create an interface that all providers must comply with. This interface is the contract that guarantees each database can provide all the necessary information:

export interface DatabaseProvider {
  // Identificación
  readonly id: string;
  readonly name: string;
  readonly icon: ReactNode;
  readonly color: string;

  // Configuración Docker
  readonly defaultPort: number;
  readonly dataPath: string;
  readonly versions: string[];

  // Métodos que cada DB debe implementar
  getBasicFields(): FormField[];
  getAuthenticationFields(): FormField[];
  getAdvancedFields(): FieldGroup[];
  buildDockerArgs(config: any): DockerRunArgs;
  getConnectionString(container: Container): string;
  validateConfig(config: any): ValidationResult;
}

This interface defines what each database should provide without specifying how. This is the essence of the Provider pattern: separating the "what" from the "how".

Step 2: Implement Concrete Providers

Each database implements the DatabaseProvider interface with its specific logic. This is where the Provider pattern shines: the specific logic is encapsulated, not scattered:

MySQL Provider: all its logic in a single file

export class MySQLDatabaseProvider implements DatabaseProvider {
  readonly id = 'MySQL';
  readonly name = 'MySQL';
  readonly icon = <SiMysql />;
  readonly defaultPort = 3306;
  readonly dataPath = '/var/lib/mysql';
  readonly versions = ['9.4.0', '9.4', '8.4.6', '8.4', '8.0'];

  getBasicFields(): FormField[] {
    return [
      {
        name: 'name',
        label: 'Container Name',
        type: 'text',
        required: true,
        validation: { min: 3 },
      },
      {
        name: 'port',
        label: 'Port',
        type: 'number',
        defaultValue: 3306,
        required: true,
      },
      {
        name: 'version',
        label: 'MySQL Version',
        type: 'select',
        options: this.versions,
        defaultValue: this.versions[0],
      },
    ];
  }

  getAuthenticationFields(): FormField[] {
    return [
      {
        name: 'username',
        label: 'Root Username',
        type: 'text',
        defaultValue: 'root',
        readonly: true,
      },
      {
        name: 'password',
        label: 'Root Password',
        type: 'password',
        required: true,
        validation: { min: 4 },
      },
    ];
  }

  getAdvancedFields(): FieldGroup[] {
    return [
      {
        label: 'Character Set & Collation',
        fields: [
          {
            name: 'mysqlSettings.characterSet',
            type: 'select',
            options: ['utf8mb4', 'utf8', 'latin1'],
            defaultValue: 'utf8mb4',
          },
        ],
      },
    ];
  }

  buildDockerArgs(config: any): DockerRunArgs {
    const command: string[] = [];

    if (config.mysqlSettings?.characterSet) {
      command.push(`--character-set-server=${config.mysqlSettings.characterSet}`);
    }

    return {
      image: `mysql:${config.version}`,
      envVars: { MYSQL_ROOT_PASSWORD: config.password },
      ports: [{ host: config.port, container: 3306 }],
      volumes: config.persistData 
        ? [{ name: `${config.name}-data`, path: this.dataPath }] 
        : [],
      command,
    };
  }

  getConnectionString(container: Container): string {
    return `mysql://root:${container.password}@localhost:${container.port}`;
  }

  validateConfig(config: any): ValidationResult {
    const errors: string[] = [];
    if (!config.password || config.password.length < 4) {
      errors.push('Password must be at least 4 characters');
    }
    return { valid: errors.length === 0, errors };
  }
}

All MySQL logic in ~200 lines. No ifs, no switches, no repeated code. This is the Provider pattern in action: each implementation is autonomous and fulfills the contract defined by the interface.

Step 3: The Centralized Registry

To complete the Provider pattern, we need a registry that manages all available providers. This registry acts as a single point of access:

class DatabaseRegistry {
  private providers = new Map<string, DatabaseProvider>();

  get(id: string): DatabaseProvider | undefined {
    return this.providers.get(id);
  }

  getAll(): DatabaseProvider[] {
    return Array.from(this.providers.values());
  }
}

export const databaseRegistry = new DatabaseRegistry([
  new PostgresDatabaseProvider(),
  new MySQLDatabaseProvider(),
  new MariaDBDatabaseProvider(),
  new RedisDatabaseProvider(),
  new MongoDBDatabaseProvider(),
  new SQLServerDatabaseProvider(),
  new InfluxDBDatabaseProvider(),
  new ElasticsearchDatabaseProvider(),
]);

Step 4: Consume the Providers

With the Provider pattern implemented, the code that consumes these providers becomes extremely simple and generic. It doesn't need to know anything about specific databases:

Completely Dynamic Forms

The forms went from 561 lines with conditionals to this:

export function ContainerConfigurationStep() {
  const provider = databaseRegistry.get(selectedDatabase);
  const basicFields = provider.getBasicFields();
  const authFields = provider.getAuthenticationFields();

  return (
    <div>
      <Section title="Basic Configuration">
        {basicFields.map(field => (
          <DynamicFormField 
            key={field.name} 
            field={field}
            value={formData[field.name]}
            onChange={(value) => updateField(field.name, value)}
          />
        ))}
      </Section>

      <Section title="Authentication">
        {authFields.map(field => (
          <DynamicFormField key={field.name} field={field} />
        ))}
      </Section>
    </div>
  );
}

Notice something? Zero conditionals. Zero specific logic. The provider provides the fields, and the form simply renders them. This is the power of the Provider pattern.

Simplified Rust Backend

The backend no longer needs to know about any specific database. All the intelligence is delegated to the providers in the frontend:

#[tauri::command]
pub async fn create_container_from_docker_args(
    request: DockerRunRequest,
    app: AppHandle,
) -> Result<DatabaseContainer, String> {
    let docker_service = DockerService::new();

    // Crear volúmenes
    for volume in &request.docker_args.volumes {
        docker_service.create_volume_if_needed(&app, &volume.name).await?;
    }

    // Construir comando Docker (genérico para todas las DBs)
    let docker_args = docker_service
        .build_docker_command_from_args(&request.name, &request.docker_args);

    // Ejecutar
    let container_id = docker_service.run_container(&app, &docker_args).await?;

    Ok(database)
}

The build_docker_command_from_args method is completely generic. The provider already built all the arguments in the frontend.

Benefits of the Provider Pattern

1. Extensibility Without Modifying Existing Code

The Open/Closed principle (open for extension, closed for modification) of SOLID is perfectly fulfilled. Adding a new database doesn't require touching existing code:

2. Separation of Concerns

Each provider is responsible for:

Its own configuration
Its own form fields
Its own Docker logic
Its own validation

The consuming code only needs to know that a provider exists, not how it works internally.

3. Simplified Testing

Each provider has its own tests, isolated and easy to maintain:

describe('MySQLDatabaseProvider', () => {
  const provider = new MySQLDatabaseProvider();

  it('should build correct docker args', () => {
    const config = {
      name: 'test-mysql',
      port: 3306,
      version: '8.0',
      password: 'secret123',
    };

    const args = provider.buildDockerArgs(config);

    expect(args.image).toBe('mysql:8.0');
    expect(args.envVars.MYSQL_ROOT_PASSWORD).toBe('secret123');
  });
});

Conclusion

The Provider pattern completely transformed Docker DB Manager's architecture. What previously required changes in 19 different files is now solved by creating a single file that implements the interface.

This pattern is especially powerful when you have multiple implementations of the same functionality. Whether it's databases, authentication providers, payment processors, or any interchangeable component, the Provider pattern allows you to scale without accumulating technical debt.

If your project requires changes in multiple places to add a feature, you probably need to identify the right pattern. Not because the code is "bad," but because a better abstraction can transform hours of work into minutes.

Want to see the code or contribute?

📦 Repository: github.com/AbianS/docker-db-manager
🔍 Refactor Pr: PR
⭐ Give it a star if you find it useful

Docker DB Manager is free, open source, and currently available for macOS (Windows and Linux in development).

Have you applied the Provider pattern in your projects? Have questions about software architecture? Leave me a comment!

Haz que tu app crezca sin dolor: Así escapé del código repetido gracias al patrón Provider

AbianS — Thu, 16 Oct 2025 15:38:30 +0000

Hace unos dias escribí sobre Docker DB Manager, una aplicación de escritorio que simplifica la gestión de contenedores de bases de datos en Docker.

Pero había un problema: cada vez que añadía soporte para una nueva base de datos, tenía que escribir código duplicado en Rust y TypeScript. Era tedioso, propenso a errores y frustrante.

Hoy te cuento cómo transformé completamente la arquitectura usando el patrón Provider, convirtiendo la adición de nuevas bases de datos en algo tan simple como escribir una clase TypeScript.

¿Qué es el patrón Provider?

El patrón Provider es un patrón de diseño que permite delegar la responsabilidad de proporcionar funcionalidad específica a componentes intercambiables. En lugar de tener lógica centralizada con condicionales para cada caso, cada proveedor (provider) implementa una interfaz común y se encarga de su propia configuración y comportamiento.

La idea central: En vez de preguntar "¿qué tipo eres?" y actuar en consecuencia, le preguntamos al objeto: "¿qué necesitas?" y él nos lo proporciona.

Este patrón es especialmente útil cuando:

Tienes múltiples implementaciones de una misma funcionalidad
Cada implementación tiene su propia lógica específica
Quieres añadir nuevas implementaciones sin modificar código existente
Necesitas mantener el código desacoplado y escalable

El problema: código duplicado por todas partes

Backend en Rust con lógica específica

En docker.rs tenía un método gigante con un match statement para cada base de datos:

pub fn build_docker_command(
    &self,
    request: &CreateDatabaseRequest,
    volume_name: &Option<String>,
) -> Result<Vec<String>, String> {
    let mut args = vec![
        "run".to_string(),
        "-d".to_string(),
        "--name".to_string(),
        request.name.clone(),
        "-p".to_string(),
        format!("{}:{}", request.port, self.get_default_port(&request.db_type)),
    ];

    // Añadir volumen si persist_data es true
    if let Some(vol_name) = volume_name {
        args.push("-v".to_string());
        args.push(format!("{}:{}", vol_name, self.get_data_path(&request.db_type)));
    }

    // Variables de entorno según el tipo de base de datos
    match request.db_type.as_str() {
        "PostgreSQL" => {
            args.push("-e".to_string());
            args.push(format!("POSTGRES_PASSWORD={}", request.password));

            if let Some(username) = &request.username {
                if username != "postgres" {
                    args.push("-e".to_string());
                    args.push(format!("POSTGRES_USER={}", username));
                }
            }
            // ... más configuración específica de PostgreSQL
        }
        "MySQL" => {
            args.push("-e".to_string());
            args.push(format!("MYSQL_ROOT_PASSWORD={}", request.password));
            // ... más configuración específica de MySQL
        }
        "MongoDB" => {
            // ... configuración específica de MongoDB
        }
        "Redis" => {
            // ... configuración específica de Redis
        }
        // ... más casos para cada base de datos
        _ => return Err(format!("Database type not supported: {}", request.db_type)),
    }

    Ok(args)
}

Frontend con condicionales infinitos

// En container-configuration-step.tsx (¡561 líneas!)
function ContainerConfigurationStep() {
  // Campos diferentes según el tipo de base de datos
  if (selectedDatabase === 'PostgreSQL') {
    return (
      <div>
        <Input label="Username" defaultValue="postgres" />
        <Input label="Password" type="password" />
        <Select label="Host Auth Method">
          <option>md5</option>
          <option>scram-sha-256</option>
        </Select>
        {/* ... 100 líneas más de configuración específica */}
      </div>
    )
  }

  if (selectedDatabase === 'MySQL') {
    return (
      <div>
        <Input label="Root Password" type="password" />
        <Select label="Character Set">
          <option>utf8mb4</option>
          <option>utf8</option>
        </Select>
        {/* ... otra configuración específica */}
      </div>
    )
  }

  // ... más ifs para MongoDB, Redis, etc.
}

El costo real

Añadir MariaDB significaba tocar un montón de archivos. Cada cambio requería modificar tanto Rust como TypeScript, mantener tipos sincronizados y probar todo manualmente.

La solución: aplicar el patrón Provider

La transformación clave: En lugar de tener lógica centralizada que conoce todas las bases de datos, cada base de datos se convierte en un provider que se describe a sí mismo.

Esto es exactamente el patrón Provider en acción. Veamos cómo:

Paso 1: Definir el contrato con una interfaz

El primer paso es crear una interfaz que todos los providers deben cumplir. Esta interfaz es el contrato que garantiza que cada base de datos puede proporcionar toda la información necesaria:

export interface DatabaseProvider {
  // Identificación
  readonly id: string;
  readonly name: string;
  readonly icon: ReactNode;
  readonly color: string;

  // Configuración Docker
  readonly defaultPort: number;
  readonly dataPath: string;
  readonly versions: string[];

  // Métodos que cada DB debe implementar
  getBasicFields(): FormField[];
  getAuthenticationFields(): FormField[];
  getAdvancedFields(): FieldGroup[];
  buildDockerArgs(config: any): DockerRunArgs;
  getConnectionString(container: Container): string;
  validateConfig(config: any): ValidationResult;
}

Esta interfaz define qué debe proporcionar cada base de datos sin especificar cómo. Esto es la esencia del patrón Provider: separar el "qué" del "cómo".

Paso 2: Implementar providers concretos

Cada base de datos implementa la interfaz DatabaseProvider con su lógica específica. Aquí es donde el patrón Provider brilla: la lógica específica está encapsulada, no dispersa:

MySQL Provider: toda su lógica en un solo archivo

export class MySQLDatabaseProvider implements DatabaseProvider {
  readonly id = 'MySQL';
  readonly name = 'MySQL';
  readonly icon = <SiMysql />;
  readonly defaultPort = 3306;
  readonly dataPath = '/var/lib/mysql';
  readonly versions = ['9.4.0', '9.4', '8.4.6', '8.4', '8.0'];

  getBasicFields(): FormField[] {
    return [
      {
        name: 'name',
        label: 'Container Name',
        type: 'text',
        required: true,
        validation: { min: 3 },
      },
      {
        name: 'port',
        label: 'Port',
        type: 'number',
        defaultValue: 3306,
        required: true,
      },
      {
        name: 'version',
        label: 'MySQL Version',
        type: 'select',
        options: this.versions,
        defaultValue: this.versions[0],
      },
    ];
  }

  getAuthenticationFields(): FormField[] {
    return [
      {
        name: 'username',
        label: 'Root Username',
        type: 'text',
        defaultValue: 'root',
        readonly: true,
      },
      {
        name: 'password',
        label: 'Root Password',
        type: 'password',
        required: true,
        validation: { min: 4 },
      },
    ];
  }

  getAdvancedFields(): FieldGroup[] {
    return [
      {
        label: 'Character Set & Collation',
        fields: [
          {
            name: 'mysqlSettings.characterSet',
            type: 'select',
            options: ['utf8mb4', 'utf8', 'latin1'],
            defaultValue: 'utf8mb4',
          },
        ],
      },
    ];
  }

  buildDockerArgs(config: any): DockerRunArgs {
    const command: string[] = [];

    if (config.mysqlSettings?.characterSet) {
      command.push(`--character-set-server=${config.mysqlSettings.characterSet}`);
    }

    return {
      image: `mysql:${config.version}`,
      envVars: { MYSQL_ROOT_PASSWORD: config.password },
      ports: [{ host: config.port, container: 3306 }],
      volumes: config.persistData 
        ? [{ name: `${config.name}-data`, path: this.dataPath }] 
        : [],
      command,
    };
  }

  getConnectionString(container: Container): string {
    return `mysql://root:${container.password}@localhost:${container.port}`;
  }

  validateConfig(config: any): ValidationResult {
    const errors: string[] = [];
    if (!config.password || config.password.length < 4) {
      errors.push('Password must be at least 4 characters');
    }
    return { valid: errors.length === 0, errors };
  }
}

Toda la lógica de MySQL en ~200 líneas. Sin ifs, sin switches, sin código repetido. Esto es el patrón Provider en acción: cada implementación es autónoma y cumple el contrato definido por la interfaz.

Paso 3: El registro centralizado

Para completar el patrón Provider, necesitamos un registro que gestione todos los providers disponibles. Este registro actúa como punto de acceso único:

class DatabaseRegistry {
  private providers = new Map<string, DatabaseProvider>();

  get(id: string): DatabaseProvider | undefined {
    return this.providers.get(id);
  }

  getAll(): DatabaseProvider[] {
    return Array.from(this.providers.values());
  }
}

export const databaseRegistry = new DatabaseRegistry([
  new PostgresDatabaseProvider(),
  new MySQLDatabaseProvider(),
  new MariaDBDatabaseProvider(),
  new RedisDatabaseProvider(),
  new MongoDBDatabaseProvider(),
  new SQLServerDatabaseProvider(),
  new InfluxDBDatabaseProvider(),
  new ElasticsearchDatabaseProvider(),
]);

Paso 4: Consumir los providers

Con el patrón Provider implementado, el código que consume estos providers se vuelve extremadamente simple y genérico. No necesita conocer nada sobre bases de datos específicas:

Formularios completamente dinámicos

Los formularios pasaron de 561 líneas con condicionales a esto:

export function ContainerConfigurationStep() {
  const provider = databaseRegistry.get(selectedDatabase);
  const basicFields = provider.getBasicFields();
  const authFields = provider.getAuthenticationFields();

  return (
    <div>
      <Section title="Basic Configuration">
        {basicFields.map(field => (
          <DynamicFormField 
            key={field.name} 
            field={field}
            value={formData[field.name]}
            onChange={(value) => updateField(field.name, value)}
          />
        ))}
      </Section>

      <Section title="Authentication">
        {authFields.map(field => (
          <DynamicFormField key={field.name} field={field} />
        ))}
      </Section>
    </div>
  );
}

¿Notas algo? Cero condicionales. Cero lógica específica. El provider proporciona los campos, y el formulario simplemente los renderiza. Esto es el poder del patrón Provider.

Backend Rust simplificado

El backend ya no necesita conocer ninguna base de datos específica. Toda la inteligencia está delegada a los providers en el frontend:

#[tauri::command]
pub async fn create_container_from_docker_args(
    request: DockerRunRequest,
    app: AppHandle,
) -> Result<DatabaseContainer, String> {
    let docker_service = DockerService::new();

    // Crear volúmenes
    for volume in &request.docker_args.volumes {
        docker_service.create_volume_if_needed(&app, &volume.name).await?;
    }

    // Construir comando Docker (genérico para todas las DBs)
    let docker_args = docker_service
        .build_docker_command_from_args(&request.name, &request.docker_args);

    // Ejecutar
    let container_id = docker_service.run_container(&app, &docker_args).await?;

    Ok(database)
}

El método build_docker_command_from_args es completamente genérico. El provider ya construyó todos los argumentos en el frontend.

Los beneficios del patrón Provider

1. Extensibilidad sin modificar código existente

El principio Open/Closed (abierto para extensión, cerrado para modificación) del SOLID se cumple perfectamente. Añadir una nueva base de datos no requiere tocar código existente:

Ejemplo real: Elasticsearch

Para probar el sistema, añadí soporte para Elasticsearch. Todo en un solo commit:

commit 344b475
feat: add Elasticsearch provider and update database registry with tests

Solo tuve que:

Crear elasticsearch.provider.tsx (~200 líneas)
Añadirlo al registro (1 línea)
Escribir tests

Tiempo total: 35 minutos. Sin tocar Rust, sin modificar formularios, sin actualizar tipos.

2. Separación de responsabilidades

Cada provider es responsable de:

Su propia configuración
Sus propios campos de formulario
Su propia lógica Docker
Su propia validación

El código consumidor solo necesita saber que existe un provider, no cómo funciona internamente.

3. Testing simplificado

Cada provider tiene sus propios tests, aislados y fáciles de mantener:

describe('MySQLDatabaseProvider', () => {
  const provider = new MySQLDatabaseProvider();

  it('should build correct docker args', () => {
    const config = {
      name: 'test-mysql',
      port: 3306,
      version: '8.0',
      password: 'secret123',
    };

    const args = provider.buildDockerArgs(config);

    expect(args.image).toBe('mysql:8.0');
    expect(args.envVars.MYSQL_ROOT_PASSWORD).toBe('secret123');
  });
});

Conclusión

El patrón Provider transformó completamente la arquitectura de Docker DB Manager. Lo que antes requería cambios en 19 archivos diferentes ahora se resuelve creando un solo archivo que implementa la interfaz.

Este patrón es especialmente poderoso cuando tienes múltiples implementaciones de una misma funcionalidad. Ya sea bases de datos, proveedores de autenticación, procesadores de pagos o cualquier componente intercambiable, el patrón Provider te permite escalar sin acumular deuda técnica.

Si tu proyecto requiere cambios en múltiples lugares para añadir una feature, probablemente necesitas identificar el patrón correcto. No porque el código esté "mal", sino porque una mejor abstracción puede transformar horas de trabajo en minutos.

¿Quieres ver el código o contribuir?

📦 Repositorio: github.com/AbianS/docker-db-manager
🔍 pr del refactor: PR
⭐ Dale una estrella si te resulta útil

Docker DB Manager es gratuito, open source y actualmente disponible para macOS (Windows y Linux proximamente).

¿Has aplicado el patrón Provider en tus proyectos? ¿Tienes preguntas sobre arquitectura de software? ¡Déjame un comentario!

Managing multiple databases in Docker without having 50 commands saved in Notion

AbianS — Mon, 06 Oct 2025 16:40:46 +0000

Spinning up a database with Docker sounds simple… until you’ve done it five times.

Every new project starts the same: you Google "docker run postgres", copy a command, tweak it a bit, run it… and everything’s fine—until you need another database. Then chaos begins.

By default Docker uses the same port for each database type — 5432 for Postgres, 3306 for MySQL, 6379 for Redis — so when you try to run a second instance you get the classic error: Error: port 5432 already in use.

Quick fix: change the port. Fine, but then each DB ends up on a different port: 5432, 5433, 5434, 5435… Now you have five projects, five databases, five ports, and half your time is spent hunting in Docker Desktop to find which container belongs to which project.

Worse still: once a container is created, changing its port isn’t trivial. You typically have to stop it, remove it, recreate it with the new configuration, update the .env, and hope you didn’t lose data because you forgot to mount a volume. It’s manual, delicate work—so many people just leave the mess as-is rather than rebuild everything.

The real problem

Each DB needs its own port: you can change ports, but then you end up with an unruly list that’s hard to track.
Hard to maintain: Docker Desktop turns into a guessing game to match containers with projects.
Changing configuration is painful: moving a port or renaming a DB means deleting and recreating it, with a real risk of data loss.
Scattered configuration: commands in Notion, passwords in .env, and ports only in your head.

Docker DB Manager — order and control without opening the terminal 😌

Docker DB Manager was born from that frustration: an app that lets you create, manage and modify Docker databases without memorizing a single command.

Create databases in seconds: choose the engine (Postgres, MySQL, Redis or MongoDB), give it a name and password, and you’re done. (And this is just the beginning — more database engines will be added in future updates.)
Connection strings ready to copy: get your DATABASE_URL without searching or typing anything.

postgresql://admin:tu-password@localhost:5433/mydb

Edit without manual rebuilds: change name or port from the UI; the app handles the adjustments and keeps your data.
Persistent storage made easy: toggle “persist data” and the app will create and manage the volume for you.
Synchronized with Docker Desktop: changes made in Docker Desktop are reflected in the app and vice versa.
Everything centralized: a clear view with all your databases, ports and states — no guessing needed.

Built with Tauri (lightweight and fast), React + TypeScript on the frontend and Rust on the backend to run Docker commands safely and efficiently.

Available now for macOS (Intel and Apple Silicon).
Windows and Linux coming soon.

📦 Open source — download and source code on GitHub:
👉 github.com/AbianS/docker-db-manager

If you have more databases than open tabs in your browser, this app will give you back some calm (and a few saved minutes).

Gestionar múltiples bases de datos en Docker sin tener 50 comandos guardados en Notion

AbianS — Mon, 06 Oct 2025 16:36:07 +0000

Levantar una base de datos con Docker parece sencillo… hasta que lo haces por quinta vez.

Cada nuevo proyecto empieza igual: buscas en Google "docker run postgres", copias un comando, lo ajustas un poco, lo ejecutas… y todo va bien hasta que necesitas otra base de datos. Entonces empieza el caos.

Docker, por defecto, usa el mismo puerto para cada tipo de base de datos - 5432 para Postgres, 3306 para MySQL, 6379 para Redis - . Así que cuando intentas correr una segunda instancia, te salta el clásico error: Error: port 5432 already in use.

Solución rápida: cambiar el puerto. Pero claro, cada base acaba en un puerto distinto: 5432, 5433, 5434, 5435… Ahora tienes cinco proyectos, cinco bases, cinco puertos, y la mitad del tiempo lo pierdes buscando en Docker Desktop cuál corresponde a cuál.

Y lo peor llega después: una vez creada, cambiar el puerto de un contenedor no es trivial. Tienes que detenerlo, borrarlo, volver a crear otro con la nueva configuración, actualizar el .env, y esperar no haber perdido datos si olvidaste montar un volumen. Es un proceso tan manual y delicado que muchos prefieren dejar todo como está -aunque su entorno sea un caos- solo por no tener que rehacerlo.

El verdadero problema

Cada base necesita su puerto: puedes cambiarlos, sí, pero acabas con una lista de comandos imposible de recordar.
Difícil de mantener: abrir Docker Desktop se convierte en un juego de adivinanzas para saber qué proyecto usa qué contenedor.
Cambiar configuración es doloroso: mover un puerto o renombrar una DB implica borrarla y recrearla, con riesgo de perder datos.
Configuraciones dispersas: comandos guardados en Notion, contraseñas en .env y puertos solo en tu cabeza.

Docker DB Manager - orden y control sin abrir la terminal 😌

Docker DB Manager nace de esa frustración: una app que te permite crear, gestionar y modificar bases de datos Docker sin memorizar ni un solo comando.

Crea bases de datos en segundos: elige el motor (Postgres, MySQL, Redis o MongoDB), ponle nombre y contraseña, y listo. (Y esto es solo el comienzo - más bases de datos llegarán con cada actualización.)
Connection strings listas para copiar: obtén tu DATABASE_URL sin buscar ni escribir nada.

postgresql://admin:tu-password@localhost:5433/mydb

Edita sin reconstruir a mano: cambia nombre o puerto desde la interfaz; la app se encarga de hacer los ajustes y mantener los datos.
Sincronizada con Docker Desktop: cualquier cambio se refleja automáticamente.
Todo centralizado: una vista clara con todas tus bases, puertos y estados, sin tener que adivinar.

Construida con Tauri (ligera y rápida), React + TypeScript en el frontend y Rust en el backend para ejecutar comandos Docker de forma segura.

Disponible ahora para macOS (Intel y Apple Silicon). Windows y Linux próximamente.

📦 Código abierto y descarga en GitHub:
👉 github.com/AbianS/docker-db-manager

Si tienes más bases de datos que pestañas abiertas en tu navegador, esta app te devolverá la calma (y unos cuantos minutos de vida).