¿Qué es un servidor? Guía en lenguaje sencillo para quienes crean apps

Un servidor es un ordenador —o un programa que se ejecuta en uno— que espera peticiones y las responde. Cuando abres una web, tu navegador (el cliente) envía una petición a través de internet, y en algún lugar un servidor devuelve la página, las imágenes o los datos. Todas las apps que usas, desde el correo hasta la banca en línea, dependen de servidores que hacen esto millones de veces al día.

Por qué importan los servidores cuando construyes con IA

Cuando un creador con IA te hace una app, parte del código se ejecuta en el navegador del visitante y parte suele ejecutarse en un servidor. La parte del servidor hace lo que el navegador no puede hacer, o en lo que no se puede confiar:

• Guardar y cargar datos desde una base de datos.
• Mantener secretos, como las claves de API de pagos o de proveedores de IA, que nunca deben llegar al navegador.
• Comprobar permisos: asegurarse de que un usuario solo ve y cambia sus propios registros.
• Hablar con otros servicios: cobrar una tarjeta, enviar un correo, llamar a un modelo de IA.

Saber qué hace el servidor te ayuda a entender dónde viven realmente las reglas de tu app, por qué algunos cambios requieren volver a publicar y qué pagas cuando alojas una app. Para la división entre las dos mitades, consulta frontend frente a backend.

Una analogía cotidiana

Un servidor es como el personal de ventanilla de una oficina de correos. No sale a buscar clientes; espera. Un cliente (el cliente de la petición) se acerca con una solicitud —«envíe este paquete», «¿tengo correo?»—, el empleado la gestiona y devuelve un resultado. Una misma ventanilla atiende a muchos clientes uno tras otro, y una oficina ocupada abre más ventanillas.

La oficina también tiene normas que el cliente no puede saltarse: para recoger un paquete hay que enseñar el documento. Eso es también el trabajo del servidor en una app: el navegador puede pedir cualquier cosa, pero el servidor decide qué obtiene.

Cómo llega una petición a un servidor

Cuando alguien visita https://bookings.example.com/schedule:

1. Búsqueda DNS. El navegador pregunta al sistema de nombres de dominio qué dirección IP corresponde a bookings.example.com. Consulta cómo funcionan los dominios y el DNS.
2. Conexión. El navegador se conecta a esa dirección, por el puerto 443 para HTTPS, y establece una conexión cifrada. Consulta qué es HTTPS.
3. Petición. Envía una petición HTTP: GET /schedule.
4. Trabajo. El servidor ejecuta el código que gestiona /schedule, quizá buscando las reservas de hoy en la base de datos.
5. Respuesta. Devuelve un código de estado (200 OK) y el contenido: una página HTML o datos JSON que la página muestra.

Todo esto suele tardar una fracción de segundo.

Tipos de servidores que oirás nombrar

Ten en cuenta que «servidor» significa tanto la máquina como el programa. «Se ha caído el servidor» puede referirse a cualquiera de los dos.

Un ejemplo práctico: una app de reservas para una peluquería

Esto es lo que hace el servidor en una pequeña app de reservas de peluquería:

• Un visitante abre la web. El servidor (o una CDN delante de él) envía los archivos de la página.
• La página pide al servidor GET /api/slots?date=2026-10-03. El servidor consulta la base de datos para ver los huecos libres y los devuelve como JSON.
• El visitante reserva las 14:00. La página envía POST /api/bookings. El servidor comprueba que el hueco sigue libre —no se fía de lo que diga el navegador—, guarda la reserva y devuelve 201 Created.
• El servidor llama a un servicio de correo con una clave secreta, guardada en el servidor, para enviar la confirmación.

Si apagaras el servidor, la página quizá seguiría cargando desde una CDN, pero no podría mostrar huecos ni guardar reservas.

Lo que necesita un servidor para funcionar bien

• Memoria (RAM) y CPU. Con poca memoria la app se cae bajo carga; con poca CPU, se ralentiza.
• Estar en marcha. Un servidor apagado no puede responder. Algunas plataformas duermen las apps inactivas y las despiertan en la siguiente visita, lo que ahorra dinero pero puede hacer más lenta la primera petición.
• Configuración y secretos, proporcionados como variables de entorno.
• Registros (logs): el historial del servidor de lo que ha ocurrido, que es lo primero que miras cuando algo se rompe.
• Actualizaciones y parches de seguridad, que el alojamiento gestionado hace por ti.

Ideas equivocadas habituales

• «La nube significa que no hay servidores». La nube son los servidores de otras empresas, alquilados por hora o por uso.
• «Un servidor es un ordenador grande y especial». Cualquier ordenador puede actuar como servidor. Tu portátil ejecuta uno cuando abres localhost durante el desarrollo.
• «Si el botón está oculto, los usuarios no pueden pulsarlo». Cualquiera puede enviar peticiones directamente a tu servidor. Las comprobaciones de permisos deben hacerse en el servidor, no solo en la página.
• «Más servidores arreglan la lentitud». A menudo la causa real es una consulta lenta a la base de datos o una API externa. Encuentra primero el cuello de botella.
• «Necesito gestionar un servidor para tener una app». Las plataformas gestionadas ejecutan los servidores por ti; tú despliegas el código y ellas se ocupan de las máquinas.

Qué pedir a tu creador de apps con IA

• «¿Qué partes de esta app se ejecutan en el servidor y cuáles en el navegador?»
• «Guarda todas las claves de API en el servidor y léelas desde variables de entorno.»
• «Comprueba los permisos en el servidor para cada petición que lea o modifique datos.»
• «¿Dónde encuentro los registros del servidor y qué dicen sobre este error?»
• «¿Necesita esta app un servidor o puede ser un sitio estático?»
• «¿Qué pasa con la primera petición después de que la app haya estado inactiva?»

Servidores en Mythex

En Mythex no configuras ni gestionas servidores. Mientras construyes, tu app se ejecuta en un entorno en la nube privado para la vista previa en vivo. Cuando publicas, Mythex la despliega: los frontends estáticos como sitios estáticos y los backends (Node, Python, C#, Java y otros) como contenedores creados a partir de un Dockerfile, sin que tengas que configurar el alojamiento. Mythex elige el tamaño de la máquina al desplegar: por defecto 1 CPU y 512 MB de memoria, con más disponible bajo petición (hasta 1 GB en Free, y hasta 2 CPU, 4 GB y 3 máquinas en Pro). Las apps publicadas duermen cuando están inactivas y se despiertan en la siguiente visita, y una app dormida no consume cómputo. Los detalles están en la documentación sobre backends de API y límites de alojamiento, y nuestra guía de alojamiento web cubre el panorama general.

Preguntas