Applicazioni web progressive in siti multiorigine

Sfide e soluzioni alternative per la creazione di app web progressive in siti multiorigine.

Demián Renzulli

Data di pubblicazione: 19 agosto 2019

In passato, l'utilizzo di architetture multi-origine presentava alcuni vantaggi. Per le app web progressive, questo approccio presenta molte sfide. In particolare, il criterio della stessa origine impone restrizioni per la condivisione di elementi come service worker e cache, autorizzazioni e per ottenere un'esperienza autonoma su più origini.

Scopri gli usi positivi e negativi di più origini e spiega le sfide e le soluzioni alternative per la creazione di app web progressive in siti multi-origine.

Utilizzi corretti e scorretti di più origini

Esistono alcuni motivi legittimi per cui i siti utilizzano un'architettura multiorigine, principalmente per fornire un insieme indipendente di applicazioni web o per creare esperienze completamente isolate l'una dall'altra. Esistono anche utilizzi da evitare.

Il buono

Dai un'occhiata prima ai motivi utili:

• Localizzazione / Lingua: utilizzo di un dominio di primo livello con codice paese per separare i siti da pubblicare in paesi diversi (ad es. https://www.google.com.ar) o utilizzo di sottodomini per dividere i siti destinati a località diverse (ad es. https://newyork.craigslist.org) o per offrire contenuti per una lingua specifica (ad es. https://en.wikipedia.org).

• Web app indipendenti:utilizzo di sottodomini diversi per fornire esperienze il cui scopo differisce notevolmente dal sito sull'origine principale. Ad esempio, in un sito di notizie, la web app di cruciverba potrebbe essere intenzionalmente pubblicata da https://crosswords.example.com e installata e utilizzata come PWA indipendente, senza dover condividere risorse o funzionalità con il sito web principale.

The bad

Se non fai nessuna di queste cose, è probabile che l'utilizzo di un'architettura multiorigine sia uno svantaggio quando crei app web progressive.

Nonostante ciò, molti siti continuano a essere strutturati in questo modo senza un motivo particolare o per motivi "legacy". Un esempio è l'utilizzo di sottodomini per separare arbitrariamente parti di un sito che dovrebbero far parte di un'esperienza unificata.

Ad esempio, i seguenti pattern sono fortemente sconsigliati:

• Sezioni del sito: separazione delle diverse sezioni di un sito in sottodomini. Nei siti di notizie, non è raro vedere la home page all'indirizzo https://www.example.com, mentre la sezione sport si trova all'indirizzo https://sports.example.com, quella politica all'indirizzo https://politics.example.com e così via. Nel caso di un sito di e-commerce, utilizza ad esempio https://category.example.com per le categorie di prodotti, https://product.example.com per le pagine di prodotto e così via.

• Flusso utente:un altro approccio sconsigliato è quello di separare le diverse parti più piccole del sito, ad esempio le pagine per i flussi di accesso o di acquisto nei sottodomini. Ad esempio, utilizzando https://login.example.com e https://checkout.example.com.

Per i casi in cui la migrazione a una singola origine non è possibile, di seguito è riportato un elenco di sfide e (ove possibile) soluzioni alternative da prendere in considerazione durante la creazione di app web progressive.

Sfide e soluzioni alternative per le PWA in origini diverse

Quando si crea un sito web su più origini, fornire un'esperienza PWA unificata è difficile, soprattutto a causa della norma relativa all'origine protetta, che impone una serie di vincoli. Vediamoli uno alla volta.

Service worker

L'origine dell'URL dello script del service worker deve essere la stessa dell'origine della pagina che chiama register(). Ciò significa che, ad esempio, una pagina all'indirizzo https://www.example.com non può chiamare register() con un URL del service worker all'indirizzo https://section.example.com.

Un'altra considerazione è che un service worker può controllare solo le pagine ospitate nell'origine e nel percorso a cui appartiene. Ciò significa che, se il service worker è ospitato all'indirizzo https://www.example.com, può controllare solo gli URL di questa origine (in base al percorso definito nel parametro scope), ma non controllerà alcuna pagina in altri sottodomini, ad esempio quelli in https://section.example.com.

In questo caso, l'unica soluzione alternativa è utilizzare più service worker (uno per origine).

Memorizzazione nella cache

Anche gli oggetti Cache, IndexedDB e localStorage sono limitati a una singola origine. Ciò significa che non è possibile accedere alle cache appartenenti a https://www.example.com, ad esempio da https://www.section.example.com.

Ecco alcune cose che puoi fare per gestire correttamente le cache in scenari come questo:

• Sfrutta la memorizzazione nella cache del browser:è sempre consigliabile utilizzare le best practice tradizionali per la memorizzazione nella cache del browser. Questa tecnica offre l'ulteriore vantaggio di riutilizzare le risorse memorizzate nella cache tra le origini, cosa che non è possibile fare con la cache del service worker. Per le best practice su come utilizzare la cache HTTP con i service worker, puoi consultare questo post.

• Mantieni leggera l'installazione del service worker:se gestisci più service worker, evita che gli utenti debbano sostenere un costo di installazione elevato ogni volta che accedono a una nuova origine. In altre parole, memorizza nella cache preventiva solo le risorse assolutamente necessarie.

Autorizzazioni

Le autorizzazioni sono anche limitate alle origini. Ciò significa che se un utente ha concesso una determinata autorizzazione all'origine https://section.example.com, questa non verrà trasferita ad altre origini, come https://www.example.com.

Poiché non è possibile condividere le autorizzazioni tra le origini, l'unica soluzione è richiedere l'autorizzazione per ogni sottodominio in cui è richiesta una determinata funzionalità (ad es. la posizione). Per elementi come le notifiche push web, puoi mantenere un cookie per monitorare se l'autorizzazione è stata accettata dall'utente in un altro sottodominio, in modo da evitare di richiederla di nuovo.

Installazione

Per installare una PWA, ogni origine deve avere il proprio manifest con un start_url relativo a se stesso. Ciò significa che un utente che riceve la richiesta di installazione su una determinata origine (ad es.https://section.example.com) non potrà installare la PWA con un start_url su un'altra origine (ad es.https://www.example.com). In altre parole, gli utenti che ricevono la richiesta di installazione in un sottodominio potranno installare solo le PWA per le sottopagine, non per l'URL principale dell'app.

Inoltre, lo stesso utente potrebbe ricevere più richieste di installazione durante la navigazione nel sito se ogni sottodominio soddisfa i criteri di installazione e chiede all'utente di installare la PWA.

Per risolvere il problema, puoi assicurarti che il prompt venga visualizzato solo nell'origine principale. Quando un utente visita un sottodominio che soddisfa i criteri di installazione:

1. Ascolta l'evento beforeinstallprompt.
2. Impedisci la visualizzazione del prompt, chiamando il numero event.preventDefault().

In questo modo, ti assicuri che il prompt non venga mostrato in parti non intenzionali del sito, mentre puoi continuare a mostrarlo, ad esempio, nell'origine principale (ad es. la home page).

Modalità autonoma

Durante la navigazione in una finestra autonoma, il browser si comporterà in modo diverso quando l'utente si sposta al di fuori dell'ambito impostato dal manifest della PWA. Il comportamento dipende da ogni versione e fornitore del browser. Ad esempio, le ultime versioni di Chrome aprono una scheda personalizzata di Chrome quando un utente esce dall'ambito in modalità autonoma.

Nella maggior parte dei casi non esiste una soluzione, ma è possibile applicare una soluzione alternativa per piccole parti dell'esperienza ospitate in sottodomini (ad esempio, i flussi di lavoro di accesso):

1. Il nuovo URL, https://login.example.com, potrebbe aprirsi all'interno di un iframe a schermo intero.
2. Una volta completata l'attività all'interno dell'iframe (ad esempio, la procedura di accesso), è possibile utilizzare postMessage() per trasferire le informazioni risultanti dall'iframe alla pagina principale.
3. Come passaggio finale, una volta ricevuto il messaggio dalla pagina principale, i listener possono essere annullati e l'iframe può essere rimosso dal DOM.

Conclusione

Le norme relative alla stessa origine impongono molte restrizioni per i siti basati su più origini che vogliono ottenere un'esperienza PWA coerente. Per questo motivo, per offrire la migliore esperienza agli utenti, sconsigliamo vivamente di dividere i siti in origini diverse.

Per i siti esistenti già creati in questo modo, può essere difficile far funzionare correttamente le PWA multiorigine, ma abbiamo esplorato alcune potenziali soluzioni alternative. Ognuno può comportare dei compromessi, quindi usa il tuo giudizio quando decidi quale approccio adottare sul tuo sito web.

Quando valuti una strategia a lungo termine o la riprogettazione del sito, valuta la migrazione a un'unica origine, a meno che non ci sia un motivo importante per mantenere l'architettura multi-origine.

Un ringraziamento speciale per le revisioni tecniche e i suggerimenti a: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle e Andre Bandarra.