Arquitectura sin boilerplate: Cuando la base de datos se convierte en API gateway y la IA en interfaz de usuario

Cómo eliminar toda la capa backend con PgArachne y MCP, distribuir el sistema desde un único binario y dejar que los agentes de IA funcionen como interfaz de usuario.

En la ingeniería de software existe una tendencia arraigada hacia el apilamiento de abstracciones. Cuando hoy construimos una aplicación web típica, el stack tecnológico habitual incluye una base de datos relacional, una capa ORM (Object-Relational Mapping), un framework de backend (Node.js, Python, Go, .NET), bibliotecas de validación, serializadores al formato JSON y, finalmente, el servidor HTTP que expone estos datos a la red.

Como resultado, los desarrolladores de backend pasan una cantidad enorme de tiempo escribiendo el llamado código «boilerplate» — traduciendo mecánicamente estructuras de base de datos a rutas HTTP y validando lo que muchas veces ya está validado a nivel de base de datos.

Pero si la lógica de negocio de la aplicación está estrechamente ligada al modelo de datos y a la integridad de los mismos, surge una pregunta legítima: ¿Realmente necesitamos una aplicación backend separada que actúe únicamente como calentador de paso para JSON?

El enfoque «base de datos como backend» (Database-as-a-Backend) no es conceptualmente nuevo. Sin embargo, en combinación con la herramienta PgArachne y el nuevo estándar Model Context Protocol (MCP), adquiere una dimensión arquitectónica completamente nueva. Este texto analiza en detalle cómo con este stack se puede eliminar toda una capa de aplicaciones, distribuir un sistema completo desde un único binario y permitir que los agentes de IA funcionen como la propia interfaz de usuario.

1. El cambio arquitectónico: De los controladores a la lógica pura de base de datos

Una API REST tradicional requiere, para cada entidad, la definición de una ruta, un controlador, middleware de validación, manejo de errores y un mapeo a una consulta SQL. Si cambia la estructura de una tabla o una regla de negocio, el desarrollador debe modificar el código en varios puntos del backend y, posteriormente, también en el frontend.

PgArachne elimina por completo esta capa intermedia. El desarrollo de backend se reduce aquí a la definición del esquema de base de datos y de funciones PL/pgSQL (o PL/v8 o PL/Python). La herramienta en sí funciona como una API gateway delgada y de alto rendimiento, escrita en Go, que se ejecuta directamente frente a PostgreSQL y mapea automáticamente los procedimientos y funciones almacenados a una API JSON-RPC 2.0.

Cómo funciona la reflexión en la práctica

En cuanto existe en la base de datos una función que acepta y devuelve el tipo de dato jsonb, PgArachne la registra y expone de inmediato mediante reflexión de los catálogos del sistema de PostgreSQL (pg_proc, pg_namespace, pg_argument). Sin reinicios de servidor, sin compilaciones.

Imaginemos una función sencilla para el registro de un usuario:

CREATE OR REPLACE FUNCTION api.register_user(params jsonb)
RETURNS jsonb AS $$
DECLARE
   new_user_id uuid;
   user_email text;
BEGIN
   user_email := lower(trim(params->>'email'));

  -- Validace přímo v databázi
   IF user_email !~* '^[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}$'
   THEN
      RAISE EXCEPTION 'Invalid email address' USING ERRCODE = '22000';
   END IF;

   INSERT INTO users (email, password_hash)
   VALUES (user_email, crypt(params->>'password', gen_salt('bf')))
   RETURNING id INTO new_user_id;

   RETURN jsonb_build_object(
      'status', 'success',
      'user_id', new_user_id
   );
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

COMMENT ON FUNCTION api.register_user(jsonb) IS 'Registers a new user and returns the user ID. Expects email and password fields.';

PgArachne mapea esta función automáticamente a un endpoint JSON-RPC. La aplicación cliente (o un agente de IA) envía entonces una petición POST estándar con el cuerpo:

{
   "jsonrpc": "2.0",
   "method": "api.register_user",
   "params": {
      "email": "[email protected]",
      "password": "SuperSecretPassword123"
   },
   "id": 1
}

Enfoque híbrido: Del CRUD universal a la lógica estricta

Este modelo a menudo tropieza con el temor a una rigidez excesiva. ¿Qué pasa si al inicio del proyecto no quiero escribir una función SQL para cada tabla? ¿Y si más adelante necesito validaciones extremadamente complejas? PgArachne admite una estrategia híbrida:

  1. Funciones universales (MVP rápido): Al inicio del proyecto se pueden habilitar funciones CRUD genéricas que permiten a la aplicación cliente consultar, filtrar y modificar tablas directamente (de forma similar a lo que hace PostgREST). El desarrollo del frontend puede arrancar de inmediato.
  2. Funciones RPC dedicadas (Hardening de producción): A medida que el proyecto crece y requiere procesos de negocio estrictos (p. ej., el procesamiento transaccional de un pedido vinculado al estado del almacén), el acceso universal se cierra para esa entidad y se reemplaza por una función SQL aislada. Para la aplicación cliente nada cambia externamente — sigue comunicándose con el protocolo JSON-RPC.

2. El modelo de seguridad: Cambio de identidad mediante SET LOCAL ROLE

Una de las objeciones más frecuentes a la arquitectura «base de datos como backend» es la cuestión de la seguridad. Si la aplicación cliente se comunica directamente con la gateway de base de datos, ¿cómo evitar que el usuario A lea los datos del usuario B?

PgArachne no gestiona la autorización ni los permisos de acceso por su cuenta. En su lugar, delega la seguridad al cien por cien en el núcleo probado de PostgreSQL y en el mecanismo Row-Level Security (RLS).

Cómo funciona en la base de datos:

  1. Autenticación (BYO-JWT): PgArachne admite el modelo Bring Your Own JWT. Se puede utilizar cualquier proveedor de identidad externo (Auth0, Clerk, Supabase Auth o un microservicio propio) que firme los tokens. A la gateway se le facilita únicamente la clave pública (JWKS) para verificar la firma.
  2. Contexto de la petición: Cuando llega una petición HTTP, PgArachne verifica el JWT, extrae de él los claims (p. ej., el ID de usuario y su rol) y abre una transacción hacia PostgreSQL.
  3. Aislamiento a nivel de transacción: Al inicio mismo de la transacción, la gateway ejecuta una serie de comandos de configuración del contexto:
  SET LOCAL ROLE authenticated;
  SELECT set_config('app.current_user_id', '123e4567-e89b-12d3-a456-426614174000', true);
  1. Aplicación de las reglas RLS: Si se tiene definida una política RLS sobre la tabla orders, PostgreSQL garantiza automáticamente que cualquier consulta posterior (incluso anidada dentro de una función compleja) vea únicamente los datos pertenecientes a ese usuario:
  CREATE POLICY order_isolation_policy ON orders
  FOR ALL
  TO authenticated
  USING (user_id = current_setting('app.current_user_id')::uuid);

Gracias a este enfoque se elimina por completo toda una clase de vulnerabilidades de seguridad del tipo IDOR (Insecure Direct Object Reference), que habitualmente surgen por errores del desarrollador en los controladores de backend. La seguridad se define de forma declarativa directamente junto a los datos.

3. Distribución desde un único binario: Frontend estático y JAMstack sin compromisos

El despliegue moderno a menudo parece una pesadilla de infraestructura. Hay que gestionar contenedores Docker para el backend en Node.js, configurar una CDN (Content Delivery Network) para distribuir la Single Page Application (React/Vue/Svelte), resolver las políticas CORS (Cross-Origin Resource Sharing) y configurar un proxy inverso (Nginx/Traefik) que una todo.

PgArachne aborda esto con la pragmática sencillez del lenguaje Go. Incorpora un servidor de archivos estáticos integrado y altamente optimizado. Esto permite cambiar por completo la estrategia de despliegue de la aplicación.

Distribución monolítica con las ventajas de los microservicios

Toda la aplicación cliente puede construirse como un frontend completamente estático — sin server-side rendering (SSR), únicamente HTML, CSS y JavaScript de cliente optimizados. Estos archivos se cargan en una carpeta que PgArachne sirve.

Las ventajas de este enfoque son fundamentales:

Comunicación en tiempo real sin la complejidad de los WebSockets

Si la aplicación cliente requiere datos en vivo — como notificaciones en tiempo real, actualizaciones de stock o chat — los desarrolladores suelen recurrir a WebSockets. Sin embargo, estos son costosos en recursos, escalan mal a través de load balancers y requieren lógica de estado compleja en el backend.

PgArachne resuelve este problema con soporte nativo para Server-Sent Events (SSE) combinado con el mecanismo de base de datos LISTEN/NOTIFY.

Cuando ocurre un cambio en la base de datos (p. ej., mediante un trigger), PostgreSQL lanza un evento:

NOTIFY channel_orders_updates, '{"order_id": 501, "status": "shipped"}';

PgArachne captura esa notificación y la reenvía inmediatamente a través de la conexión HTTP abierta hacia el frontend mediante la interfaz de cliente estándar EventSource de JavaScript:

const evtSource = new EventSource("/api/stream?channel=orders_updates");
evtSource.onmessage = (event) => {
   const data = JSON.parse(event.data);
   console.log("Objednávka aktualizována:", data);
};

Todo funciona de forma unidireccional, eficiente, a través del protocolo HTTP estándar y sin necesidad de implementar brokers de mensajería dedicados como Redis.

4. Model Context Protocol (MCP): La era de las aplicaciones sin interfaz gráfica (Zero-UI)

El cambio tecnológico más interesante que aporta PgArachne no tiene que ver, sin embargo, con el ahorro de líneas de código en el desarrollo web clásico, sino con la integración con el ecosistema de inteligencia artificial a través del Model Context Protocol (MCP).

MCP es un protocolo abierto (originalmente diseñado por Anthropic) que define una forma uniforme en que los modelos LLM (como Claude, GPT o modelos locales) pueden comunicarse de forma segura con fuentes de datos externas, sistemas de archivos e interfaces de aplicaciones. PgArachne incluye una implementación nativa de servidor MCP.

Una API autodocumentada como conjunto de herramientas (Tools)

Cuando se conecta PgArachne con un entorno de desarrollo (p. ej., Cursor, Claude Desktop o un agente autónomo propio), la gateway realiza la introspección de las funciones SQL disponibles y las presenta al modelo de IA como sus herramientas internas (tools).

El elemento clave son los comentarios SQL estándar. Los modelos de IA no necesitan leer el código fuente de las tablas; necesitan una semántica comprensible. PgArachne toma el texto del comando COMMENT ON FUNCTION y lo transmite al LLM como instrucción de sistema para esa herramienta.

Si el modelo recibe la tarea de averiguar el estado del negocio, examina el esquema de herramientas y encuentra una función con la descripción: «Devuelve el volumen de negocio total y el número de pedidos para el período especificado.» El modelo entiende por sí mismo qué parámetros (date_from, date_to) debe generar, construye una petición JSON-RPC válida, PgArachne la ejecuta de forma segura y el modelo interpreta los datos brutos para el usuario en texto comprensible o en un gráfico.

El concepto Zero-UI: Cuando la interfaz gráfica nunca llega a crearse

En una gran cantidad de sistemas empresariales internos, herramientas analíticas, interfaces B2 B o consolas de administración, la creación de una interfaz gráfica de usuario (GUI) es puro despilfarro de tiempo de ingeniería. Los desarrolladores pasan semanas creando tablas, filtros, selectores y gráficos solo para que un directivo o analista pueda exportar datos con un clic.

Con la arquitectura PgArachne + MCP se abre el camino hacia el llamado Zero-UI (interfaz cero):

  1. Sin código frontend: No se crea ningún React, ningún formulario, ningún CSS.
  2. Lenguaje natural como interfaz universal: El usuario se comunica directamente con el agente de IA (p. ej., a través de chat o una interfaz de voz).
  3. Ejecución autónoma: El usuario introduce: «Encuéntrame los 5 principales clientes que más dinero han gastado con nosotros este mes, pero cuyo último pedido fue hace más de 10 días. Quiero enviarles un email de retención.»
  4. Procesamiento: El agente de IA identifica las funciones necesarias expuestas a través de PgArachne, extrae los datos exactos de forma transaccional y segura (a través de RLS), los formatea en una tabla clara y directamente propone los textos de los correos.

La lógica de negocio y la integridad permanecen al cien por cien bajo control en PostgreSQL, la transmisión de datos la garantiza el velocísimo servidor en Go y la capa de usuario flexible la genera la IA dinámicamente según la necesidad actual del usuario.

5. Cuándo (no) desplegar esta arquitectura: Límites y riesgos

Toda decisión arquitectónica es un compromiso (trade-off). La arquitectura «base de datos como backend» no es una bala de plata y tiene límites específicos que deben evaluarse antes del despliegue.

Escenarios adecuados (Sweet Spots)

Escenarios inadecuados (Cuándo preferir un backend clásico)

Conclusión: Austeridad pragmática para la era moderna

La arquitectura construida sobre la combinación de PostgreSQL, PgArachne y Model Context Protocol representa un retorno radical a la sobriedad técnica. Demuestra que gran parte de la complejidad que introducimos en los proyectos de software modernos está causada únicamente por el empeño en transferir y transformar continuamente datos entre capas incompatibles.

Al eliminar las capas intermedias — es decir, al suprimir la aplicación backend clásica y reemplazarla por una gateway delgada y altamente optimizada — obtenemos un sistema con una sobrecarga mínima, extremadamente fácil de desplegar y preparado de forma nativa para la integración con IA. El futuro del desarrollo no tiene por qué consistir en escribir miles de líneas de código de tránsito, sino en definir con precisión el modelo de datos y la lógica de negocio directamente donde los datos están en casa.