Cómo compilar varias apps web progresivas en el mismo dominio

Cómo compilar varias AWP, aprovechando el mismo nombre de dominio, para que el usuario sepa que pertenecen a la misma organización o servicio

Chase Phillips

Demián Renzulli

Matt Giuca

En la entrada de blog sobre apps web progresivas en sitios de varios orígenes, Demian analizó los desafíos que enfrentan los sitios compilados en varios orígenes cuando intentan compilar una sola app web progresiva que los incluya a todos.

Un ejemplo de este tipo de arquitectura de sitio es un sitio de comercio electrónico en el que ocurre lo siguiente:

• La página principal está en https://www.example.com.
• Las páginas de categorías se alojan en https://category.example.com.
• Las páginas de detalles del producto en https://product.example.com.

Como se explica en el artículo, la política de mismo origen impone varias restricciones que evitan el uso compartido de service workers, cachés y permisos entre orígenes. Por ese motivo, te recomendamos que evites este tipo de configuración y que, si ya tienes sitios compilados de esta manera, consideres migrar a una arquitectura de sitio de origen único siempre que sea posible.

Evita usar orígenes diferentes para secciones de un mismo sitio cuando intentes compilar una app web progresiva unificada.

En esta publicación, analizamos el caso contrario: en lugar de una sola AWP de distintos orígenes, analizaremos el caso de las empresas que desean proporcionar varias AWP, aprovechando el mismo nombre de dominio y hacer saber al usuario que esas AWP pertenecen a la misma organización o servicio.

Como habrás notado, usamos términos diferentes, pero interrelacionados, como dominios y orígenes. Antes de continuar, repasemos estos conceptos.

Términos técnicos

• Dominio: cualquier secuencia de etiquetas según se define en el sistema de nombres de dominio (DNS). Por ejemplo, com y example.com son dominios.
• Nombre de host: Es una entrada de DNS que se resuelve en, al menos, una dirección IP. Por ejemplo: www.example.com sería un nombre de host, example.com podría ser un nombre de host si tuviera una dirección IP y com nunca se resolvería en una dirección IP, por lo que nunca podría ser un nombre de host.
• Origin: Es una combinación de un esquema, un nombre de host y un puerto (opcionalmente). Por ejemplo, https://www.example.com:443 es un origen.

Como su nombre lo indica, la política de mismo origen impone restricciones en los orígenes, por lo que nos referiremos al término principalmente en todo el artículo. Sin embargo, ocasionalmente, utilizaremos "dominios" o "subdominios" para describir la técnica que se utiliza y crear los diferentes "orígenes".

El caso de varias AWP relacionadas

En algunos casos, es posible que desees compilar apps independientes, pero que aun así las identifiques como pertenecientes a la misma organización o “marca”. Volver a usar el mismo nombre de dominio es una buena manera de establecer esa relación. Por ejemplo:

• En un sitio de comercio electrónico, se quiere crear una experiencia independiente para permitir que los vendedores administren su inventario y, a la vez, asegurarse de que comprenden que pertenece al sitio web principal donde los usuarios compran productos.
• Un sitio de noticias sobre deportes quiere compilar una app específica para un evento deportivo importante para permitir que los usuarios reciban estadísticas sobre sus competencias favoritas a través de notificaciones y, luego, instalarla como una app web progresiva, a la vez que se asegure de que los usuarios la reconozcan como una app creada por la empresa de noticias.
• Una empresa quiere compilar apps de chat, correo y calendario separadas, y quiere que funcionen como apps individuales, vinculadas al nombre de la empresa.

La empresa propietaria de example.com quiere proporcionar tres apps o AWP independientes que utilicen el mismo nombre de dominio para establecer la relación entre ellas.

Usa orígenes distintos

El enfoque recomendado en casos como estos es que cada app conceptualmente distinta se publique en su propio origen.

Si quieres usar el mismo nombre de dominio dentro de todos, puedes hacerlo con subdominios. Por ejemplo, una empresa que proporciona varias apps o servicios de Internet puede alojar una app de correo electrónico en https://mail.example.com y una app de calendario en https://calendar.example.com, mientras ofrece el servicio principal de su negocio en https://www.example.com. Otro ejemplo es un sitio de deportes que quiere crear una app independiente dedicada completamente a un evento deportivo importante, como un campeonato de fútbol en https://footballcup.example.com, que los usuarios pueden instalar y usar independientemente del sitio deportivo principal, alojado en https://www.example.com. Este enfoque también puede ser útil para las plataformas que permiten a los clientes crear apps independientes bajo la marca de la empresa. Por ejemplo, una app que permita a los comercios crear sus propias AWP en https://merchant1.example.com, https://merchant2.example.com, etcétera.

El uso de orígenes diferentes garantiza el aislamiento entre las apps, lo que significa que cada una de ellas puede administrar diferentes funciones del navegador de manera independiente, incluidas las siguientes:

• Capacidad de instalación: Cada app tiene su propio manifiesto y proporciona su propia experiencia instalable.
• Almacenamiento: Cada app tiene sus propias cachés, almacenamiento local y, básicamente, todas las formas de almacenamiento local del dispositivo, sin compartirlos con las demás.
• Service Workers: cada app tiene su propio service worker para los permisos registrados.
• Permisos: Los permisos también se definen en función de los orígenes. Gracias a eso, los usuarios sabrán exactamente a qué servicio están dando permisos y funciones como las notificaciones se atribuirán correctamente a cada app.

Crear un grado de aislamiento de este tipo es lo más conveniente en el caso práctico de varias AWP independientes, por lo que recomendamos este enfoque.

Si las apps en subdominios desean compartir datos locales entre sí, aún podrán hacerlo mediante cookies o, en situaciones más avanzadas, podrían considerar sincronizar el almacenamiento a través de un servidor.

Se recomienda compilar diferentes AWP en orígenes distintos mediante el uso de subdominios.

Usa el mismo origen

El segundo enfoque es compilar las diferentes AWP en el mismo origen. Esto incluye las siguientes situaciones:

Rutas no superpuestas

Varias AWP o “apps web” conceptuales, alojadas en el mismo origen, con rutas sin superposición. Por ejemplo:

• https://example.com/app1/
• https://example.com/app2/

Rutas superpuestas o anidadas

Varias AWP en el mismo origen, una de cuyo alcance está anidado dentro de la otra:

• https://example.com/ (la "app externa")
• https://example.com/app/ (la "app interior")

La API de service worker y el formato del manifiesto te permiten realizar cualquiera de las acciones anteriores, mediante el alcance a nivel de ruta de acceso. Sin embargo, en ambos casos, usar el mismo origen presenta muchos problemas y limitaciones cuya raíz se debe al hecho de que el navegador no las considerará "apps" distintas, por lo que no se recomienda este enfoque.

No se recomienda usar rutas de acceso (superpuestas o no) para proporcionar dos AWP independientes ("app1", "app2") con el mismo origen.

En la siguiente sección, analizaremos estos desafíos con más detalle y qué se puede hacer si no es posible usar orígenes distintos.

Desafíos para múltiples AWP de mismo origen

A continuación, se incluyen algunos problemas prácticos comunes de ambos enfoques del mismo origen:

• Almacenamiento: Las cookies, el almacenamiento local y todas las formas de almacenamiento local del dispositivo se comparten entre las apps. Por ese motivo, si el usuario decide limpiar los datos locales de una app, se borrarán todos los datos del origen. No hay manera de hacerlo para una sola app. Ten en cuenta que Chrome y otros navegadores le pedirán de forma activa a los usuarios que borren los datos locales cuando desinstalen una de las apps, lo que también afectará los datos de las otras apps del origen. Otro problema es que las apps también tendrán que compartir su cuota de almacenamiento, lo que significa que, si alguna de ellas ocupa demasiado espacio, la otra se verá afectada de forma negativa.
• Permisos: Los permisos están vinculados al origen. Esto significa que, si el usuario otorga un permiso a una app, este se aplicará a todas las apps de ese origen de forma simultánea. Esto puede parecer algo bueno (no tener que solicitar un permiso varias veces), pero recuerda que si el usuario bloquea el permiso de una app, evitará que los demás soliciten ese permiso o usen esa función.
• Configuración del usuario: La configuración también se establece por origen. Por ejemplo, si dos apps tienen diferentes tamaños de fuente y el usuario solo quiere acercar una de ellas para compensarla, no podrá hacerlo sin aplicar también la configuración a las otras apps.

Debido a estos desafíos, es difícil fomentar este enfoque. Sin embargo, si no puedes usar un origen independiente (p.ej., un subdominio), como se explica en la sección Cómo usar orígenes separados de las dos opciones de origen que presentamos, se recomienda usar rutas que no se superpongan en lugar de rutas superpuestas o anidadas.

Como se mencionó, los desafíos analizados en esta sección son comunes a ambos enfoques del mismo origen. En la siguiente sección, veremos en detalle por qué usar rutas superpuestas o anidadas es la estrategia menos recomendada.

Desafíos adicionales para rutas superpuestas/anidadas

El problema adicional con el enfoque de rutas superpuestas/anidadas (donde https://example.com/ es la app externa y https://example.com/app/ es la app interna), es que todas las URLs de la app interna se considerarán parte de la app externa y interna.

En la práctica, esto presenta los siguientes problemas:

• Promoción de la instalación: Si el usuario visita la app interna (por ejemplo, en un navegador web), cuando la app externa ya esté instalada en el dispositivo del usuario, este no mostrará los banners promocionales de la instalación y no se activará el evento beforeInstallPrompt. Esto se debe a que el navegador verificará y comprobará si la página actual pertenece a una app que ya está instalada, y concluirá que lo está. La solución alternativa es instalar la app interna manualmente (mediante la opción "Crear acceso directo" del menú del navegador) o instalar la app interna primero, antes de la externa.
• Notificación y API de insignias: Si la app externa está instalada, pero la interna no, las notificaciones y las insignias provenientes de la app interna se atribuirán de forma errónea a la app externa (que es el alcance de cierre más cercano de una app instalada). Esta función se ejecuta correctamente en el caso de que ambas apps estén instaladas en el dispositivo del usuario.
• Captura de vínculos: La app externa puede capturar URLs que pertenecen a la app interna. Esto es muy probable si la app externa está instalada, pero la interna no. Del mismo modo, los vínculos dentro de la app externa que se vinculan con la app interna no vincularán la captura con la app interna, ya que se considera que están dentro del alcance de la app externa. Además, en ChromeOS y Android, si estas apps se agregan a Play Store (como Actividades web de confianza), la app externa capturará todos los vínculos. Incluso si la app interna está instalada, el SO seguirá ofreciendo al usuario la opción de abrirlas en la app externa.

Conclusión

En este artículo, analizamos diferentes formas en las que los desarrolladores pueden compilar varias apps web progresivas relacionadas entre sí dentro del mismo dominio.

En resumen, te recomendamos que uses un origen diferente (p.ej., subdominios) para alojar AWP independientes. Alojarlas en el mismo origen presenta muchos desafíos, principalmente porque el navegador no las considerará completamente como apps distintas.

• Orígenes separados: Recomendado
• Mismo origen, rutas que no se superpongan: No se recomienda
• Mismo origen, rutas superpuestas o anidadas: No se recomienda

Si no es posible usar orígenes diferentes, usa rutas que no se superpongan (p.ej., https://example.com/app1/ y https://example.com/app2/), en lugar de usar rutas superpuestas o anidadas, como https://example.com/ (para la app externa) y https://example.com/app/ (para la app interna).

Recursos adicionales

• Apps web progresivas en sitios de varios orígenes

Muchas gracias por sus revisiones y sugerencias técnicas: Joe Medley, Dominick Ng, Alan Cutter, Daniel Murphy, Penny McLachlan, Thomas Steiner y Darwin Huang

Foto de Tim Mosshold en Unsplash