Problemas comunes del hosting de Firebase y soluciones

  • Por
Cómo configurar correctamente apps para alojar en el hosting de Firebase para evitar problemas, centrándonos en las aplicaciones SPA (Single Page Application) y Polymer.

En este artículo vamos a revisar los problemas más comunes que he tenido que resolver con aplicaciones alojadas en el hosting de Firebase. Mi experiencia con Firebase ha sido principalmente para alojar apps realizadas con Polymer, pero estoy seguro que algunos de estos consejos van a ser relevantes para otros frameworks.

Firebase ofrece un servicio de hosting gratuito, en el que podemos además asociar nuestro propio nombre de dominio. El dominio en sí no lo puedes registrar con Firebase, sino que usas un proveedor de hosting de tu preferencia para registrarlo, pero lo que es el alojamiento de los archivos y el servidor para transferirlos es gratuito (con unos límites de transferencia y espacio en disco). Eso sí, sólo funciona con ficheros estáticos, por lo que no admite programación del lado del servidor (algo que tampoco es relevante ya que el propio Firebase nace para apoyarte con las cosas que harías en el backend).

Nota: Firebase es un excelente servicio de Google para el desarrollo de aplicaciones de todo tipo, web, mobile… incluso programas del lado del servidor y propósito general. La gracia de Firebase es que puedes desarrollar en el lado del cliente características que harías del lado del servidor, como acceso a base de datos, sistema de almacenamiento, notificaciones, etc. Encuentra información completa para aprender Firebase en el Manual de Firebase.

Configurar el hosting como SPA

Al hacer el "firebase init" desde la línea de comandos para generar tu proyecto Firebase una de las cosas que te pregunta es si quieres que Firebase se configure como SPA. Ojo a esta configuración pues para determinados tipos de proyectos no sería útil. Si la pones todas las solicitudes de páginas se dirigirán hacia el index.html y si tu aplicación está dispersa en varias URL diferentes te podrá dar un problema.

Service Worker

Las aplicaciones actualmente es cada vez más común que tengan un service worker, que se instala de manera residente en el navegador para realizar distintos tipos de operativas, incluso si tu página no está abierta en un momento dado.

El service worker, entre sus diversas funcionalidades, nos permite realizar un cacheo de páginas, de modo que cuando se solicitan te la ofrecen directamente de memoria, en lugar de ir a por ella al servidor. Un problema habitual es que tu service worker esté por el medio haciendo trabajo y al final ocurran cosas que no esperabas.

El service worker es muy normal que no se cree automáticamente. Por ejemplo en Polymer tenemos el archivo "sw-precache-config.js" que nos permite indicar la configuración sobre el service worker que se va a generar para el cacheo de contenido.

Ese archivo se basa en el paquete Service Worker Precache (sw-precache) que es el generador del service worker en si, en función de lo declarado en "sw-precache-config.js". Tienes que prestar especial atención a esta configuración para ahorrarte problemas.

Rutas de autenticación devuelven a la home de Firebase

Este es uno de los síntomas del problema de una mala configuración del archivo "sw-precache-config.js". Lo que ocurre es que al usar conectores sociales para la autenticación con Google, Twitter, Facebook o Github, existe una url de callback en tu espacio de hosting, a la que vuelven los proveedores de oAuth cuando autorizan el acceso a la cuenta para una app.

Esa URL de callback es algo como esto: https://tu_app_firebase.firebaseapp.com/_/auth

Si tienes activado un service worker puede ocurrir que esa URL esté direcionada al index y por tanto te muestre tu home, entregando el index.html cacheado, en lugar de la página de callback. Es algo que está explicado y resuelto en esta issue de Github.

Básicamente la librería sw-precache es capaz de entregar el archivo de index.html ante las rutas no cacheadas. Eso se configura con la propiedad del "sw-precache-config.js"

navigateFallback: '/index.html'
Nota: En una app de Polymer ya viene configurado así el precache config, al menos cuando trabajas con el Polymer Starter Kit 2. Pero el propio sw-precache lo podrías usar de manera similar en cualquier tipo de proyecto, porque simplemente sirve para crear genéricamente service workers para cacheo y no está asociado específicamente a la librería Polymer.

La solución pasa por configurar el "sw-precache-config.js", en el que podemos asociar una "lista blanca" de URLs que se van a cachear. Las otras que no se indiquen no se cachearán. El trabajo por tanto es indicar todos los puntos de entrada de tu aplicación para que se cacheen sirviendo el correspondiente index.html. Los demás no se mostrarán a través del index.html.

Eso se hace con el array "navigateFallbackWhitelist", que permite indicarle una lista de URL con expresiones regulares. Podría ser algo como esto:

navigateFallbackWhitelist: [
    /^\/home\//, 
    /^\/contacto\//, 
    /^\/servicio\//, 
    /^\/admin\//,
  ]

Dependencias de la aplicación Polymer

Este sí que es un posible error que encontrarás con apps Polymer únicamente, realmente en apps donde estás usando el proceso de build del Polymer CLI.

Para que el proceso de build funcione correctamente tienes que asegurarte de configurar todas las librerías externas que estés usando en "includeDependencies". Esa configuración la encuentras en el archivo "polymer.json". Dicho de otra manera, que lo tengas tus dependencias a librerías JS externas en bower_components no te asegura que se haya incluido en el build.

Nota: Este problema de dependencias que no se incluyen en el build puede ocurrir con dependencias que se cargan de manera lógica, ante determinadas situaciones. Por ejemplo, el archivo "webcomponents-lite.min.js" solo se carga si tu navegador no tiene soporte a Web Components, por lo que se tendrá que evaluar cierto código y si no se cumple la condición se creará el script correspondiente con ese archivo. Si la etiqueta SCRIPT estuviera escrita "a fuego" en tu código, esto no pasaría.

Por ejemplo podrías tener un includeDependencies como este:

"includeDependencies": [
    "manifest.json",
    "firebase-messaging-sw.js",
    "bower_components/webcomponentsjs/webcomponents-lite.min.js",
    "bower_components/app-storage/app-indexeddb-mirror/app-indexeddb-mirror-worker.js",
  ]

El servicio https no funciona con mi dominio personalizado

Este error me ha surgido con dominios recién instalados. Cuando entras por https:// no te funciona bien. Firebase te dice que está todo bien configurado y realmente sí te sirven los archivos, pero te salen errores de seguridad en el navegador, como que la página no es segura.

Simplemente hay que esperar unas horas y está todo resuelto... Irse a dormir y al día siguiente lo tendrás. Por ello, si tienes tiempos de entrega, es bueno que te asegures de configurar el dominio personalizado días antes de entregar tu proyecto, para dar tiempo a que se generen los certificados SSL para tu dominio personalizado.