Arquitectura Web

Cuando empecé a desarrollar, me daba igual la arquitectura: abría un editor, escribía código y lo subía al servidor. Pero cuando el proyecto crece — cuando tienes múltiples usuarios, cuando necesitas desplegar sin parar la app, cuando un error en una función tumba toda la web — te das cuenta de que cómo organizas tu código importa tanto como el código en sí. Elegir mal la arquitectura te condena a reescribir todo desde cero en seis meses.

Este post no es un tutorial de una tecnología concreta. Es un mapa del territorio: las principales arquitecturas web, cuándo usar cada una, qué tecnologías las acompañan, y qué patrones de diseño te ayudarán a tomar mejores decisiones. Lo escribí originalmente en 2017 cuando estaba aprendiendo estas cosas, y lo he ido actualizando con la perspectiva que me ha dado el tiempo y la experiencia. Si estás empezando o quieres afianzar conceptos, esto te dará la base para entender por qué los proyectos se estructuran como se estructuran.

Modelos de arquitectura

Monolítica

La arquitectura monolítica concentra toda la aplicación — frontend, backend y base de datos — en un único despliegue. Es el modelo más tradicional y aún muy utilizado.

Tecnologías típicas en 2017: Laravel (PHP), Django (Python), Ruby on Rails, Spring MVC (Java), ASP.NET MVC.

El monolito funciona bien hasta que no funciona. Cuando tu equipo crece, cuando necesitas desplegar solo un cambio pequeño sin arriesgarte a romper todo, cuando quieres que un servicio caído no tumbe la web entera… ahí es donde necesitas otra cosa. La siguiente evolución natural es separar la aplicación en servicios independientes.

Microservicios

La arquitectura de microservicios divide la aplicación en servicios pequeños e independientes, cada uno con su propia base de datos y lógica de negocio. Se comunican entre sí mediante APIs REST o mensajería asíncrona.

Tecnologías clave: Docker (contenedores), Kubernetes (orquestación), Docker Compose, Netflix OSS (Eureka, Zuul).

Pero los microservicios resuelven el backend. ¿Y el frontend? Si tu usuario tiene que esperar a que el servidor genere el HTML completo en cada clic, la experiencia se siente lenta comparada con lo que están acostumbrados en apps nativas. Aquí es donde entran las SPA.

SPA (Single Page Application)

El frontend se carga una única vez y toda la interacción se gestiona desde JavaScript sin recargar la página. El servidor solo sirve archivos estáticos y la lógica vive completamente en el navegador.

Ejemplo típico: Una aplicación construida con Angular 4 + TypeScript que consume una API REST de Laravel o Node.js.

Las SPA resuelven la experiencia de usuario, pero crean un nuevo problema: el SEO. Google indexa el HTML que recibe, y si tu app solo devuelve un <div id="app"></div> vacío con un montón de JavaScript, los buscadores no ven nada. Para contenido que necesita aparecer en Google — blogs, tiendas, portafolios — necesitas que el HTML venga renderizado desde el servidor. Eso es SSR.

Server-Side Rendering (SSR)

Modelo donde el HTML se genera en el servidor para cada petición. Es el enfoque clásico que siguen PHP, Python/Django, Ruby on Rails y Java/Spring.

Tendencia en 2017: Next.js (React SSR, lanzado en 2016) está ganando tracción para combinar lo mejor de SPA y SSR.

El problema es que ni SSR ni SPA son perfectos por separado. SSR te da SEO pero pierdes la experiencia fluida de navegar sin recargas. SPA te da la experiencia pero pierdes el SEO. La solución que ha ganado terreno es combinar ambos: SSR para las primeras páginas que necesita Google, y SPA para la navegación posterior. Next.js popularizó este enfoque y hoy es el estándar.

Arquitectura híbrida (SSR + SPA)

Muchas aplicaciones modernas combinan ambos enfoques: SSR para las primeras páginas (SEO y rendimiento) y SPA para la navegación posterior (experiencia de usuario).

Ahora que entiendes los modelos de arquitectura, vamos a ver cómo se organizan las capas en una aplicación real. Porque da igual que elijas monolito o microservicios: siempre tendrás una capa que se comunica con el usuario, una que procesa la lógica, y una que guarda datos.

Capas de una arquitectura web típica en 2017

┌─────────────────────────────────┐
│          CLIENTE                │
│   (Navegador / App Móvil)       │
│   HTML + CSS + JavaScript       │
│   Angular / React / Vue.js      │
└──────────────┬──────────────────┘
               │ HTTP/HTTPS (JSON)
┌──────────────▼──────────────────┐
│        API / SERVIDOR           │
│   Node.js / Laravel / Django    │
│   Spring Boot / .NET Core       │
│   Lógica de negocio             │
└──────────────┬──────────────────┘
               │
┌──────────────▼──────────────────┐
│       BASE DE DATOS             │
│   MySQL / PostgreSQL / MongoDB  │
│   Redis (caché)                 │
│   Elasticsearch (búsqueda)      │
└─────────────────────────────────┘

Tecnologías dominantes en 2017

Estas son las herramientas que estaban definiendo el panorama en 2017. Algunas siguen siendo relevantes, otras han sido reemplazadas, pero entender qué había te ayuda a entender por qué las cosas son como son hoy.

Frontend:

Backend:

Infraestructura y bases de datos:

Patrones de diseño comunes en 2017

MVC, API REST, Repository y CQRS

• MVC (Model-View-Controller): El patrón más extendido. Separa la aplicación en tres componentes: Modelo (datos y lógica de negocio), Vista (interfaz) y Controlador (coordina ambos). Usado por Laravel, Django, Rails, Spring MVC.
• API REST: El estándar de comunicación entre frontend y backend. Recursos como URLs, operaciones con métodos HTTP (GET, POST, PUT, DELETE), datos en JSON.
• Repository Pattern: Abstrae el acceso a datos. La lógica de negocio no accede directamente a la BD sino a través de una interfaz que oculta la implementación.
• CQRS (Command Query Responsibility Segregation): Separa operaciones de lectura (query) de escritura (command). Cada una puede tener su propio modelo optimizado. Gana popularidad para sistemas complejos.

GET    /api/users/123      → Obtener usuario
POST   /api/users          → Crear usuario
PUT    /api/users/123      → Actualizar usuario
DELETE /api/users/123      → Eliminar usuario

Estos patrones resuelven problemas de organización del código. Pero hay otra tendencia en 2017 que ataca un problema diferente: acercar las web apps al rendimiento de las apps nativas.

Progressive Web Apps (PWA)

Una de las tendencias más fuertes de 2017. Las PWA combinan lo mejor de las web apps y las apps nativas:

• Service Workers: Permiten funcionar offline y cachear recursos
• Manifest.json: La web se puede “instalar” en el escritorio o móvil
• HTTPS obligatorio: Seguridad como requisito base
• Push Notifications: Notificaciones nativas desde el navegador

Ejemplos reales en 2017: Twitter Lite, Pinterest, Flipboard, OLX.

Las PWA mejoran la experiencia en el navegador, pero el problema de comunicación entre frontend y backend sigue ahí. REST funciona bien, pero cuando tu app necesita datos de 10 fuentes diferentes en una sola pantalla, terminas haciendo 10 peticiones. GraphQL propone una alternativa.

GraphQL vs REST

En 2017, GraphQL (creado por Facebook en 2012 y open-sourceado en 2015) empieza a ganar tracción como alternativa a REST:

Herramientas clave en 2017: Apollo (cliente GraphQL para React), GraphiQL (IDE para probar queries), Prisma (capa de acceso a BD para GraphQL).

Con todas estas opciones — arquitecturas, patrones, tendencias — la pregunta inevitable es: ¿cuál uso? La respuesta corta es “depende”, pero hay buenas prácticas que se aplican casi siempre.

Buenas prácticas en 2017

1. Separar frontend y backend mediante APIs REST claras
2. Usar contenedores Docker para entornos de desarrollo y producción consistentes
3. CI/CD automatizado con Jenkins, GitLab CI o Travis CI
4. Caché en Redis para datos que no cambian frecuentemente
5. HTTPS en todas partes — Let’s Encrypt ha facilitado enormemente la adopción de certificados gratuitos
6. Responsive design — Bootstrap o Flexbox para adaptar a móviles
7. Testing automatizado — Jest para JS, PHPUnit para PHP, pytest para Python

Conclusión

Si tuviera que resumir todo esto en una frase, sería: no hay arquitectura perfecta, hay arquitectura adecuada para cada momento. Un proyecto personal no necesita microservicios. Una app con millones de usuarios no puede ser un monolito simple. Y la mayoría de proyectos reales terminan híbridos, usando lo mejor de cada enfoque.

Lo que sí puedo decirte es que entender estas opciones — y saber cuándo usar cada una — es lo que separa a alguien que escribe código de alguien que construye sistemas. Y eso es algo que solo se aprende construyendo, equivocándose, y volviendo a leer sobre arquitectura cuando el proyecto se complica.

🧪 Comprobar que lo has entendido

• Identifica cada modelo: ante una frase como “todo en un solo proyecto” o “servicios independientes con su propia base de datos”, sabes de qué arquitectura habla.
• Relaciona tecnología y arquitectura: asocias Angular/React con SPA, PHP/Django/Rails con SSR, y Docker/Kubernetes con microservicios.
• Justifica la elección: puedes explicar por qué un proyecto pequeño encaja mejor en un monolito y uno grande con equipos separados en microservicios.

🪜 Siguiente nivel

Esta guía te da el mapa conceptual. El siguiente paso es ponerlo en práctica con código:

1. JavaScript de 0 a 100 — el lenguaje que mueve el frontend de casi todas estas arquitecturas: Guía de JavaScript: De 0 a 100.
2. TypeScript de 0 a 100 — tipado estático para tus apps SPA y APIs: Guía de TypeScript: De 0 a 100.
3. Docker de 0 a 100 — la base para desplegar monolito o microservicios de forma reproducible: Guía de Docker: De 0 a 100.
4. Servidor propio — lleva tu primera app a Internet: Cómo crear un servidor virtual con Apache.

🔗 Enlaces y recursos

• MDN — Guía de arquitecturas y patrones de aplicaciones web
• DigitalOcean — Community tutorials sobre arquitectura
• Documentación de Docker
• Documentación de React
• Documentación de Vue.js