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 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.

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

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 compilar una app específica para un evento deportivo importante, de modo que los usuarios puedan recibir estadísticas sobre sus competencias favoritas a través de notificaciones y, luego, instalarla como una app web progresiva, a la vez que se asegura de que los usuarios la reconozcan como una app creada por la empresa de noticias.
• Una empresa desea crear apps de chat, correo electrónico y calendario independientes 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, con el mismo nombre de dominio para establecer la relación entre ellas.

Usa orígenes independientes

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

Si deseas usar el mismo nombre de dominio dentro de 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 podría 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:

• 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 alcances 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 un grado de aislamiento de este tipo 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.

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 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 del service worker y el formato de manifiesto te permiten realizar cualquiera de las acciones anteriores mediante alcances 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 considerará que estas son "apps" distintas, por lo que se desaconseja este enfoque.

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

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 del mismo origen

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

• Almacenamiento: Las cookies, el almacenamiento local y todas las formas de almacenamiento local del dispositivo se comparten entre 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 en una sola app. Ten en cuenta que Chrome y otros navegadores solicitarán activamente a los usuarios que borren los datos locales cuando desinstalen una de las apps, lo que afectará también los datos de las otras apps en el 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 de forma simultánea. 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 separado (p.ej., un subdominio), como se explica en la sección Cómo usar orígenes separados, de las dos opciones del mismo origen que presentamos, se recomienda usar rutas no superpuestas 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é el uso de rutas 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 comprobará y determinará si la página actual pertenece a una app que ya está instalada, y concluirá que sí. La solución es instalar la app interna de forma manual (a través de la opción "Crear atajo" del menú del navegador) o instalar primero la app interna, antes que 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
• Rutas del mismo origen, que no se superponen: No se recomienda
• Mismo origen, rutas superpuestas o anidadas: No se recomienda

Si no es posible usar diferentes orígenes, con rutas de acceso no superpuestas (p.ej., https://example.com/app1/ y https://example.com/app2/, se recomienda 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

Agradecemos sus opiniones y sugerencias técnicas: Joe Medley, Dominick Ng, Alan Cter, Daniel Murphy, Penny McLachlan, Thomas Steiner y Darwin Huang.

Foto de Tim Mossholder en Unsplash