Frontend vs. backend: qué se ejecuta en el navegador y qué en el servidor

¿Qué dicen las fuentes técnicas de cada lado?

“Frontend” y “backend” son términos de uso corriente; la documentación de MDN prefiere hablar de código del lado del cliente y del lado del servidor. Según MDN, el código que se ejecuta en el navegador se ocupa de mejorar la apariencia y el comportamiento de la página: elegir y dar estilo a componentes de interfaz, crear diseños, la navegación y la validación de formularios. Se ejecuta dentro del navegador y tiene poco o ningún acceso al sistema operativo. La programación del lado del servidor, en cambio, consiste sobre todo en elegir qué contenido se devuelve al navegador en respuesta a cada petición. Ese código valida los datos y las peticiones que llegan, usa bases de datos para guardar y recuperar información y mantiene sesiones, el mecanismo con el que un servidor recuerda a la persona y responde distinto según quién es (MDN, Introduction to the server side).

Un detalle que confunde a quien empieza: el lenguaje no define el lado. MDN señala que JavaScript corre en el navegador, pero también puede ser un lenguaje del servidor, por ejemplo en Node.js (MDN, What is JavaScript?). Lo que importa es dónde se ejecuta.

¿Dónde se ejecuta cada cosa en una app generada con IA?

Las herramientas de vibe coding generan proyectos que parecen un solo bloque, pero cada archivo corre en un sitio distinto. Estas señales ayudan:

Los frameworks actuales difuminan la línea dentro de un mismo proyecto. En Next.js, por ejemplo, las páginas y los diseños son por defecto componentes de servidor, que pueden consultar datos y usar claves sin exponerlas al cliente. Los archivos marcados con "use client" (y lo que importan) pasan a formar parte del código que se envía al navegador, y se reservan para cuando hace falta estado, eventos como un clic o APIs del navegador (Next.js, Server and Client Components). Si le pides a la IA un botón que guarda datos, conviene preguntarle en cuál de los dos tipos de archivo lo puso.

Hay una trampa frecuente con las variables de entorno. En Next.js, solo las variables con el prefijo NEXT_PUBLIC_ se incluyen en el código que recibe el navegador; las demás se reemplazan por una cadena vacía (Next.js, Server and Client Components). En Vite, las que empiezan por VITE_ quedan expuestas en el código del cliente, y su documentación advierte que no deben contener información sensible como claves de API (Vite, Env variables and modes). Por eso una clave privada con uno de esos prefijos equivale a publicarla. El detalle de qué claves pueden ir en el navegador está en variables de entorno y secretos.

¿Qué pasa cuando la app habla directo con la base de datos?

Una app puede usar un servicio de datos como Supabase y consultar la base desde el navegador, sin servidor propio. Eso no elimina el backend: lo traslada al servicio, y la seguridad depende de su configuración. La documentación de Supabase advierte que una tabla de un esquema expuesto sin Row Level Security (RLS) es legible y escribible por cualquier rol con permisos sobre ella. Con RLS activado, ningún dato es accesible por la API con una clave publicable hasta que se crean políticas, y las claves secretas no se deben usar en el navegador (Supabase, Row Level Security). Cómo se escriben esas reglas se explica en bases de datos para diseñadores.

¿Qué debe vivir en cada lado?

Una regla práctica: el navegador muestra y pide; el servidor decide y guarda.

• En el navegador: el diseño, los mensajes, el estado de la pantalla y las validaciones que mejoran la experiencia, como avisar de que falta la arroba en un correo antes de enviarlo.
• En el servidor: las reglas de negocio, los permisos, las claves, la escritura en la base de datos y la validación final de todo lo que llega.

La validación del navegador ayuda a la persona, pero no protege nada: quien envía la petición sin pasar por la pantalla se la salta. La que cuenta es la del servidor o la de la base de datos. La API es el canal por el que ambos lados se hablan, y desplegar es publicar ambas partes.

¿Por qué le importa a un diseñador que trabaja con IA?

Porque cada decisión de diseño que depende de un permiso debe tener respaldo en el servidor. Ocultar un botón “Eliminar” a quien no tiene permiso es experiencia. Si el botón desaparece pero el servidor sigue aceptando la petición, es un agujero. La pregunta útil para ti es: ¿quién hace cumplir esta regla?, y se la puedes hacer también a la IA cuando te entrega una pantalla.

Ejemplo

Ejemplo ilustrativo: una diseñadora tiene una app de solicitudes de clientes. La pantalla oculta el botón “Aprobar” a quien no es gerente, y eso es lo que se ve en las pruebas. Al revisar, descubre que la función del servidor que aprueba solicitudes no comprueba el rol de quien llama, así que cualquiera con una petición bien formada podría aprobar. Pide que la regla se verifique en el servidor, añade una prueba con una cuenta sin permisos que intente aprobar y solo entonces da la pantalla por cerrada. El botón oculto era experiencia; la comprobación en el servidor es la seguridad.

¿Cómo aplicarlo mañana?

1. Haz una lista de cinco reglas importantes de tu app: quién puede hacer qué, qué datos son privados, qué cuesta dinero. Para cada una, anota si la comprueba el navegador o el servidor.
2. Si una regla solo la comprueba el navegador, pide a la IA que la repita en el servidor o en la base de datos, y pruébala con una cuenta que no debería poder hacerlo.
3. Busca claves en variables con prefijo público (NEXT_PUBLIC_, VITE_) y en archivos que el navegador descarga. Si hay una privada, muévela al servidor antes de cualquier otra cosa.
4. Al describir un flujo a la IA, indica en qué lado vive cada parte: “esta comprobación corre en el servidor, no en el componente”. La mayoría de los errores de arquitectura nacen de una frase ambigua.

Si la herramienta que usas crea la app de punta a punta, qué es el vibe coding explica por qué conviene revisar justo esta frontera.

Errores comunes

• Creer que ocultar un botón equivale a restringir una acción.
• Poner la validación de permisos solo en el navegador.
• Guardar claves privadas en archivos o variables que el navegador descarga.
• Pensar que una app “sin servidor” no tiene backend: el servicio que usa lo es.
• Confundir validar el formato (un correo con arroba) con validar el permiso.
• Dar por hecho que JavaScript siempre corre en el navegador.

Fuentes

• MDN, Introduction to the server side: cliente frente a servidor, validación, bases de datos y sesiones.
• MDN, What is JavaScript?: código del cliente y del servidor, JavaScript en Node.js.
• Next.js, Server and Client Components: componentes de servidor por defecto, "use client" y variables con prefijo NEXT_PUBLIC_.
• Vite, Env variables and modes: variables VITE_ expuestas en el código del cliente.
• Supabase, Row Level Security: la base de datos hace cumplir el acceso; las claves secretas no van en el navegador.