¿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 front end que la gente ve y pulsa, el back end 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 permite 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 de apertura 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 creas con IA

Cuando describes una app a un creador con IA, las palabras que usas deciden qué capas construye. «Haz una página que muestre nuestra carta» produce un front end. «Deja que los clientes pidan desde 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 se guarden datos, dilo. Un creador que solo hace el front end parecerá terminado, pero se olvidará de todo al recargar.
• Detectas una falsa apariencia de terminado. 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 front end solo puede servirse como archivos estáticos. Un back end 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 front end. Las cartas, 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 back end. Los clientes nunca 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 cuando cambia el turno.

Un restaurante que solo tiene comedor puede enseñarte una carta bonita, pero no te puedes comer nada. Eso es una app que solo tiene front end y finge ser full-stack.

Las tres capas con más detalle

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

Ese orden es la idea de seguridad más importante de toda la pila. Todo lo que está en el front end puede ser leído y modificado por el visitante, porque se ejecuta en su dispositivo. Por eso las reglas —«solo el propietario puede ver esta factura», «un cupón solo puede usarse una vez»— deben aplicarse en el back end. Para más detalles sobre esa división, consulta front end frente a back end.

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 los horarios de esta semana, pulsa una clase, inicia sesión y reserva una plaza.

Lo que pasa por debajo:

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

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

Términos clave

• Front end (lado del cliente): la parte que se ejecuta en el navegador.
• Back end (lado del servidor): la parte que se ejecuta en un servidor. También se llama servidor de API.
• Base de datos: donde se guardan los datos de forma organizada. Consulta qué es una base de datos.
• API: la lista de peticiones que acepta el back end desde el front end 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 programa que hace todo, frente a varios programas más pequeños (por ejemplo, una web y una API independiente). Ambos son full-stack.

Errores habituales e ideas erróneas

• «Parece terminado, así que está terminado». 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 front end. Ocultar un botón no es seguridad. Si el back end no comprueba nada, cualquiera que conozca la petición puede hacerla.
• Poner claves secretas en el front end. 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 back end, 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, un puñado de rutas en el back end y tres tablas en la base de datos. Describe las capas, no el tamaño.
• Pensar que tienes que 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 términos 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, una página de administración que liste 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 escepticismo: recarga, inicia sesión con dos personas distintas e intenta ver datos que no deberías ver. La guía para crear 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 front end 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 la documentación sobre apps de varios servicios muestra cómo una web y una API se previsualizan y publican juntas, y la página del creador de apps full-stack ofrece puntos de partida.

Preguntas