¿Qué es una app full-stack? Explicación en lenguaje sencillo

Una app full-stack es una app que incluye todas las capas que necesita para funcionar: el frontend que la gente ve y pulsa, el backend que se ejecuta en un servidor y aplica las reglas, y la base de datos que lo recuerda todo. Una lista de tareas que guarda tus tareas, te deja iniciar sesión desde cualquier dispositivo y no muestra tu lista a nadie más es full-stack. Una sola página que solo muestra tu horario no lo es.

«Stack» significa simplemente las capas de tecnología apiladas unas sobre otras. «Full» significa que todas están presentes.

Por qué importa cuando construyes con IA

Cuando describes una app a un creador con IA, las palabras que uses deciden qué capas construye. «Haz una página que muestre nuestra carta» produce un frontend. «Deja que los clientes pidan de nuestra carta y que la cocina vea los pedidos nuevos» necesita las tres capas, porque los pedidos deben guardarse, compartirse entre dos tipos de usuarios y mantenerse privados.

Conocer la diferencia te ayuda de tres maneras:

• Pides lo correcto. Si quieres que los datos se guarden, dilo. Un creador que solo genera el frontend parecerá terminado, pero olvidará todo al recargar.
• Detectas la falsa completitud. Una demo con datos de ejemplo puede parecer idéntica a una app que funciona. Conocer las capas te permite comprobar que los datos realmente van a algún sitio.
• Entiendes los costes de funcionamiento. Un frontend por sí solo puede servirse como archivos estáticos. Un backend y una base de datos son programas que se ejecutan en servidores, y ahí está la mayor parte del coste de alojamiento.

Una analogía: un restaurante

Piensa en un restaurante.

• El comedor es el frontend. La carta, las mesas y la libreta del camarero. Es lo que ven los clientes, y debe ser agradable y fácil de usar.
• La cocina es el backend. Los clientes no entran. Recibe los pedidos, comprueba que el plato esté disponible, lo cocina y rechaza las peticiones raras. Aquí viven las reglas.
• La despensa y el libro de pedidos son la base de datos. Guardan lo que existe y lo que se ha pedido, para que nada se olvide al cambiar de turno.

Un restaurante con solo comedor puede enseñarte una carta bonita, pero no te dará de comer. Eso es una app que solo tiene frontend y pretende ser full-stack.

Las tres capas en detalle

Las capas se comunican siguiendo un orden fijo. El frontend pide algo al backend a través de una API: un conjunto definido de peticiones que el backend acepta. El backend comprueba la petición, lee o escribe en la base de datos y envía una respuesta. El frontend nunca habla directamente con la base de datos.

Ese orden es la idea de seguridad más importante de toda la pila. Cualquier cosa del frontend puede ser leída y modificada por el visitante, porque se ejecuta en su dispositivo. Por eso las reglas —«solo el propietario puede ver esta factura», «un cupón se puede usar una vez»— deben aplicarse en el backend. Para más información sobre esta división, consulta frontend frente a backend.

Un ejemplo práctico: una app de reservas de clases

Supón que diriges un estudio de yoga y quieres que la gente reserve clases en línea.

Lo que hace el visitante: abre la web, ve el horario de esta semana, pulsa una clase, inicia sesión y reserva una plaza.

Lo que ocurre por debajo:

1. El frontend muestra el horario. Para rellenarlo, pide al backend: «¿Qué clases hay esta semana y cuántas plazas quedan?».
2. El backend pide a la base de datos las clases y cuenta las reservas de cada una, y responde.
3. El visitante pulsa Reservar. El frontend envía «reserva la clase 42 para esta persona con sesión iniciada».
4. El backend comprueba: ¿está realmente con sesión iniciada? ¿Está completa la clase? ¿Ya ha reservado esa clase? Solo si todo está bien escribe una nueva fila de reserva en la base de datos.
5. El backend responde «reservado», y el frontend muestra una confirmación.
6. Más tarde, la responsable del estudio inicia sesión y ve la lista de clases. El backend comprueba que es administradora antes de mostrar los nombres de todos.

Ahora imagina que esto se hubiera construido solo con frontend. El horario podría mostrarse, y el botón Reservar podría mostrar un tic bonito, pero la reserva desaparecería al recargar, el contador de «plazas libres» sería incorrecto para los demás y la responsable nunca la vería. El paso 4 —las comprobaciones— faltaría por completo. Esa es la diferencia práctica.

Términos clave

• Frontend (lado cliente): la parte que se ejecuta en el navegador.
• Backend (lado servidor): la parte que se ejecuta en un servidor. También se llama servidor de API.
• Base de datos: donde los datos se guardan de forma organizada. Consulta qué es una base de datos.
• API: la lista de peticiones que acepta el backend desde el frontend u otros programas.
• Autenticación: comprobar quién es alguien (inicio de sesión). Autorización: comprobar qué puede hacer.
• Despliegue: poner todas las capas en servidores para que el público pueda usarlas.
• Monolito frente a servicios: un único programa que lo hace todo, frente a varios programas más pequeños (por ejemplo, una web y una API independiente). Ambos son full-stack.

Errores comunes e ideas equivocadas

• «Parece terminada, así que lo está». Los datos de ejemplo y un botón que parece funcionar no equivalen a datos guardados. Recarga la página, ábrela en una ventana privada y comprueba que los datos siguen ahí.
• Poner las reglas en el frontend. Ocultar un botón no es seguridad. Si el backend no lo comprueba, cualquiera que conozca la petición puede hacerla.
• Poner claves secretas en el frontend. Una clave de un proveedor de pagos o de IA en el código del navegador es legible por todos los visitantes. Las claves van en el backend, en variables de entorno; consulta variables de entorno y secretos.
• Pensar que full-stack significa complicado. Una app full-stack pequeña puede tener unas pocas pantallas, algunas rutas de backend y tres tablas en la base de datos. Describe las capas, no el tamaño.
• Pensar que debes elegir tú cada tecnología. Cualquier pila sensata y muy usada sirve para una primera versión. Lo que más importa es una descripción clara de los datos y de las reglas.

Qué pedir a tu creador de apps con IA

Describe la app en función de las tres capas, aunque no les pongas nombre:

• Los datos: «Guarda las clases (nombre, hora, aforo) y las reservas (clase, persona, hora de reserva) en una base de datos.»
• Las reglas: «No se puede reservar una clase por encima del aforo. Una persona solo puede reservar una vez cada clase. Solo los administradores pueden ver quién ha reservado.»
• Las pantallas: «Un horario semanal, una confirmación de reserva y una página de administración con las reservas por clase.»
• Las comprobaciones: «Aplica estas reglas en el servidor, no solo en la página. Guarda las claves de API en el servidor.»

Después, pruébalo con espíritu crítico: recarga, inicia sesión con dos personas distintas e intenta ver datos que no deberías ver. La guía para construir una app con IA recorre ese ciclo de principio a fin.

Apps full-stack en Mythex

Mythex crea apps web full-stack a partir de una descripción en el chat. Por defecto, una app nueva recibe un frontend en React y TypeScript; cuando la app necesita guardar datos, Mythex añade al proyecto una base de datos Postgres dedicada, y puedes pedir un servidor de API independiente (por ejemplo, en Python, Node, C# o Java) junto a la web. Todo se ejecuta a la vez en una vista previa en vivo y se publica en una URL pública. La página de apps con varios servicios de la documentación muestra cómo se previsualizan y publican juntos una web y una API, y la página del creador de apps full-stack ofrece puntos de partida.

Preguntas