Progressive Web Apps em sites de várias origens

Desafios e soluções alternativas para a criação de Progressive Web Apps em sites de várias origens.

Demián Renzulli

Contexto

No passado, havia algumas vantagens no uso de arquiteturas de várias origens, mas para Progressive Web Apps, essa abordagem apresenta muitos desafios. Especificamente, a política de mesma origem impõe restrições ao compartilhamento de recursos como service workers e caches, permissões e para garantir uma experiência independente em várias origens. Este artigo descreve os usos bons e ruins de várias origens e explica os desafios e as soluções alternativas para a criação de Progressive Web Apps em sites de várias origens.

Usos bons e ruins de várias origens

Existem alguns motivos legítimos para que os sites empreguem uma arquitetura de várias origens, principalmente relacionadas ao fornecimento de um conjunto independente de aplicativos da Web, ou para criar experiências totalmente isoladas umas das outras. Há também usos que devem ser evitados.

A boa notícia

Primeiro, vamos analisar os motivos úteis:

• 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 diferentes países (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 oferecer conteúdo em um idioma específico (por exemplo, https://en.wikipedia.org).

• Apps da Web independentes:usar subdomínios diferentes para fornecer experiências com uma finalidade muito diferente do site na origem principal. Por exemplo, em um site de notícias, o webapp com palavras cruzadas poderia ser veiculado intencionalmente por https://crosswords.example.com e instalado e usado como um PWA independente, sem precisar compartilhar recursos ou funcionalidades com o site principal.

A má

Se você não fizer nada disso, é provável que o uso de uma arquitetura de várias origens seja uma desvantagem ao criar Progressive Web Apps.

Apesar disso, muitos sites continuam sendo estruturados dessa maneira por nenhum motivo específico ou por motivos "legados". Um exemplo é o uso de subdomínios para separar arbitrariamente partes de um site que devem fazer parte de uma experiência unificada.

Os padrões a seguir, por exemplo, não são recomendados:

• Seções do site: separação de seções diferentes 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, política em https://politics.example.com e assim por diante. No caso de um site de comércio eletrônico, usar 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 diferentes partes menores do site, como páginas para o login ou fluxos de 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 que já existem, a migração para uma única origem é a melhor abordagem.

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

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

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

Service Workers

A origem do URL do script do service worker precisa ser igual à origem 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 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, aqueles em https://section.example.com.

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

Atenção : registrar e ter vários service workers ativos consome recursos adicionais (memória, CPU etc.). Portanto, tenha bom senso em relação a quantos service workers ativos um usuário provavelmente precisará navegar pelo site.

Armazenamento em cache

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

Aqui estão algumas dicas do que você pode fazer para gerenciar caches corretamente em cenários como esses:

• Aproveite o processo de cache do navegador: use as práticas recomendadas tradicionais de armazenamento em cache do navegador. Essa técnica oferece o benefício adicional de reutilizar recursos armazenados em cache entre 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, confira esta postagem.

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

Quando o service worker estiver ativo e em execução, a política de mesma origem também restringirá solicitações entre origens feitas dentro de service workers. Felizmente, essa solução tem uma solução alternativa: usar o CORS (conforme explicado aqui). Não é recomendado 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 à https://section.example.com de origem, ela não será transferida para outras origens, como https://www.example.com.

Como não é possível compartilhar permissões entre origens, a única solução aqui é pedir a permissão em cada subdomínio em que um determinado recurso é necessário (por exemplo, local). Para itens como push na Web, é possível manter um cookie para rastrear se a permissão foi aceita pelo usuário em outro subdomínio e evitar uma nova solicitação.

Instalação

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

Existe também o problema de o mesmo usuário receber várias solicitações de instalação ao navegar no site (se cada subdomínio atende aos critérios de instalação) e solicita que o usuário instale o PWA.

Para atenuar esse problema, garanta que o comando apareça apenas na origem principal. Quando um usuário visita um subdomínio que atende aos critérios de instalação:

1. Ouça o evento beforeinstallprompt.
2. Impede que o prompt apareça, chamando event.preventDefault().

Dessa forma, você garante que o comando não seja mostrado em partes indesejadas do site e pode continuar a mostrá-lo, por exemplo, na origem principal (por exemplo, na página inicial).

Modo independente

Durante a navegação 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 da versão do navegador e de cada fornecedor. 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á uma 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 dentro de um iframe em tela cheia.
2. Quando a tarefa for concluída dentro do iframe (por exemplo, o processo de login), postMessage() poderá ser usado para transmitir as informações resultantes do iframe de volta para a página mãe.
3. Por fim, quando a mensagem é recebida pela página principal, o registro dos listeners é cancelado e o iframe é finalmente 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, onde o usuário pode realizar uma ação em um subdomínio e voltar à origem principal (como em um fluxo de login), mas não é 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 validando todas as origens usando 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 buscam uma experiência de PWA coerente. Por esse motivo, para oferecer a melhor experiência aos usuários, não recomendamos dividir os sites em origens diferentes.

Para sites já criados dessa forma, pode ser um desafio fazer com que os PWAs de várias origens funcionem corretamente, mas exploramos algumas possíveis soluções. Cada uma pode ter vantagens e desvantagens. Por isso, use o bom senso ao decidir qual abordagem usar no seu site.

Ao avaliar uma estratégia de longo prazo ou a 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 muito pelas revisões técnicas e sugestões: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle e Andre Bandarra.