Desafios e soluções alternativas para criar Progressive Web Apps em sites de várias origens.
Publicado em: 19 de agosto de 2019
Antes, havia algumas vantagens em usar arquiteturas de várias origens. Para os PWAs, essa abordagem apresenta muitos desafios. Em particular, a política de mesma origem impõe restrições ao 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 soluções alternativas para criar PWAs 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 a fornecer um conjunto independente de aplicativos da Web ou criar experiências completamente isoladas umas das outras. Há também usos que devem ser evitados.
A boa notícia
Confira os motivos úteis primeiro:
Localização / idioma: use um domínio de nível superior com código do país para separar sites que serão veiculados em diferentes países (por exemplo,
https://www.google.com.ar) ou use subdomínios para dividir sites segmentados para diferentes locais (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:uso de subdomínios diferentes para oferecer experiências com finalidades consideravelmente diferentes do site na origem principal. Por exemplo, em um site de notícias, o web app de palavras cruzadas pode ser veiculado intencionalmente de
https://crosswords.example.come 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 nada disso, provavelmente usar uma arquitetura de várias origens será uma desvantagem ao criar Progressive Web Apps.
Apesar disso, muitos sites continuam sendo estruturados dessa forma sem um motivo específico ou por motivos "legados". 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 desencorajados:
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 emhttps://sports.example.com, política emhttps://politics.example.come assim por diante. No caso de um site de e-commerce, use algo comohttps://category.example.compara categorias de produtos,https://product.example.compara páginas de produtos etc.Fluxo do usuário:outra abordagem desencorajada é separar diferentes partes menores do site, como páginas para os fluxos de login ou compra em subdomínios. Por exemplo, usando
https://login.example.comehttps://checkout.example.com.
Para os casos em que não é possível migrar para uma única origem, confira 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 unificada de PWA é um desafio, principalmente devido à política de mesma origem, que impõe várias restrições. Vamos analisar cada uma delas.
Service workers
A origem do URL do script do service worker precisa ser a mesma da 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 as de https://section.example.com.
Nesse caso, a única solução alternativa é usar vários service workers (um por origem).
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.
Confira algumas dicas para gerenciar caches corretamente em situações como essa:
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 adicional 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, faça o pré-cache apenas dos recursos absolutamente necessários.
Permissões
As permissões também são definidas para origens. Isso significa que, se um usuário concedeu 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 é possível 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 coisas como notificações push da Web, você pode manter um cookie para rastrear se a permissão foi aceita pelo usuário em outro subdomínio e evitar solicitá-la 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 receber 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 outra origem (por exemplo, https://www.example.com). Em outras palavras, os usuários que receberem 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.
Além disso, o mesmo usuário pode receber várias solicitações de instalação ao navegar pelo 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, verifique se a solicitação é mostrada apenas na origem principal. Quando um usuário visita um subdomínio que atende aos critérios de instalação:
- Detecte o evento
beforeinstallprompt. - Impeça que o aviso apareça chamando
event.preventDefault().
Assim, você garante que a solicitação não seja mostrada em partes não intencionais do site, mas continue aparecendo, por exemplo, na origem principal (página inicial).
Modo independente
Ao navegar em uma janela independente, o navegador se comportará de maneira diferente quando o usuário sair 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á 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):
- O novo URL,
https://login.example.com, pode ser aberto em um iframe de tela cheia. - 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.
- Como etapa final, depois que a mensagem é recebida pela página principal, os listeners podem ser cancelados, e o iframe é 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 alcançar uma experiência de PWA coerente. Por isso, para oferecer 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 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 mudança no design 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.