[Vibe coder #1] Anatomía de mi app creada por IA: frontend, backend y DB

Cada vez más personas crean apps dándoles instrucciones a la IA. Si pides «créame un servicio así» a herramientas como Cursor, Claude Code o v0, obtienes una app funcional. Pero después aparece un obstáculo común: no sabes qué construyó realmente la IA. Cuando surge un error, no sabes dónde mirar ni qué preguntarle.

El primer paso para superar este obstáculo no es saber leer código. Es entender de qué piezas está hecha tu app y qué hace cada una: tener un mapa de su estructura. Son las tres piezas que los desarrolladores llaman frontend, backend y DB. En este artículo las explicamos por completo para no desarrolladores. Con este mapa, las API keys, Git, el despliegue y los costes de los próximos artículos encajarán en su sitio.

Una app tiene la misma estructura que un restaurante

Ya sea web o móvil, la mayoría de los servicios que reciben usuarios constan de tres partes. La comparación con un restaurante encaja perfectamente.

Sala (frontend) es el espacio donde se sientan los clientes: menú, mesas e interiorismo. Todo lo que ven y tocan directamente. En una app, aquí están los botones, los campos de entrada y las transiciones de pantalla.

Cocina (backend) es el espacio que los clientes no pueden ver. Allí se cocina realmente cuando llega un pedido, y se guardan secretos comerciales como las recetas y la gestión de ingredientes. En una app, procesa el inicio de sesión, los pagos y la comprobación de permisos.

Almacén (base de datos, DB) es donde se guardan los ingredientes. Aunque la cocina se incendie y cierre, los ingredientes del almacén permanecen. En una app, aquí se almacenan realmente los datos de usuarios, publicaciones y pedidos.

Cuando el cliente (usuario) hace un pedido en el menú (frontend), la comanda llega a la cocina (backend), que saca ingredientes del almacén, cocina (consulta la DB) y lo envía a la sala. Este viaje de ida y vuelta ocurre cada vez que actualizas Instagram.

El frontend se ejecuta en el dispositivo del usuario

La característica más importante del frontend es dónde se ejecuta. El código frontend se ejecuta en el navegador (o teléfono) del usuario, no en tu servidor. Al entrar en un sitio, el código se envía al dispositivo, que lo ejecuta y dibuja la pantalla.

Aquí aparece una conclusión esencial para cualquier vibe coder: cualquiera puede abrir y ver el código frontend. Haz clic derecho en el navegador y selecciona «Inspeccionar» para ver el código frontend del sitio actual. No hay excepciones, ni siquiera Naver o Toss. Está diseñado así y no se puede impedir.

Por eso no puedes guardar secretos en el frontend. Poner allí una API key, la contraseña de administrador o la lógica de validación de pagos equivale a hacerla pública en todo el mundo. Al pedirle código a una IA, a veces coloca estos valores en el frontend por comodidad. Si despliegas la app sin saberlo, pueden robarte la API key y provocarte una factura enorme. Lo trataremos en detalle en la parte 2.

El backend se ejecuta en mi servidor

El backend, en cambio, se ejecuta en el servidor que administro. El usuario no puede ver su código; solo puede enviarle «solicitudes» y recibir «respuestas». Es como un cliente que no puede entrar en la cocina y solo puede entregar la comanda.

Por eso, todo lo importante debe hacerse en el backend.

• Guardar secretos: las API keys y los datos de acceso a la DB solo deben estar en el backend.
• Comprobar permisos: la pregunta «¿este usuario tiene derecho a borrar esta publicación?» debe resolverse en el backend. Ocultar el botón de borrar en el frontend es solo decoración: cualquiera puede enviar la solicitud aunque no vea el botón.
• Pagos y cálculos: si calculas el precio en el frontend y confías en el resultado, el usuario puede manipular la solicitud y pagar 1 won.

En resumen: el frontend muestra; el backend decide. Las comprobaciones del frontend sirven para orientar al usuario, pero la seguridad y las decisiones reales corresponden al backend.

La DB es donde los datos viven realmente

Si alguna vez pensaste «borré y volví a desplegar mi app, pero los usuarios siguen ahí», es porque los datos viven en la DB, no en la app. La app (frontend + backend) es la plantilla; la DB es la caja fuerte. Aunque reemplaces toda la plantilla, el contenido de la caja permanece.

Supabase y Firebase, muy usados en el vibe coding, son servicios que gestionan esta DB por ti. De ahí salen estas diferencias:

• Aunque cambies el código y vuelvas a desplegar → los datos están a salvo.
• Si reinicias la DB → aunque el código esté bien, todos los datos desaparecen.

Por eso revertir el código y recuperar los datos son problemas completamente distintos cuando quieres «deshacer algo». El código se revierte con Git (lo veremos en la parte 3) y los datos con una copia de seguridad de la DB. Revertir uno no revierte el otro.

Qué es cada cosa en mi proyecto

Ya conocemos los conceptos; apliquémoslos a la carpeta del proyecto. Al abrir un proyecto creado por IA aparecen muchas carpetas, pero sus nombres permiten distinguirlas aproximadamente. En un proyecto Next.js, el caso más común del vibe coding, es así:

• app/ o pages/, components/ → es el frontend que dibuja las pantallas. Si quieres cambiar el texto de un botón, mira aquí.
• La carpeta app/api/ o un archivo cuya parte superior contiene "use server" → es el backend. Está en el mismo proyecto, pero se ejecuta en el servidor.
• El archivo .env → es el almacén de secretos que usa el backend. Aquí van las API keys y los datos de acceso a la DB.
• La DB normalmente no está dentro de la carpeta del proyecto. Es un espacio independiente que aparece al iniciar sesión en el sitio web o dashboard de Supabase o Firebase.

Hay algo importante: herramientas modernas como Next.js mezclan frontend y backend en una sola carpeta de proyecto. Que haya una sola carpeta no significa que todo se ejecute en el mismo sitio. Algunos archivos se envían al navegador del usuario y otros permanecen solo en el servidor. Si la distinción te confunde, pregunta a la IA: «¿este archivo se ejecuta en el navegador del usuario o en el servidor?». Esa pregunta determina dónde guardar los secretos.

Qué cambia cuando tienes este mapa

Entender la estructura cambia tres cosas de inmediato.

Primero, sabrás dónde mirar cuando aparezca un error. Si la pantalla se ve mal, mira la consola de herramientas de desarrollo del navegador (el grito del frontend); si no se guarda algo o falla el inicio de sesión, mira los logs del servidor (el grito del backend). Al preguntar a la IA, «aparece este error en la consola del navegador» y «aparece este error en los logs del servidor» son pistas completamente distintas. Solo esta distinción mejora mucho su diagnóstico.

Segundo, previene la mitad de los incidentes de seguridad. Secretos en el backend y permisos comprobados en el backend. Respetar solo este principio evita buena parte de los incidentes de seguridad del vibe coding.

Tercero, tus instrucciones para la IA serán más precisas. «Da error al pulsar el botón Guardar» se resuelve mucho antes con «parece que falla la llamada a la API del backend al pulsar el botón; revisa el código del servidor». Las preguntas de quien tiene el mapa son distintas.

Resumen

• Una app es un restaurante compuesto por sala (frontend), cocina (backend) y almacén (DB).
• El frontend se ejecuta en el dispositivo del usuario y cualquiera puede ver su código, así que no debes guardar secretos allí.
• El backend se ejecuta en mi servidor, y allí se toman todas las decisiones, como guardar secretos, comprobar permisos y procesar pagos.
• La DB es independiente de la app: los datos sobreviven aunque reemplaces el código, pero desaparecen si borras la DB.
• Si tienes dudas, pregunta a la IA: «¿este código se ejecuta en el navegador o en el servidor?».

En la próxima parte trataremos el tema que más incidentes provoca sobre esta estructura: las API y las API keys. Explicaremos por qué todos dicen que hay que ocultarlas, qué ocurre realmente cuando se exponen y cómo comprobar si la key de tu proyecto está segura.