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 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 abarque a todos.

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

• La página principal se encuentra 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, lo que evita que se compartan los trabajadores del servicio, las cachés y los permisos entre los orígenes. Por esa razón, te recomendamos evitar este tipo de configuración y, para aquellos que ya tienen sitios compilados de esta manera, considerar migrar a una arquitectura de sitio de origen único siempre que sea posible.

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

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

Términos técnicos

• Dominio: Es cualquier secuencia de etiquetas como 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.
• Origen: Es una combinación de un esquema, un nombre de host y, de manera opcional, un puerto. Por ejemplo, https://www.example.com:443 es un origen.

Como su nombre lo indica, la política de origen único impone restricciones a los orígenes, por lo que nos referiremos principalmente al término a lo largo del artículo. Sin embargo, usaremos "dominios" o "subdominios" de vez en cuando para describir la técnica que se usa, con el fin de crear los diferentes "orígenes".

El caso de varias AWP relacionadas

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

• Un sitio de comercio electrónico quiere crear una experiencia independiente para permitir que los vendedores administren su inventario y, al mismo tiempo, asegurarse de que comprendan que pertenece al sitio web principal en el que los usuarios compran productos.
• Un sitio de noticias deportivas quiere crear una app específica para un evento deportivo importante para permitir que los usuarios reciban estadísticas sobre sus competiciones favoritas a través de notificaciones y, luego, instalarla como una app web progresiva y, al mismo tiempo, asegurarse de que los usuarios la reconozcan como una app creada por la empresa de noticias.
• Una empresa quiere crear apps de chat, correo electrónico y calendario independientes, y quiere que funcionen como apps individuales, vinculadas al nombre de la empresa.

Cómo usar orígenes independientes

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 en todos ellos, puedes hacerlo con subdominios. Por ejemplo, una empresa que proporciona varias apps o servicios de Internet puede alojar una app de correo en https://mail.example.com y una app de calendario en https://calendar.example.com, mientras ofrece el servicio principal de su empresa en https://www.example.com. Otro ejemplo es un sitio deportivo que quiere crear una app independiente dedicada por completo a un evento deportivo importante, como un campeonato de fútbol en https://footballcup.example.com, que los usuarios puedan 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 sus propias apps independientes con la marca de la empresa. Por ejemplo, una app que permite a los comercios crear sus propias AWP en https://merchant1.example.com, https://merchant2.example.com, etcétera.

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

• Instalabilidad: 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 compartirlas con las demás.
• Trabajadores del servicio: Cada app tiene su propio trabajador del servicio para los permisos registrados.
• Permisos: Los permisos también se definen por orígenes. Gracias a eso, los usuarios sabrán exactamente para qué servicio otorgan permisos, y las funciones como las notificaciones se atribuirán correctamente a cada app.

Crear ese grado de aislamiento es lo más conveniente en el caso de uso de varias AWP independientes, por lo que te recomendamos este enfoque.

Si las apps en subdominios quieren compartir datos locales entre sí, podrán hacerlo a través de cookies o, en casos más avanzados, podrían considerar sincronizar el almacenamiento a través de un servidor.

Usar el mismo origen

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

Rutas que no se superponen

Varias AWP o "aplicaciones web" conceptuales, alojadas en el mismo origen, con rutas que no se superponen Por ejemplo:

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

Rutas superpuestas o anidadas

Varios AWP en el mismo origen, cuyo alcance está anidado dentro del otro:

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

La API de servicio en primer plano y el formato de manifiesto te permiten hacer cualquiera de las opciones anteriores con el alcance a nivel de la 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 considerará que estas son "apps" distintas, por lo que se desaconseja este enfoque.

En la siguiente sección, analizaremos estos desafíos con más detalle y lo que se puede hacer si usar orígenes separados no es una opción.

Desafíos para varias AWP de origen único

Estos son algunos problemas prácticos comunes a ambos enfoques de origen:

• Almacenamiento: Las cookies, el almacenamiento local y todas las formas de almacenamiento local del dispositivo se comparten entre las apps. Por esa razón, si el usuario decide borrar los datos locales de una app, se borrarán todos los datos del origen. No hay forma de hacerlo para una sola app. Ten en cuenta que Chrome y algunos otros navegadores solicitará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 negativamente.
• Permisos: Los permisos del navegador están vinculados al origen. Esto significa que, si el usuario otorga un permiso a una app, se aplicará a todas las apps de ese origen simultáneamente. Eso puede parecer algo bueno (no tener que pedir un permiso varias veces), pero recuerda que, si el usuario bloquea el permiso de una app, impedirá que las demás soliciten ese permiso o usen esa función. Ten en cuenta que, incluso si los permisos del navegador solo se deben otorgar una vez por origen, los permisos a nivel del sistema, por otro lado, se deben otorgar una vez por app, independientemente de si varias apps apuntan al mismo origen.
• 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 quiere ajustar el zoom en solo una de ellas para compensarlo, no podrá hacerlo sin aplicar la configuración a las otras apps.

Estos desafíos dificultan el fomento de 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 independientes, 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 que se analizan en esta sección son comunes a ambos enfoques de origen. En la siguiente sección, profundizaremos en los detalles de por qué usar rutas de acceso superpuestas o anidadas es la estrategia menos recomendada.

Desafíos adicionales para las rutas superpuestas o anidadas

El problema adicional con el enfoque de rutas superpuestas o anidadas (en el que 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 de la interna.

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

• Promoción de 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, el navegador no mostrará los banners promocionales de instalación ni se activará el evento BeforeInstallPrompt. El motivo es que el navegador verificará si la página actual pertenece a una app que ya está instalada y concluirá que sí. La solución para esto es instalar la app interna de forma manual (a través de la opción de menú del navegador "Crear acceso directo") o instalar primero la app interna, antes de la app externa.
• Notificación y la API de Badging: Si la app externa está instalada, pero la interna no, las notificaciones y los distintivos que provienen de la app interna se atribuirán erróneamente a la app externa (que es el alcance de cierre más cercano de una app instalada). Esta función funciona 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 no la interna. Del mismo modo, los vínculos dentro de la app externa que se vinculan a la app interna no vincularán la captura en la app interna, ya que se consideran dentro del alcance de la app externa. Además, en ChromeOS y Android, si estas apps se agregan a Play Store (como Actividades web confiables), la app externa capturará todos los vínculos. Incluso si la app interna está instalada, el SO le ofrecerá al usuario la opción de abrirla en la app externa.

Conclusión

En este artículo, analizamos las diferentes formas en 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., con subdominios) para alojar AWP independientes. Alojados en el mismo origen, presentan muchos desafíos, principalmente porque el navegador no las considerará apps distintas.

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

Si no es posible usar orígenes diferentes, se recomienda usar rutas de acceso que no se superpongan (p.ej., https://example.com/app1/ y https://example.com/app2/) en lugar de rutas de acceso 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 Mossholder en Unsplash