Capítulo 22 — Introducción a Firebase Hosting¶
Recursos visuales propuestos¶
Antes de desarrollar este capítulo conviene seleccionar recursos visuales que realmente aporten comprensión. Los conceptos introductorios como qué es un CDN, el flujo básico de un usuario accediendo a una aplicación, la comparación entre hosting tradicional y Firebase Hosting, la distribución mundial de contenido y los tipos de aplicaciones compatibles se explican mejor con imágenes didácticas, porque su objetivo principal es ayudar al lector a construir intuición conceptual. En cambio, la arquitectura interna de Firebase Hosting, el flujo entre navegador, CDN y origen, la integración con Firestore, Authentication y Cloud Functions, y la infraestructura global del servicio requieren diagramas SVG, ya que involucran relaciones técnicas y secuencias entre múltiples componentes.[cite:1][cite:2]
Imágenes didácticas¶
- ¿Qué es un CDN? Conviene como imagen didáctica porque su función es explicar un concepto general de distribución de contenido de forma accesible.
- Flujo básico de un usuario accediendo a Firebase Hosting. Debe ser imagen didáctica porque ayuda a visualizar el recorrido principal sin entrar todavía en detalles profundos de arquitectura.
- Comparación entre hosting tradicional y Firebase Hosting. Es mejor como imagen didáctica porque permite contrastar modelos de entrega y administración de manera inmediata.
- Distribución mundial de contenido. Conviene como imagen didáctica porque refuerza visualmente la idea de edge locations y cercanía al usuario.
- Tipos de aplicaciones compatibles. Debe ser imagen didáctica porque clasifica casos de uso sin requerir un diagrama técnico complejo.
Diagramas SVG¶
- Arquitectura completa de Firebase Hosting. Debe resolverse como SVG porque combina despliegue, origen, edge cache, CDN y servicios complementarios.[cite:1]
- Flujo entre navegador, CDN y origen. Conviene SVG porque necesita mostrar resolución, cache hit, cache miss, consulta al origen y respuesta.
- Integración con Firestore, Authentication y Cloud Functions. Debe ser SVG porque describe cómo una aplicación alojada en Hosting consume el resto del ecosistema Firebase.[cite:1]
- Infraestructura global de Firebase Hosting. Debe ser SVG porque representa distribución mundial, edge servers, HTTPS y entrega desde la ubicación más cercana.[cite:1]
Objetivos de aprendizaje¶
Al finalizar este capítulo, el lector será capaz de:
- Comprender qué es Firebase Hosting y qué problemas resuelve dentro del despliegue de aplicaciones web modernas.[cite:1]
- Entender cómo funciona su arquitectura basada en CDN global, edge locations, caché y entrega segura por HTTPS.[cite:1][cite:2]
- Explicar qué ocurre desde que un usuario escribe una URL hasta que recibe una aplicación distribuida por Firebase Hosting.
- Identificar qué tipos de aplicaciones encajan mejor en Firebase Hosting y cómo se integra con el resto del ecosistema Firebase.[cite:1]
- Distinguir las ventajas y limitaciones del servicio frente a modelos de hosting tradicionales.
- Preparar conceptualmente el proyecto oficial del libro para los siguientes capítulos dedicados al despliegue.
Introducción¶
Después de construir autenticación, base de datos, almacenamiento y lógica de backend, llega una pregunta inevitable: ¿cómo se publica la aplicación para que cualquier usuario pueda acceder a ella desde Internet? En ese punto aparece Firebase Hosting como la pieza del ecosistema que se encarga de distribuir la aplicación web de forma rápida, segura y global.[cite:1]
La documentación oficial define Firebase Hosting como un servicio de hosting de contenido web de nivel de producción. También señala que, con un solo comando, es posible desplegar aplicaciones web a una CDN global, y que el servicio está optimizado para sitios estáticos y aplicaciones web de una sola página, aunque también puede integrarse con Cloud Functions o Cloud Run para contenido dinámico y microservicios.[cite:1] Esta definición es importante porque muestra dos ideas centrales. La primera: Hosting no es solo “un servidor donde subir archivos”. La segunda: Firebase Hosting no vive aislado, sino como una puerta de entrada al resto del ecosistema Firebase y Google Cloud.
Además, Firebase Hosting entrega el contenido siempre sobre conexiones seguras. La documentación indica que el servicio incluye SSL de configuración cero, provisiona certificados automáticamente para los dominios y distribuye el contenido desde el edge server más cercano dentro de su CDN global.[cite:1] Esta combinación de automatización, seguridad y distribución mundial es la razón por la que Firebase Hosting resulta tan atractivo para equipos que desean desplegar aplicaciones modernas sin administrar infraestructura compleja desde el primer día.
En este capítulo no se enseñará todavía a desplegar ni a configurar dominios personalizados. El objetivo es más importante desde el punto de vista formativo: comprender la arquitectura del servicio. Cuando el lector entienda cómo Hosting sirve contenido, cómo funciona el caché, qué significa CDN, por qué HTTPS viene integrado y cómo se relaciona con Firestore, Authentication, Cloud Storage y Cloud Functions, estará listo para publicar el proyecto del libro con criterio profesional.
Desarrollo completo¶
¿Qué es Firebase Hosting?¶
Firebase Hosting es el servicio del ecosistema Firebase diseñado para alojar y distribuir aplicaciones web, sitios estáticos, recursos frontend y, en combinación con otras piezas, contenido dinámico y microservicios.[cite:1]
Desde una perspectiva arquitectónica, Hosting resuelve la capa de entrega del frontend. Es decir, toma los archivos de la aplicación —HTML, CSS, JavaScript, imágenes, fuentes, manifiestos, íconos y otros recursos estáticos— y los sirve de forma segura y eficiente desde una red global de distribución de contenido.[cite:1]
No debe confundirse con un “hosting compartido” tradicional. En un hosting clásico, el equipo suele pensar en un servidor específico, una máquina, una carpeta web y una configuración manual del entorno. En Firebase Hosting, la abstracción es diferente: se publica una versión del sitio y la infraestructura administrada se encarga de distribuirla a través de la CDN.
¿Qué problemas resuelve?¶
Firebase Hosting resuelve varios problemas habituales del despliegue web moderno:
- distribuir contenido estático cerca del usuario final;
- servir la aplicación por HTTPS sin administrar certificados manualmente;
- facilitar despliegues y actualizaciones rápidas;
- integrarse con el resto del backend sin necesidad de montar un servidor web clásico;
- ofrecer alta disponibilidad y rendimiento sin operar infraestructura propia.[cite:1]
Para un desarrollador que viene del mundo del frontend o del backend sin experiencia fuerte en operaciones, esto reduce enormemente la complejidad inicial.
¿Por qué utilizar Firebase Hosting?¶
Porque combina simplicidad operativa con una arquitectura sólida para aplicaciones modernas. La documentación oficial resalta varias capacidades clave: entrega sobre conexión segura, distribución rápida mediante una CDN global, compresión automática con gzip o Brotli, despliegue de nuevas versiones con un solo comando y posibilidad de integración con Cloud Functions o Cloud Run para contenido dinámico.[cite:1]
Dicho de forma más simple: Hosting permite concentrarse en la aplicación y no en administrar servidores web, certificados, proxy inversos, balanceadores o distribución internacional desde el primer despliegue.
Casos de uso¶
Firebase Hosting encaja especialmente bien en:
- sitios estáticos;
- landing pages;
- Progressive Web Apps;
- paneles administrativos;
- aplicaciones SPA en React, Vue, Angular o Svelte;
- frontends que consumen Firestore, Authentication y Storage;
- experiencias híbridas que combinan frontend estático y rutas dinámicas con Functions o Cloud Run.[cite:1]
Arquitectura¶
Relación entre Firebase Hosting y Google Cloud¶
Firebase Hosting no es una infraestructura paralela separada de Google Cloud. Es una capa de producto orientada a desarrolladores que simplifica el despliegue y administración de contenido web sobre infraestructura global administrada por Google.
La documentación oficial explica que cada archivo subido se almacena y distribuye desde la CDN global del servicio, y que todo el contenido se entrega desde el edge server más cercano al usuario.[cite:1] Esto implica que Hosting se apoya en una red mundial de infraestructura administrada y no en un único servidor central.
CDN global¶
Una CDN, o red de distribución de contenido, es una red de servidores distribuidos geográficamente que entregan contenido desde ubicaciones cercanas al usuario final. En vez de hacer que todas las personas del mundo soliciten la aplicación al mismo origen central, la CDN acerca copias cacheadas del contenido al borde de la red.
Firebase Hosting usa una CDN global para servir los archivos desplegados.[cite:1][cite:2] Esto reduce latencia, mejora tiempos de carga y disminuye dependencia de un único punto geográfico para la entrega de contenido.
Edge Locations¶
Las edge locations son los puntos distribuidos de la CDN desde los cuales se entrega el contenido. La documentación oficial describe que los archivos se sirven desde el edge server más cercano al usuario.[cite:1] En términos prácticos, esto significa que una persona en México, España o Argentina no necesita esperar a que el archivo viaje desde un único servidor central lejano si ese recurso ya está disponible en el edge apropiado.
Servidores distribuidos¶
Hablar de Firebase Hosting como “servidores distribuidos” ayuda a comprender que la aplicación no depende de una sola máquina web. Cuando el contenido está cacheado en múltiples edges, la entrega se vuelve más resiliente y rápida.
Este modelo es muy distinto del hosting tradicional donde a menudo se suben archivos a un solo servidor o a un pequeño conjunto de nodos administrados manualmente.
HTTPS automático¶
La documentación oficial es muy clara: Firebase Hosting incluye SSL de configuración cero, de modo que el contenido siempre se sirve de forma segura.[cite:1] Esto significa que el desarrollador no tiene que comprar, instalar ni renovar manualmente certificados solo para comenzar a servir su aplicación por HTTPS.
Certificados SSL¶
Además del SSL por defecto, Firebase provisiona automáticamente certificados para los dominios conectados al sitio, de modo que todo el contenido se entregue de forma segura.[cite:1] Este punto es extremadamente valioso porque elimina una de las tareas operativas más tediosas y propensas a error en despliegues web tradicionales.
HTTP/2¶
Firebase Hosting soporta protocolos modernos de transporte y entrega. Aunque la página principal enfatiza más claramente la conexión segura y la CDN, la plataforma se orienta a servir contenido moderno con alto rendimiento y buenas prácticas actuales de red. En este contexto, HTTP/2 forma parte de la evolución natural de los servicios de hosting modernos y contribuye a una entrega más eficiente de múltiples recursos.
HTTP/3¶
En el mismo sentido, Firebase Hosting se alinea con la infraestructura moderna de entrega web. Para el lector, lo importante en este punto no es memorizar internals de protocolo, sino entender la consecuencia arquitectónica: el servicio está diseñado para entregar aplicaciones modernas usando tecnologías de red actuales orientadas a velocidad, seguridad y resiliencia.
Compresión automática¶
La documentación oficial explica que cada archivo se cachea en SSDs en los edges de la CDN y se sirve como gzip o Brotli, seleccionando automáticamente el mejor método de compresión según el contenido.[cite:1] Esta característica tiene impacto directo en rendimiento porque reduce el peso transferido al navegador sin exigir configuración manual inicial.
Funcionamiento¶
¿Qué ocurre cuando un usuario visita una aplicación?¶
Cuando un usuario escribe la URL de una aplicación alojada en Firebase Hosting, comienza un flujo que puede resumirse así:
- El navegador resuelve el dominio.
- La solicitud llega a la infraestructura de Hosting.
- La CDN determina el edge adecuado.
- Si el contenido está cacheado, el edge lo devuelve directamente.
- Si no lo está, el edge obtiene el contenido desde el origen apropiado y luego lo sirve.
- El navegador recibe HTML, CSS, JavaScript y recursos asociados.
- La aplicación frontend inicia y comienza a interactuar con Firestore, Authentication, Storage u otros servicios.
Este flujo es importante porque muestra que Hosting no “ejecuta” el frontend en el servidor; lo distribuye al navegador, que luego ejecuta la aplicación del lado cliente.
Resolución DNS¶
La resolución DNS es el paso mediante el cual el navegador descubre a qué infraestructura debe dirigir la solicitud del dominio. Aunque el lector no necesita dominar DNS avanzado todavía, sí conviene saber que el primer paso para llegar a Hosting no es el contenido en sí, sino la localización del servicio que lo entregará.
CDN¶
Una vez resuelto el dominio, la CDN entra en acción. La documentación oficial indica que Firebase Hosting sirve el contenido desde el edge server más cercano al usuario y que todo el contenido está respaldado por una CDN global.[cite:1]
Caché¶
El comportamiento de caché es uno de los aspectos más importantes del servicio. La documentación oficial sobre manejo de caché indica que todo contenido estático solicitado se almacena automáticamente en la CDN, y que cuando se vuelve a desplegar el sitio, Firebase Hosting limpia automáticamente el contenido cacheado a través de la CDN hasta la siguiente solicitud.[cite:2]
Este detalle es esencial para entender por qué los despliegues no requieren “vaciar cache manualmente” como suele ocurrir en sistemas más artesanales.
Además, para contenido dinámico servido por Cloud Functions o Cloud Run, la documentación aclara que no se cachea en la CDN por defecto, aunque puede configurarse mediante encabezados Cache-Control.[cite:2] Esto muestra una diferencia importante entre contenido estático y dinámico.
Entrega del contenido¶
La entrega del contenido depende del tipo de recurso:
- el HTML inicial puede venir del edge;
- los archivos JS y CSS también pueden servirse desde la CDN;
- imágenes, fuentes y manifest se entregan del mismo modo si forman parte del sitio desplegado;
- llamadas posteriores a Firestore, Authentication o Storage ya dependen de esos servicios y no de Hosting.
En otras palabras, Hosting entrega la aplicación; la aplicación luego consume el backend.
Actualizaciones¶
La documentación oficial indica que, usando la CLI, se despliegan nuevas versiones del sitio con un solo comando y que Hosting permite revertir con un clic desde la consola si hace falta.[cite:1] Aunque los despliegues se estudiarán después, aquí interesa entender la arquitectura general: el contenido publicado es una instantánea versionada del estado del sitio en ese momento.
Versionado interno¶
Cada despliegue representa una versión del sitio. Esto permite que el servicio gestione cambios, invalidación de caché y rollback. Para el lector, la idea más importante es que Hosting no funciona como “copiar archivos sueltos a un FTP”, sino como publicar snapshots controlados de una aplicación.
Tipos de aplicaciones¶
Sitios estáticos¶
Firebase Hosting es especialmente fuerte en sitios estáticos. La documentación oficial y el quickstart destacan que el servicio aloja activos estáticos como HTML, CSS, JavaScript y archivos multimedia de manera rápida, segura y confiable.[cite:1][cite:3]
SPA (Single Page Applications)¶
La documentación principal afirma explícitamente que Hosting está optimizado para aplicaciones web de una sola página.[cite:1] Esto lo vuelve ideal para frontend modernos que cargan una shell inicial y luego gestionan navegación del lado cliente.
Aplicaciones Vue¶
Las aplicaciones Vue basadas en build estático encajan muy bien en Hosting porque el resultado final suele ser un conjunto de archivos estáticos distribuidos por la CDN. Lo importante aquí no es el framework específico, sino el tipo de artefacto generado al compilar.
Aplicaciones React¶
React es uno de los casos más comunes para Firebase Hosting. Una SPA React compilada produce archivos estáticos que Hosting entrega eficientemente a escala global. Además, el frontend React puede consumir sin fricción Firestore, Authentication y Storage desde el navegador.
Aplicaciones Angular¶
Angular también encaja naturalmente cuando su salida es estática o pre-renderizada. Hosting se vuelve especialmente cómodo porque el equipo puede desplegar el resultado del build sin preocuparse por un servidor tradicional para los activos frontend.
Aplicaciones Svelte¶
Las aplicaciones Svelte o SvelteKit con salida estática siguen el mismo patrón. Siempre que el resultado final sea servible como frontend estático o híbrido con integración backend, Firebase Hosting es un candidato fuerte.
Flutter Web¶
Flutter Web genera una aplicación web compilada que puede publicarse como activos estáticos. Por eso Firebase Hosting resulta una alternativa muy natural para exponerla rápidamente con HTTPS y CDN global.
Aplicaciones híbridas¶
La documentación oficial recuerda que, además del contenido estático, Firebase Hosting puede combinarse con Cloud Functions o Cloud Run para servir contenido dinámico y microservicios.[cite:1] Esto permite arquitecturas híbridas donde el frontend se distribuye por la CDN y ciertas rutas o capacidades se resuelven mediante backend.
Integración¶
Firestore¶
Una aplicación alojada en Firebase Hosting puede usar Firestore desde el cliente para lectura y escritura de datos según las reglas correspondientes. Hosting no reemplaza la base de datos; la expone al mundo en forma de aplicación accesible desde navegador.
Authentication¶
Del mismo modo, la interfaz servida por Hosting puede autenticar usuarios mediante Firebase Authentication. Esto significa que una misma app alojada en Hosting puede presentar formularios, iniciar sesión, mantener estado autenticado y acceder a recursos protegidos del ecosistema.
Cloud Storage¶
Las aplicaciones servidas desde Hosting también pueden mostrar imágenes, documentos y recursos multimedia alojados en Cloud Storage. De nuevo, Hosting actúa como capa de entrega del frontend, mientras Storage resuelve el binario y Firestore describe el contexto documental.
Cloud Functions¶
La documentación oficial indica que Firebase Hosting puede combinarse con Cloud Functions para servir contenido dinámico y microservicios.[cite:1] Esto permite enrutar determinadas solicitudes a backend sin salir del entorno Firebase.
App Hosting (introducción)¶
La documentación principal de Hosting ya hace referencia a Firebase App Hosting como otra opción dentro del ecosistema, especialmente orientada a ciertas experiencias modernas de frameworks y despliegue más integrado.[cite:1] En este capítulo basta con entender que App Hosting existe como evolución o complemento para ciertos escenarios y que se estudiará más adelante.
Ventajas¶
Velocidad¶
Firebase Hosting entrega archivos desde una CDN global, con caché en SSDs de edge y compresión automática gzip o Brotli.[cite:1] Esto se traduce en tiempos de carga rápidos y buena experiencia para usuarios distribuidos geográficamente.
Seguridad¶
Todo el contenido se sirve sobre HTTPS con SSL de configuración cero y certificados provisionados automáticamente para los dominios conectados.[cite:1] Eso eleva el nivel de seguridad base desde el primer despliegue.
Escalabilidad¶
Al apoyarse en infraestructura global y CDN, Hosting evita que el frontend dependa de un único servidor que deba escalarse manualmente. La distribución de contenido está diseñada para cargas globales y picos de tráfico propios de aplicaciones web modernas.[cite:1]
Disponibilidad¶
La arquitectura distribuida contribuye a una alta disponibilidad percibida. Un usuario no depende de la cercanía a una sola máquina, sino de la capacidad de la red global para servir el contenido desde un edge adecuado.
Costos¶
Firebase Hosting resulta muy atractivo en costo-beneficio para muchos proyectos porque simplifica operaciones, elimina tareas de infraestructura y ofrece planes adecuados para comenzar y crecer. Aunque el análisis detallado de costos se profundizará después, aquí importa entender que buena parte del ahorro proviene de reducir complejidad operativa.
Limitaciones¶
Qué puede hacer¶
Firebase Hosting puede servir contenido estático de forma excelente, hospedar SPAs, soportar PWAs, aplicar headers y rewrites ligeros, y actuar como capa frontal combinada con Functions o Cloud Run para contenidos dinámicos.[cite:1][cite:2]
Qué no puede hacer¶
No debe confundirse con un servidor de ejecución arbitraria del backend tradicional. El frontend alojado en Hosting no ejecuta código servidor por sí solo. Si la aplicación necesita lógica dinámica del lado servidor, debe integrarse con Cloud Functions, Cloud Run u otra pieza adecuada.[cite:1]
Casos donde conviene otra alternativa¶
Si un proyecto requiere SSR complejo, entornos full-stack más integrados o patrones muy específicos de frameworks modernos, en algunos casos puede convenir evaluar App Hosting, Cloud Run u otras alternativas del ecosistema Google según la arquitectura concreta. La decisión no es “Firebase Hosting o nada”, sino elegir la pieza adecuada para cada tipo de entrega.
Casos reales¶
Portal institucional¶
Un portal institucional con páginas informativas, formularios básicos y autenticación para ciertas áreas privadas encaja perfectamente en Hosting. El contenido público se distribuye rápido a nivel mundial y la parte autenticada puede conectarse con Authentication y Firestore.
Panel administrativo¶
Un panel administrativo SPA para la plataforma educativa del libro es un caso natural. React, Vue o Angular pueden compilar a activos estáticos y ser distribuidos por Hosting mientras consumen backend Firebase.
Plataforma educativa del libro¶
En el proyecto transversal, la aplicación web futura reunirá varios servicios ya estudiados:
- Authentication para acceso de administradores, docentes, alumnos y padres.
- Firestore para datos académicos y operativos.
- Cloud Storage para credenciales, documentos, evidencias y multimedia.
- Cloud Functions para procesos sensibles o automatizaciones.
Firebase Hosting será la capa que exponga esa aplicación a Internet, permitiendo que todos esos servicios queden disponibles desde una sola experiencia web coherente.
Comparaciones técnicas¶
Hosting tradicional vs Firebase Hosting¶
| Aspecto | Hosting tradicional | Firebase Hosting |
|---|---|---|
| Infraestructura | Suele centrarse en uno o pocos servidores | CDN global con edge servers distribuidos [cite:1] |
| HTTPS | A menudo requiere configuración manual | SSL automático y certificados provisionados por Firebase [cite:1] |
| Despliegue | Frecuentemente manual o por FTP | Snapshot desplegable con CLI [cite:1][cite:3] |
| Caché | A menudo requiere configuración adicional | Caché automática para contenido estático en CDN [cite:2] |
| Integración con backend | Generalmente desacoplada o manual | Integración natural con Functions, Firestore, Auth y Storage [cite:1] |
Sitio estático vs aplicación híbrida¶
| Tipo | Qué entrega Hosting | Cuándo usar |
|---|---|---|
| Sitio estático | HTML, CSS, JS, imágenes y assets cacheados [cite:1] | Landing pages, portales, documentación |
| SPA | Shell frontend + recursos cliente [cite:1] | Paneles, apps React/Vue/Angular |
| Híbrida | Frontend estático + rutas dinámicas con Functions/Cloud Run [cite:1][cite:2] | Apps con SSR parcial o microservicios |
Buenas prácticas¶
- Organizar claramente el frontend y los recursos públicos antes del despliegue.
- Optimizar imágenes, fuentes y bundles para aprovechar realmente la CDN.
- Pensar el caché como parte de la arquitectura y no como un detalle posterior.[cite:2]
- Separar lo que pertenece al frontend estático de lo que debe resolverse en backend.
- Mantener una estructura de proyecto preparada para integrar Hosting con el resto del ecosistema Firebase.
- Entender qué recursos serán cacheables y cuáles requerirán comportamiento dinámico.
Errores comunes¶
- Pensar que Firebase Hosting es solo “subir un index.html”.
- Confundir hosting de frontend con ejecución de backend del lado servidor.
- Ignorar el papel del caché y luego sorprenderse por comportamiento de contenido dinámico.[cite:2]
- No distinguir entre activos estáticos y rutas que deberían resolverse con Functions o Cloud Run.
- Asumir que una SPA y un sitio estático simple tienen exactamente las mismas necesidades de configuración.
- Descuidar la optimización de assets aunque la CDN exista.
Resumen¶
Firebase Hosting es el servicio de Firebase orientado a alojar y distribuir aplicaciones web y contenido estático con una experiencia de despliegue simple y una infraestructura de producción global.[cite:1] La documentación oficial destaca que el servicio distribuye el contenido a través de una CDN mundial, entrega cada archivo desde el edge server más cercano, comprime automáticamente con gzip o Brotli y sirve todo mediante HTTPS con SSL de configuración cero.[cite:1]
Desde el punto de vista arquitectónico, Firebase Hosting resuelve la capa de entrega del frontend y se integra naturalmente con el resto del ecosistema. La aplicación que recibe el usuario en el navegador puede usar Authentication, Firestore, Cloud Storage y Cloud Functions sin que el equipo tenga que construir primero una plataforma de hosting propia.[cite:1]
Su modelo también simplifica operaciones. El comportamiento automático de caché para contenido estático, la invalidación del contenido desplegado al publicar nuevas versiones y la posibilidad de combinar recursos estáticos con backend dinámico hacen de Hosting una plataforma muy sólida para sitios modernos y aplicaciones SPA.[cite:2] En el proyecto del libro, será la puerta de entrada pública que pondrá en Internet todo lo que se ha construido en capítulos anteriores.
Conceptos clave¶
- Firebase Hosting.[cite:1]
- CDN global.[cite:1]
- Edge server.[cite:1]
- HTTPS automático.[cite:1]
- SSL de configuración cero.[cite:1]
- Certificados automáticos.[cite:1]
- Caché CDN.[cite:2]
Cache-Control.[cite:2]- Compresión Brotli y gzip.[cite:1]
- Sitio estático.
- SPA.[cite:1]
- Aplicación híbrida.[cite:1]
- Integración con Cloud Functions.[cite:1]
- Rollback.
- Snapshot de despliegue.
Preguntas de repaso¶
- ¿Qué es Firebase Hosting y qué papel cumple dentro del ecosistema Firebase?[cite:1]
- ¿Por qué una CDN mejora el rendimiento de una aplicación web moderna?[cite:1][cite:2]
- ¿Qué significa que el contenido se entregue desde el edge server más cercano?[cite:1]
- ¿Qué ventajas ofrece el SSL automático de Firebase Hosting?[cite:1]
- ¿Qué diferencias existen entre el contenido estático y el contenido dinámico dentro del modelo de Hosting?[cite:1][cite:2]
- ¿Por qué las aplicaciones SPA encajan tan bien en Firebase Hosting?[cite:1]
- ¿Qué ocurre con el caché del contenido estático cuando se publica una nueva versión del sitio?[cite:2]
- ¿Cómo se integra Firebase Hosting con Firestore, Authentication, Storage y Functions?
- ¿Qué limitaciones tiene Hosting frente a un backend tradicional?
- ¿Por qué el proyecto del libro necesita Firebase Hosting para completar su arquitectura web?
Ejercicios prácticos¶
- Dibuja conceptualmente el flujo completo desde que un usuario escribe la URL hasta que se ejecuta una SPA alojada en Firebase Hosting.
- Clasifica qué partes del proyecto del libro pertenecerán al frontend servido por Hosting y cuáles pertenecerán a otros servicios.
- Compara un despliegue tradicional basado en un solo servidor con un despliegue sobre Firebase Hosting y CDN global.
- Diseña una propuesta de organización del frontend de la plataforma educativa pensando en su futura publicación.
- Analiza qué recursos del sistema deberían aprovechar mejor el caché y cuáles requerirán comportamiento dinámico.[cite:2]
- Explica cómo se beneficiaría una aplicación Flutter Web al publicarse en Firebase Hosting.
- Identifica tres escenarios donde podría convenir combinar Hosting con Cloud Functions.
- Redacta una explicación breve para un cliente no técnico sobre por qué Hosting mejora velocidad y seguridad respecto a un hosting simple.
Bibliografía y referencias oficiales¶
- Firebase Hosting: https://firebase.google.com/docs/hosting [cite:1]
- Manage cache behavior | Firebase Hosting: https://firebase.google.com/docs/hosting/manage-cache [cite:2]
- Get started with Firebase Hosting: https://firebase.google.com/docs/hosting/quickstart [cite:3]