1. La parte de la web que no se ve
Cuando compras algo en una tienda online, la página que ves es solo la superficie. Detrás, un programa que se ejecuta en el servidor comprueba que has iniciado sesión, consulta el stock en una base de datos, calcula el precio con tus descuentos, registra el pedido y envía el correo de confirmación. Ese programa es lo que se estudia en este módulo: el desarrollo en entorno servidor, también llamado backend.
La diferencia con el código del cliente es fundamental. El código del servidor se ejecuta en una máquina que controlas tú, así que el usuario no puede verlo ni modificarlo. Por eso es ahí donde viven las reglas de negocio, la seguridad y el acceso a los datos. El navegador solo recibe el resultado: una página HTML ya construida o unos datos en JSON.
El servidor es la cocina de un restaurante
2. HTTP, el idioma entre cliente y servidor
Todo el trabajo del servidor gira alrededor de HTTP, así que merece la pena conocerlo bien. Es un protocolo de texto sencillo: el cliente envía una petición y el servidor devuelve una respuesta. Cada petición es independiente de las anteriores (HTTP no tiene memoria, es sin estado), y por eso más adelante necesitaremos cookies y sesiones para recordar quién es cada usuario.
1POST /carrito/anadir HTTP/1.1
2Host: tienda.com
3Content-Type: application/x-www-form-urlencoded
4Cookie: PHPSESSID=8f3a…
5
6producto=42&cantidad=2
7
8HTTP/1.1 302 Found
9Location: /carrito
10Set-Cookie: aviso=anadido; HttpOnly| Método | Significado | ¿Modifica datos? | ¿Idempotente? |
|---|---|---|---|
| GET | Leer un recurso | No | Sí |
| POST | Crear o enviar datos para procesar | Sí | No |
| PUT | Reemplazar un recurso completo | Sí | Sí |
| PATCH | Modificar parte de un recurso | Sí | No necesariamente |
| DELETE | Borrar un recurso | Sí | Sí |
Idempotente significa que repetir la petición deja el sistema igual que hacerla una vez. Borrar el producto 7 dos veces tiene el mismo efecto que borrarlo una; crear un pedido dos veces, no. Esta distinción explica por qué el navegador te avisa al recargar una página a la que llegaste con POST.
| Código | Familia | Los más habituales |
|---|---|---|
| 1xx | Información | 101 cambio de protocolo (WebSockets) |
| 2xx | Éxito | 200 OK · 201 creado · 204 sin contenido |
| 3xx | Redirección | 301 permanente · 302 temporal · 304 no modificado (usa la caché) |
| 4xx | Error del cliente | 400 petición mal formada · 401 sin autenticar · 403 prohibido · 404 no encontrado · 422 datos no válidos |
| 5xx | Error del servidor | 500 error interno · 502 pasarela incorrecta · 503 no disponible |
3. Servidores web, de aplicaciones y lenguajes
En una aplicación web suelen colaborar dos tipos de programa. El servidor web (Apache, Nginx) recibe las conexiones HTTP, sirve directamente los ficheros estáticos (imágenes, CSS, JavaScript) y pasa las peticiones dinámicas al servidor de aplicaciones o intérprete del lenguaje, que ejecuta tu código y genera la respuesta. En PHP, lo habitual hoy es Nginx con PHP-FPM, un conjunto de procesos que ejecutan los scripts; en Java, un servidor como Tomcat; en Node.js, el propio programa escucha en un puerto.
Qué ocurre en una petición a una página PHP
- El navegador pide
/productos.php?categoria=teclados. - Nginx ve la extensión
.phpy pasa la petición a PHP-FPM. - PHP ejecuta el script desde el principio: rellena
$_GET,$_POST,$_COOKIE…, consulta la base de datos y escribe HTML conecho. - Todo lo que el script escribe se convierte en el cuerpo de la respuesta.
- Al terminar, PHP olvida todo: la siguiente petición empieza de cero. Por eso los datos que deben durar se guardan en la base de datos, en la sesión o en cookies.
| Tecnología | Lenguaje | Puntos fuertes | Dónde se usa |
|---|---|---|---|
| PHP (Laravel, Symfony) | PHP | Fácil de desplegar, enorme ecosistema, alojamiento barato | WordPress (más del 40 % de las webs), tiendas, pymes |
| Java (Spring Boot) | Java | Robusto, tipado, muy escalable | Banca, seguros, grandes empresas |
| Node.js (Express, NestJS) | JavaScript / TypeScript | Mismo lenguaje en cliente y servidor, tiempo real | Startups, APIs, aplicaciones en tiempo real |
| Python (Django, FastAPI) | Python | Rapidez de desarrollo, ciencia de datos | Plataformas de contenido, IA, APIs |
| C# (ASP.NET Core) | C# | Rendimiento, herramientas de Microsoft | Empresas con tecnología Microsoft |
En este módulo usaremos PHP: es el lenguaje de servidor que más se enseña en DAW, sigue moviendo una parte enorme de la web y, desde la versión 8, es un lenguaje moderno, rápido y con tipos. Todo lo que aprendas (validar, proteger, organizar en MVC, acceder a datos, diseñar APIs) se traslada a cualquier otro.
4. Arquitecturas de aplicación
La forma de organizar una aplicación en capas o piezas es su arquitectura. La más clásica es la de tres capas: presentación (lo que ve el usuario), lógica de negocio (las reglas) y datos (la base de datos). Separarlas permite cambiar una sin romper las demás: puedes rediseñar la web o añadir una app móvil sin tocar las reglas del negocio.
| Arquitectura | Idea | Cuándo |
|---|---|---|
| Monolito | Toda la aplicación en un solo proyecto y despliegue | La mayoría de proyectos, sobre todo al empezar |
| Backend + frontend separados | El servidor expone una API en JSON y una SPA o app móvil la consume | Cuando hay varios clientes (web, móvil, terceros) |
| Microservicios | Muchos servicios pequeños e independientes que se comunican por red | Equipos grandes con partes que escalan por separado |
| Serverless | Funciones que el proveedor ejecuta bajo demanda | Tareas puntuales o tráfico muy irregular |
Empieza por el monolito
5. Prepara tu entorno de trabajo
Para programar en PHP necesitas el intérprete, un servidor web y una base de datos. Hay tres formas habituales de tenerlos, de más sencilla a más profesional:
| Opción | Qué es | Ventajas e inconvenientes |
|---|---|---|
| Servidor integrado de PHP | php -S localhost:8000 en la carpeta del proyecto | Inmediato para practicar; no sirve para producción |
| XAMPP / Laragon | Paquete que instala Apache, PHP y MariaDB juntos | Cómodo en Windows; las versiones no coinciden con las del servidor real |
| Docker | Contenedores con las mismas versiones que en producción | Reproducible y profesional; requiere aprender Docker (lo verás en Despliegue) |
1services:
2 web:
3 image: php:8.3-apache
4 ports: ["8080:80"]
5 volumes: ["./src:/var/www/html"]
6 depends_on: [db]
7 db:
8 image: mariadb:11
9 environment:
10 MARIADB_DATABASE: tienda
11 MARIADB_USER: tienda
12 MARIADB_PASSWORD: cambia-esta-clave
13 MARIADB_ROOT_PASSWORD: otra-clave-distintaCon este fichero, docker compose up levanta Apache con PHP en http://localhost:8080 sirviendo la carpeta src, y una base de datos MariaDB a la que PHP se conecta con el nombre de host db. Completa el entorno con Visual Studio Code (extensión PHP Intelephense), Composer para las dependencias y Git.
6. Ejercicios
Lee una conversación HTTP
Abre las herramientas de desarrollo (F12 → Red), inicia sesión en una web que uses y busca la petición del formulario de acceso. Responde: ¿qué método usa?, ¿a qué URL?, ¿qué código de estado devuelve?, ¿qué cabecera Set-Cookie recibe y con qué atributos?, ¿a dónde te redirige después? Explica por qué crees que ha elegido ese método y ese código.
Elige la tecnología
Recomienda una tecnología de servidor (PHP con Laravel, Java con Spring Boot, Node.js o Python con Django) y una arquitectura para cada caso, justificándolo: 1. La web de una academia con blog y formulario de contacto, alojamiento económico. 2. La plataforma interna de un banco, con un equipo de 40 desarrolladores Java. 3. Un chat en tiempo real para atención al cliente. 4. Una API que sirve datos a una app móvil y a una web hecha en React.
Tu primer entorno con Docker
Crea un proyecto con el compose.yaml del tema, añade src/index.php que muestre la fecha actual, la versión de PHP (PHP_VERSION) y la lista de extensiones cargadas, y compruébalo en el navegador. Después añade un script src/db.php que se conecte a MariaDB con PDO y muestre «Conexión correcta» o el mensaje de error.