Progressive Web Apps em sites de várias origens

Desafios e soluções alternativas para criar Apps Web Progressivos em sites de várias origens.

Demián Renzulli

Publicado em: 19 de agosto de 2019

No passado, havia algumas vantagens em usar arquiteturas de várias origens. Para Apps Web Progressivos, essa abordagem apresenta muitos desafios. Em particular, a política de mesma origem impõe restrições para o compartilhamento de itens como service workers e caches, permissões e para alcançar uma experiência independente em várias origens.

Descubra os usos bons e ruins de várias origens e explique os desafios e as soluções alternativas para criar Apps Web Progressivos em sites de várias origens.

Usos bons e ruins de várias origens

Há alguns motivos legítimos para os sites usarem uma arquitetura de várias origens, principalmente relacionados ao fornecimento de um conjunto independente de aplicativos da Web ou à criação de experiências completamente isoladas umas das outras. Também há usos que devem ser evitados.

A boa notícia

Confira os motivos úteis primeiro:

• Localização / idioma: usar um domínio de nível superior com código de país para separar sites que serão veiculados em países diferentes (por exemplo, https://www.google.com.ar) ou usar subdomínios para dividir sites segmentados para locais diferentes (por exemplo: https://newyork.craigslist.org) ou para oferecer conteúdo em um idioma específico (por exemplo, https://en.wikipedia.org).

• Web apps independentes: usar subdomínios diferentes para oferecer experiências com finalidades muito diferentes do site na origem principal. Por exemplo, em um site de notícias, o app da Web de palavras cruzadas pode ser disponibilizado intencionalmente em https://crosswords.example.com e instalado e usado como um PWA independente, sem precisar compartilhar recursos ou funcionalidades com o site principal.

O ruim

Se você não estiver fazendo nenhuma dessas coisas, é provável que o uso de uma arquitetura de várias origens seja uma desvantagem ao criar Apps Web Progressivos.

Apesar disso, muitos sites continuam sendo estruturados dessa forma sem um motivo específico ou por razões de "legado". Um exemplo é usar subdomínios para separar arbitrariamente partes de um site que deveriam fazer parte de uma experiência unificada.

Por exemplo, os seguintes padrões são altamente desaconselhados:

• Seções do site: separar diferentes seções de um site em subdomínios. Em sites de notícias, é comum ver a página inicial em https://www.example.com, enquanto a seção de esportes fica em https://sports.example.com, a de política em https://politics.example.com e assim por diante. No caso de um site de e-commerce, use algo como https://category.example.com para categorias de produtos, https://product.example.com para páginas de produtos etc.

• Fluxo do usuário: outra abordagem não recomendada é separar partes menores do site, como páginas para os fluxos de login ou compra em subdomínios. Por exemplo, usando https://login.example.com e https://checkout.example.com.

Observação : ao criar um site do zero, é altamente recomendável evitar dividi-lo em subdomínios. Para sites atuais, a melhor abordagem é migrar para uma única origem.

Para os casos em que não é possível migrar para uma única origem, veja a seguir uma lista de desafios e, quando possível, soluções alternativas que podem ser consideradas ao criar Apps Web Progressivos.

Desafios e soluções alternativas para PWAs em diferentes origens

Ao criar um site em várias origens, oferecer uma experiência unificada de PWA é um desafio, principalmente devido à política de mesma origem, que impõe várias restrições. Vamos analisar cada um deles.

Service workers

A origem do URL do script do service worker precisa ser a mesma da página que chama register(). Isso significa que, por exemplo, uma página em https://www.example.com não pode chamar register() com um URL de service worker em https://section.example.com.

Outra consideração é que um service worker só pode controlar páginas hospedadas na origem e no caminho a que ele pertence. Isso significa que, se o service worker estiver hospedado em https://www.example.com, ele só poderá controlar URLs dessa origem (de acordo com o caminho definido no parâmetro de escopo), mas não controlará nenhuma página em outros subdomínios, como, por exemplo, os de https://section.example.com.

Nesse caso, a única solução alternativa é usar vários service workers (um por origem).

Atenção : registrar e ter vários service workers ativos consome mais recursos (memória, CPU etc.). Portanto, use seu bom senso para determinar quantos service workers ativos um usuário provavelmente vai precisar para navegar pelo site.

Armazenamento em cache

O objeto Cache, o indexedDB e o localStorage também são restritos a uma única origem. Isso significa que não é possível acessar os caches que pertencem a https://www.example.com, por exemplo, de https://www.section.example.com.

Veja algumas maneiras de gerenciar caches corretamente em cenários como esse:

• Aproveite o armazenamento em cache do navegador: é sempre recomendável usar as práticas recomendadas tradicionais de armazenamento em cache do navegador. Essa técnica oferece o benefício extra de reutilizar recursos armazenados em cache em várias origens, o que não pode ser feito com o cache do service worker. Para conferir as práticas recomendadas sobre como usar o cache HTTP com service workers, consulte esta postagem.

• Mantenha a instalação do service worker leve: se você estiver mantendo vários service workers, evite que os usuários paguem um alto custo de instalação sempre que navegarem para uma nova origem. Em outras palavras, pré-armazene em cache apenas os recursos que são absolutamente necessários.

Quando o service worker está ativo e em execução, a política de mesma origem também restringe as solicitações entre origens feitas dentro dos service workers. Felizmente, há uma solução recomendada para isso, que é usar o CORS (conforme explicado aqui). Não é recomendável usar o modo no-cors ao buscar recursos dentro do service worker.

Permissões

As permissões também têm escopo para origens. Isso significa que, se um usuário conceder uma determinada permissão à origem https://section.example.com, ela não será transferida para outras origens, como https://www.example.com.

Como não há como compartilhar permissões entre origens, a única solução é pedir permissão em cada subdomínio em que um determinado recurso é necessário (por exemplo, localização). Para itens como push da Web, é possível manter um cookie para rastrear se a permissão foi aceita pelo usuário em outro subdomínio, evitando que ela seja solicitada novamente.

Instalação

Para instalar um PWA, cada origem precisa ter o próprio manifesto com um start_url relativo a si mesmo. Isso significa que um usuário que recebe o aviso de instalação em uma determinada origem (por exemplo, https://section.example.com) não poderá instalar o PWA com um start_url em uma origem diferente (por exemplo, https://www.example.com). Em outras palavras, os usuários que recebem o aviso de instalação em um subdomínio só poderão instalar PWAs para as subpáginas, não para o URL principal do app.

Também há o problema de que o mesmo usuário pode receber várias solicitações de instalação ao navegar no site, se cada subdomínio atender aos critérios de instalação e solicitar que o usuário instale o PWA.

Para reduzir esse problema, verifique se o aviso é mostrado apenas na origem principal. Quando um usuário acessa um subdomínio que atende aos critérios de instalação:

1. Detectar o evento beforeinstallprompt.
2. Impedir que o aviso apareça, chamando event.preventDefault().

Dessa forma, você garante que o aviso não seja mostrado em partes não intencionais do site, mas continua sendo exibido, por exemplo, na origem principal (por exemplo, na página inicial).

Modo independente

Ao navegar em uma janela independente, o navegador se comporta de maneira diferente quando o usuário sai do escopo definido pelo manifesto do PWA. O comportamento depende de cada versão e fornecedor do navegador. Por exemplo, as versões mais recentes do Chrome abrem uma guia personalizada do Chrome quando um usuário sai do escopo no modo independente.

Na maioria dos casos, não há solução para isso, mas é possível aplicar uma solução alternativa para pequenas partes da experiência hospedadas em subdomínios (por exemplo, fluxos de trabalho de login):

1. O novo URL, https://login.example.com, pode ser aberto em um iframe de tela cheia.
2. Depois que a tarefa é concluída no iframe (por exemplo, o processo de login), postMessage() pode ser usado para transmitir as informações resultantes do iframe de volta para a página mãe.
3. Como etapa final, depois que a mensagem é recebida pela página principal, os listeners podem ser cancelados, e o iframe pode ser removido do DOM.

Atenção : a técnica anterior pode ajudar a reduzir a possível mudança na interface em uma pequena parte do site, em que o usuário pode realizar uma ação em um subdomínio e retornar à origem principal (como em um fluxo de login), mas não será uma técnica eficiente para implementar em caminhos inteiros, incluindo muitas páginas hospedadas em subdomínios (como seções inteiras do site).

Observação : no contexto das Atividades Confiáveis na Web, há uma maneira recomendada de evitar esse problema, que é validar todas as origens usando o Digital Asset Links.

Conclusão

A política de mesma origem impõe muitas restrições para sites criados com base em várias origens que querem alcançar uma experiência de PWA coerente. Por isso, para oferecer a melhor experiência aos usuários, recomendamos não dividir os sites em origens diferentes.

Para sites que já foram criados dessa forma, pode ser difícil fazer com que os PWAs de várias origens funcionem corretamente, mas exploramos algumas soluções alternativas. Cada uma delas tem vantagens e desvantagens. Por isso, use o bom senso ao decidir qual abordagem adotar no seu site.

Ao avaliar uma estratégia de longo prazo ou uma reformulação do site, considere migrar para uma única origem, a menos que haja um motivo importante para manter a arquitetura de várias origens.

Agradecemos as revisões técnicas e sugestões de Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle e Andre Bandarra.