Applicazioni web progressive in siti multiorigine

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

Demián Renzulli

Contesto

In passato, l'utilizzo delle architetture multiorigine presentava alcuni vantaggi, ma per le app web progressive questo approccio presenta molte sfide. In particolare, il criterio della stessa origine impone limitazioni per la condivisione di elementi come service worker e cache, autorizzazioni e per ottenere un'esperienza autonoma su più origini. Questo articolo descrive gli usi positivi e negativi di molteplici origini e illustra le sfide e soluzioni alternative per lo sviluppo di app web progressive in siti multiorigine.

Utilizzi positivi e negativi di origini multiple

Esistono alcuni motivi legittimi per cui i siti impiegano un'architettura multiorigine, per lo più correlate alla fornitura di un insieme indipendente di applicazioni web o alla creazione di esperienze completamente isolate tra loro. Esistono anche possibili usi da evitare.

Il buono

Diamo prima un'occhiata ai motivi utili:

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

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

Il cattivo

Se non esegui nessuna di queste operazioni, è probabile che l'utilizzo di un'architettura multiorigine sia uno svantaggio durante la creazione di 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 dei sottodomini per separare arbitrariamente parti di un sito che devono far parte di un'esperienza unificata.

I seguenti pattern, ad esempio, sono altamente sconsigliati:

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

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

Nota : quando crei un sito da zero, ti consigliamo vivamente di evitare di suddividerlo in sottodomini. Per i siti esistenti, la migrazione a un'unica origine è l'approccio migliore.

Per i casi in cui non è possibile eseguire la migrazione a un'unica origine, di seguito è riportato un elenco di sfide e, se possibile, soluzioni alternative che possono essere prese in considerazione durante la creazione di app web progressive.

Sfide e soluzioni alternative per PWA di origini diverse

Quando si crea un sito web su più origini, fornire un'esperienza PWA unificata è difficile, principalmente a causa del criterio della stessa origine, che impone una serie di vincoli. Vediamoli uno alla volta.

Service worker

L'origine dell'URL dello script del service worker deve essere uguale all'origine della pagina che chiama register(). Ciò significa che, ad esempio, una pagina all'indirizzo https://www.example.com non può chiamare register() con l'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 su https://www.example.com, può controllare solo gli URL di quell'origine (in base al percorso definito nel parametro scope), ma non controllerà nessuna pagina in altri sottodomini come, ad esempio, quelli in https://section.example.com.

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

Attenzione: la registrazione e la presenza di più service worker attivi consumano risorse aggiuntive (memoria, CPU e così via), quindi valuta con prudenza il numero di service worker attivi che un utente dovrà probabilmente per navigare nel sito.

Memorizzazione nella cache

L'oggetto Cache, il database indicizzato e localStorage sono anch'essi vincolati a un'unica origine. Questo significa che non è possibile accedere alle cache che appartengono a https://www.example.com, ad esempio: 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: si consiglia sempre di utilizzare le best practice tradizionali per la memorizzazione nella cache del browser. Questa tecnica offre il vantaggio aggiuntivo di riutilizzare le risorse memorizzate nella cache tra origini, cosa non possibile con la cache del service worker. Per le best practice su come utilizzare la cache HTTP con i service worker, puoi dare un'occhiata a questo post.

• Riduci l'installazione dei service worker: se gestisci più service worker, evita di far pagare agli utenti un costo di installazione elevato ogni volta che si spostano verso una nuova origine. In altre parole: solo le risorse prememorizzate nella cache che sono assolutamente necessarie.

Quando il service worker è attivo e in esecuzione, il criterio della stessa origine limita anche le richieste multiorigine effettuate all'interno dei service worker. Fortunatamente, è disponibile una soluzione alternativa consigliata, ovvero utilizzare CORS (come spiegato qui). Non è consigliabile utilizzare la modalità no-cors per recuperare le risorse all'interno del service worker.

Autorizzazioni

Anche le autorizzazioni sono 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 in questo caso è chiedere l'autorizzazione per ogni sottodominio in cui è richiesta una determinata funzionalità (ad esempio la posizione). Per elementi come il push web, puoi gestire un cookie per monitorare se l'autorizzazione è stata accettata dall'utente in un altro sottodominio, per evitare di richiederla di nuovo.

Installazione

Per installare una PWA, ogni origine deve avere un proprio manifest con un start_url relativo a se stessa. 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 PWA solo per le pagine secondarie, non per l'URL principale dell'app.

Esiste inoltre il problema per cui 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 mitigare 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 messaggio chiamando il numero event.preventDefault().

In questo modo ti assicuri che il prompt non venga mostrato in parti indesiderate del sito, ma potrai continuare a mostrarlo, ad esempio, nell'origine principale (come 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 dalla versione e dal 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 a piccole parti dell'esperienza ospitate in sottodomini (ad esempio, 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 trasmettere alla pagina principale le informazioni risultanti dall'iframe.
3. Come ultimo passaggio, una volta ricevuto il messaggio dalla pagina principale, è possibile annullare la registrazione dei listener e rimuovere l'iframe dal DOM.

Attenzione : la tecnica precedente può aiutare a mitigare il potenziale cambiamento dell'interfaccia utente in una piccola parte del sito, dove l'utente può eseguire un'azione in un sottodominio e tornare all'origine principale (come in un flusso di accesso), ma non sarà una tecnica efficiente da implementare per interi percorsi, incluse molte pagine ospitate in sottodomini (come intere sezioni del sito).

Nota: nel contesto delle Trusted Web Actitivies, esiste un modo consigliato per evitare questo problema, convalidando tutte le origini utilizzando Digital Asset Links.

Conclusione

Il criterio della stessa origine impone molte limitazioni 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 per 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. Ognuna può comportare dei compromessi, quindi utilizza il tuo giudizio quando decidi quale approccio adottare sul tuo sito web.

Quando valuti una strategia a lungo termine o una riprogettazione del sito, valuta la possibilità di migrare a un'unica origine, a meno che non ci sia un motivo importante per mantenere l'architettura multiorigine.

Grazie mille per le recensioni tecniche e i suggerimenti: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle e Andre Bandarra.