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 em usar arquiteturas de várias origens, mas para os Progressive Web Apps, essa abordagem apresenta muitos desafios. Particularmente, a política de mesma origem impõe restrições ao compartilhamento de itens como service workers e caches, permissões e permite uma experiência independente em várias origens. Este artigo descreve os usos bons e ruins de múltiplas 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 diferentes origens

Existem algumas razões legítimas para os sites empregarem uma arquitetura de origem múltipla, principalmente relacionada 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

Primeiro, vejamos os motivos úteis:

• Localização / idioma:usar um domínio de nível superior com código de país para separar sites a serem veiculados em países diferentes (por exemplo, https://www.google.com.ar) ou subdomínios para dividir sites segmentados para diferentes locais (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 proporcionar experiências que têm uma finalidade diferente da que o site na origem principal. Por exemplo, em um site de notícias, o app da Web de palavras cruzadas poderia ser veiculado intencionalmente a partir de https://crosswords.example.com e instalado e usado como um PWA independente, sem precisar compartilhar recursos ou funcionalidades com o site principal.

O lado ruim

Se você não fizer nada disso, é provável que o uso de uma arquitetura multiorigem seja uma desvantagem na criação de Progressive Web Apps.

Apesar disso, muitos sites continuam sendo estruturados dessa maneira sem motivo específico ou por motivos "legados". Um exemplo é o uso de subdomínios para arbitrariamente separar 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 diferentes seções de um site em subdomínios. Em sites de notícias, não é incomum 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 e-commerce, 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 de login ou fluxos de compra em subdomínios. Por exemplo, usando https://login.example.com e https://checkout.example.com.

Para 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 Progressive Web Apps.

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

Ao criar um site de 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 um de cada vez.

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 sob a origem e o 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 do escopo), mas não vai controlar nenhuma página em outros subdomínios, como, por exemplo, em https://section.example.com.

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

Armazenamento em cache

O objeto Cache, IndexingDB e 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: https://www.section.example.com.

Confira alguns exemplos do que você pode fazer para gerenciar os caches corretamente em cenários como estes:

• Aproveite o armazenamento em cache do navegador:é sempre recomendado 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 entre origens, o que não pode ser feito com o cache do service worker. Para conferir as práticas recomendadas sobre o uso do 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 fazer com que os usuários paguem um alto custo de instalação sempre que navegarem para uma nova origem. Em outras palavras: pré-armazenar em cache apenas os recursos que são absolutamente necessários.

Permissões

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

Como não há como compartilhar permissões entre origens, a única solução aqui é pedir permissão em cada subdomínio em que um determinado recurso é necessário (por exemplo, localização). Em ações como push na Web, é possível manter um cookie para rastrear se a permissão foi aceita pelo usuário em outro subdomínio, evitando 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 mesmo. 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 um start_url em outro (como 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 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 atenuar esse problema, certifique-se de que a solicitação seja exibida apenas na origem principal. Quando um usuário visita um subdomínio que atende aos critérios de instalação:

1. Ouvir o evento beforeinstallprompt.
2. Evite que a solicitação apareça, chamando event.preventDefault().

Assim, você garante que a solicitação não apareça em partes indesejadas do site e pode continuar a ser mostrada, por exemplo, na origem principal (por exemplo, página inicial).

Modo autônomo

Ao navegar em uma janela independente, o navegador vai se comportar de maneira diferente quando o usuário sair do escopo definido pelo manifesto do PWA. O comportamento depende da versão do navegador e do 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á solução, mas uma solução alternativa pode ser aplicada 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. Quando a tarefa for concluída no iframe (por exemplo, o processo de login), postMessage() poderá ser usado para transmitir qualquer informação resultante do iframe de volta à página mãe.
3. Como etapa final, quando a mensagem é recebida pela página principal, o registro dos listeners pode ser cancelado e o iframe finalmente removido do DOM.

Conclusão

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

Para sites já criados dessa forma, pode ser difícil fazer com que os PWAs de várias origens funcionem corretamente, mas exploramos algumas possíveis soluções alternativas. Cada um pode ter vantagens e desvantagens, portanto, use o bom senso ao decidir qual abordagem adotar em 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 muito pelas sugestões e análises técnicas: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle e Andre Bandarra.