📝 Caso de Estudio: Cómo construir un SaaS Multi-tenant con Next.js 16, NestJS 11 y PostgreSQL RLS

Introducción: El problema de los portafolios aburridos

Seamos honestos. La mayoría de los portafolios de desarrolladores se ven exactamente iguales: una plantilla minimalista genérica, una cuadrícula con proyectos simples y una lista de tecnologías que nadie entra a auditar.

Cuando rediseñé mi espacio web, quise enfocarlo de otra manera: mostrar ingeniería real aplicada a producción. En lugar de subir 10 proyectos pequeños, decidí desglosar casos de estudio profundos.

Este es el análisis técnico de Äbasto, un SaaS B2B full-stack para la gestión de inventario y puntos de venta (POS) que resuelve el aislamiento de datos, subdominios dinámicos y un sistema de suscripción con periodos de gracia bajo un único monorepo con pnpm workspaces.

🏗️ El Stack Tecnológico

El proyecto está estructurado de manera eficiente en un monorepo:

Frontend: Next.js 16 (App Router), Zustand (para persistencia de estado local) y Tailwind CSS v4.

Backend: NestJS 11, TypeORM y PostgreSQL.

🛡️ Reto 1: Aislamiento de datos a nivel de Base de Datos (PostgreSQL RLS)

Cuando construyes un SaaS donde múltiples bodegas independientes gestionan inventarios, las filtraciones de datos entre clientes son tu peor pesadilla. Depender de añadir un WHERE warehouse_id = X en cada query del backend es peligroso y propenso a errores humanos.

La Solución: Row-Level Security (RLS)
Delegué el aislamiento de datos directamente al motor de PostgreSQL usando seguridad a nivel de fila.

Cada transacción se ejecuta de forma aislada. Un JwtAuthGuard personalizado en NestJS intercepta la petición, decodifica los datos del inquilino (tenant) e inyecta variables de sesión en la base de datos usando comandos SQL SET LOCAL:

// Inyección dinámica del contexto del inquilino
async function injectTenantContext(queryRunner: QueryRunner, warehouseId: string) {
  // Ejecución segura dentro del bloque de la transacción de la petición
  await queryRunner.query(`SET LOCAL app.current_warehouse_id = '${warehouseId}'`);
}

En la base de datos, las tablas imponen el aislamiento de forma nativa:

ALTER TABLE inventory ENABLE ROW LEVEL SECURITY;

CREATE POLICY warehouse_isolation_policy ON inventory
    USING (warehouse_id = NULLIF(current_setting('app.current_warehouse_id', true), ''));

Esto significa que incluso si a un desarrollador se le olvida filtrar por bodega en el código, PostgreSQL bloqueará por defecto cualquier intento de acceso cruzado.

🌐 Reto 2: Subdominios dinámicos multi-tenant en Next.js 16

Quería que cada dueño de bodega tuviera un subdominio único y limpio (ej: mi-tienda.lvh.me:3000).

La Solución: Proxy de reescritura dinámica
En lugar de saturar el sistema con un middleware.ts pesado, utilicé un bloque de ejecución proxy.ts en el servidor de Next.js 16. Este lee la cabecera Host en tiempo real y reescribe las rutas internamente:

// frontend/src/proxy.ts (Lógica simplificada)
export function handleSubdomainRewrite(requestHeaders: Headers) {
  const host = requestHeaders.get('host'); // ej: 'bodega-x.lvh.me:3000'
  const subdomain = host.split('.')[0];

  // Ignorar las rutas del sistema reservadas internamente
  if (subdomain === 'admin' || subdomain === 'www') {
    return null; 
  }

  // Realiza una reescritura interna hacia la ruta dinámica de la tienda
  return `/store/${subdomain}`;
}

El truco de seguridad Server-Side
Para evitar que un usuario manipule la URL y suplante la identidad de otra tienda, el proxy lee la cookie de sesión token (configurada con alcance global domain=.lvh.me), decodifica el JWT en el servidor y verifica si la bodega autorizada coincide estrictamente con el subdominio solicitado. Si no hay coincidencia, redirige inmediatamente a /no-access.

⏳ Reto 3: Restricción automatizada y motor de suscripciones

Un SaaS real necesita monetizarse y aplicar restricciones de uso de forma inteligente, sin bloquear el acceso histórico del cliente arbitrariamente. Diseñé un modelo con un periodo de gracia de 3 días.

Estado Activo -> [Fecha Expiración] -> Periodo de Gracia (Banners) -> Bloqueo Completo de Operaciones

El Guardián del Backend (SubscriptionGuard)
Construí un SubscriptionGuard global aplicado a todos los endpoints de escritura (POST, PATCH, DELETE) en los módulos críticos de productos, inventario y proveedores:

@Injectable()
export class SubscriptionGuard implements CanActivate {
  async canActivate(context: ExecutionContext): Promise<boolean> {
    const req = context.switchToHttp().getRequest();
    const { expiresAt, gracePeriodDays } = req.user; // Datos inyectados en la sesión

    const absoluteDeadline = new Date(expiresAt);
    absoluteDeadline.setDate(absoluteDeadline.getDate() + (gracePeriodDays || 3));

    if (new Date() > absoluteDeadline) {
      throw new ForbiddenException('Suscripción expirada. Operaciones de escritura bloqueadas.');
    }
    return true; // Las peticiones GET (lectura) siguen abiertas
  }
}

Comportamiento en el Frontend

• Faltando 5 días para vencer: Un banner ámbar dinámico (SubscriptionBanner) aparece en el Dashboard.

• Durante el Periodo de Gracia: El banner cambia a color naranja de advertencia.

• Pasado el Periodo de Gracia: Un componente de bloqueo de pantalla completa (SubscriptionLock) toma el control del punto de venta (POS) mostrando un botón directo de soporte mediante enlaces dinámicos de WhatsApp (wa.me).

📨 Reto 4: Notificaciones híbridas (Emails con Resend y atajos de WhatsApp)

Para mantener una comunicación operativa fluida sin incurrir en costes elevados de infraestructura, implementé un sistema de notificación de doble canal:

1. Canal A (Mails transaccionales automatizados): Un módulo global de notificaciones se conecta con el SDK de Resend en el backend. Dispara correos formateados con plantillas HTML de estilo neobrutalista oscuro ante eventos críticos (bienvenida, restablecimiento de contraseña y alertas de facturación gestionadas por un CRON job diario a mediodía).

2. Canal B (Flujos manuales de WhatsApp): Desde el panel de administración, el SuperAdmin cuenta con botones contextuales que generan mensajes dinámicos basados en el estado de cuenta del cliente, facilitando el cobro manual con un solo clic.

🧠 Conclusiones

Desarrollar Äbasto me demostró que vale mucho más la pena documentar la resolución de problemas arquitectónicos reales y complejos que acumular repositorios sencillos. Esto valida habilidades críticas:

• Comprensión avanzada de seguridad y rendimiento en bases de datos.

• Arquitectura de redes y enrutamiento en el servidor (proxies, manejo de DNS internos).

• Enfoque de producto y lógica de negocio orientada a la monetización.

Link: https://portfolio-three-topaz-81.vercel.app/en/projects/abasto

¿Cómo gestionas tú el aislamiento de datos en tus proyectos SaaS? ¿Prefieres bases de datos separadas o aislamiento lógico por fila (RLS)? ¡Debatamos en los comentarios!