Como no cagarla Vibe Codeando. (mini tip) · Cágala, Aprende, Repite

Como no cagarla Vibe Codeando. (mini tip)

Llevo usando diferentes modelos de IA desde que apareció GPT3.5. Desde ese momento comencé prompteando pequeños scripts para dispositivos IOT, desde ahí he intentado mantenerme actualizado y probando diferentes formas de Vibe Codear aplicaciones cada vez más robustas.

Cuando comencé a promtear mini soluciones de para diferentes objetivos, derivé a NoCode (N8N y Make) y con eso desarrolle soluciones aun mas robustas.

Prompteaba una parte y la otra la automatizaba..

Hasta hace muy poco cuando se comenzó a hablar de Skills, Agentes y un montón de herramientas como MCP, Cli, etc.. (Me voló la cabeza)

Estaba Vibe Codeando una app muy útil para Agricultores iba rápido, todo funcionando... yo Feliz..

Sin embargo había cometido algunos de los peores errores en el que puede caer un Vibe Coder..

En esta publicación me enfocare en dos de los cuales me hicieron retroceder y perder mucho tiempo, genera demasiados errores si no se comienza con esto en la planificación..

El Multi Tenant.

Mientras Vibe Codeaba prompteando y gastando muucho tiempo, dandole instrucciones al modelo. pensaba en la forma en que podría escalar.. ya que. O vendía la app a quien la quisiera o necesitara y le daba soporte y mantención.. ¿y si vendía 10? ¿y si simplemente la copiaban y la montaban en otro servidor? ¿Como la protegía o mantenía si eran 100?...

Y ahí me ilumino la solución El Multi Tenant.

Multi tenant es abstraer la solución y pensar mas arriba no va a haber un administrador y un usuario, se crea la imagen del Super Administrador, y toda la topología cambia.

[ Super Usuario ]

| | |

[TENANT A] [TENANT B]. [TENANT C]

| | |

Gracias a esto, puedes solucionar el segundo problema..

La Seguridad.

Cuando piensas en vender tu solución como un producto, todo cambia. Mientras vibe codeas una agenda o un kanban para uso personal, la seguridad no te quita el sueño. Pero cuando decides empaquetar esa solución para el mercado, el juego es otro. Sin embargo, cuando piensas en Multi Tenant, involucra muchos administradores y muchos más usuarios aun, cada administrador debe poder ver solo los datos de su tenant (empresa), y no los datos de "su competencia".

Y es aquí justo el punto donde todo cambia.

Si hablamos de seguridad existen 3 tipos de multi tenant

Base de datos por Inquilino (Database-per-Tenant)

Cada cliente tiene su propia base de datos física e independiente, compartiendo solo el servidor de aplicaciones. Ofrece el máximo aislamiento y seguridad de datos, pero es la opción más costosa y compleja de mantener a gran escala.

Una Base de Datos, Esquemas Separados (Schema-per-Tenant)

Todos los clientes comparten la misma base de datos, pero sus tablas están separadas lógicamente en "carpetas" o esquemas independientes. Es un enfoque híbrido que equilibra el costo operativo con un nivel de aislamiento bastante limpio a nivel de base de datos.

Base de Datos Compartida, Esquema Compartido (Shared Database, Shared Schema)

Todos los clientes guardan su información en las mismas tablas, diferenciándose únicamente por una columna obligatoria (como tenant_id). Es la opción más barata y fácil de actualizar, pero requiere un cuidado extremo en el código para que un cliente jamás vea los datos de otro.

Cada una con una implicancia en seguridad diferente y costos diferentes.

Al final, la IA puede tirar miles de líneas de código en segundos, pero la arquitectura la tienes que decidir tú antes de darle al Enter.

Espero te sirva, y que no hayas avanzado cometiendo mi error.

Saludos.

3 comments

Como no cagarla Vibe Codeando. (mini tip)