Creare più applicazioni web progressive nello stesso dominio

Come creare più PWA, sfruttando lo stesso nome di dominio, per far sapere all'utente che appartengono alla stessa organizzazione o allo stesso servizio.

Chase Phillips

Demián Renzulli

Matt Giuca

Nel post del blog sulle applicazioni web progressive nei siti con più origini, Demian ha discusso delle sfide che i siti costruiti su più origini devono affrontare quando si tenta di creare un'unica applicazione web progressive che le includa tutte.

Un esempio di questo tipo di architettura del sito è un sito di e-commerce in cui:

• La home page è all'indirizzo https://www.example.com.
• Le pagine delle categorie sono ospitate su https://category.example.com.
• Le pagine dei dettagli dei prodotti su https://product.example.com.

Come discusso nell'articolo, il criterio same-origin impone diverse limitazioni, impedendo la condivisione di service worker, cache e autorizzazioni tra le origini. Per questo motivo, consigliamo vivamente di evitare questo tipo di configurazione e, per chi ha già siti creati in questo modo, di valutare la possibilità di eseguire la migrazione a un'architettura di siti di origine singola, se possibile.

Evita di utilizzare origini diverse per le sezioni dello stesso sito quando cerchi di creare un'app web progressiva unificata.

In questo post esamineremo il caso opposto: anziché una singola PWA su origini diverse, analizzeremo il caso delle aziende che vogliono fornire più PWA, sfruttando lo stesso nome di dominio e comunicando all'utente che queste PWA appartengono alla stessa organizzazione o allo stesso servizio.

Come avrai notato, stiamo utilizzando termini diversi, ma correlati, come domini e origini. Prima di procedere, esaminiamo questi concetti.

Termini tecnici

• Dominio: qualsiasi sequenza di etichette come definito nel Domain Name System (DNS). Ad esempio: com e example.com sono domini.
• Nome host: una voce DNS che si risolve in almeno un indirizzo IP. Ad esempio, www.example.com è un nome host, example.com potrebbe esserlo se avesse un indirizzo IP e com non verrebbe mai risolto in un indirizzo IP, quindi non potrebbe mai essere un nome host.
• Origine: una combinazione di uno schema, un nome host e (facoltativamente) una porta. Ad esempio, https://www.example.com:443 è un'origine.

Come suggerisce il nome, il criterio di stessa origine impone limitazioni alle origini, pertanto faremo principalmente riferimento a questo termine nel corso dell'articolo. Tuttavia, di tanto in tanto useremo "domini" o "sottodomini" per descrivere la tecnica utilizzata al fine di creare le diverse "origini".

La motivazione alla base di più PWA correlate

In alcuni casi, potresti voler creare app indipendenti, ma identificarle comunque come appartenenti alla stessa organizzazione o "brand". Riutilizzare lo stesso nome di dominio è un buon modo per stabilire questa relazione. Ad esempio:

• Un sito di e-commerce vuole creare un'esperienza autonoma per consentire ai venditori di gestire il proprio inventario, assicurandosi al contempo che comprendano che appartiene al sito web principale in cui gli utenti acquistano i prodotti.
• Un sito di notizie sportive vuole creare un'app specifica per un importante evento sportivo, per consentire agli utenti di ricevere statistiche sulle loro competizioni preferite tramite notifiche e di installarla come app web progressiva, assicurandosi che gli utenti la riconoscano come un'app sviluppata dalla società di notizie.
• Un'azienda vuole creare app di chat, posta e calendario separate e vuole che funzionino come singole app, associate al nome dell'azienda.

La società proprietaria di example.com vuole fornire tre app o PWA indipendenti, utilizzando lo stesso nome di dominio per stabilire la relazione tra loro.

Utilizzo di origini separate

L'approccio consigliato in questi casi è che ogni app concettualmente distinta sia pubblicata sulla propria origine.

Se vuoi utilizzare lo stesso nome di dominio all'interno di tutti gli account, puoi utilizzare i sottodomini. Ad esempio, un'azienda che fornisce più servizi o app internet può ospitare un'app di posta all'indirizzo https://mail.example.com e un'app di calendario all'indirizzo https://calendar.example.com, offrendo al contempo il servizio principale della propria attività all'indirizzo https://www.example.com. Un altro esempio è un sito sportivo che vuole creare un'app indipendente completamente dedicata a un importante evento sportivo, come un campionato di calcio a https://footballcup.example.com, che gli utenti possono installare e utilizzare indipendentemente dal sito sportivo principale, ospitato su https://www.example.com. Questo approccio può essere utile anche per le piattaforme che consentono ai clienti di creare app indipendenti con il brand dell'azienda. Ad esempio, un'app che consente ai commercianti di creare le proprie PWA su https://merchant1.example.com, https://merchant2.example.com e così via.

L'utilizzo di origini diverse assicura l'isolamento tra le app, il che significa che ognuna può gestire diverse funzionalità del browser in modo indipendente, tra cui:

• Installabilità: ogni app ha il proprio file manifest e offre la propria esperienza installabile.
• Memoria: ogni app ha le proprie cache, lo spazio di archiviazione locale e praticamente tutte le forme di archiviazione locale del dispositivo, senza condividerle con le altre.
• Service worker: ogni app ha il proprio service worker per gli scopi registrati.
• Autorizzazioni: anche le autorizzazioni sono basate sulle origini. In questo modo, gli utenti sapranno esattamente a quale servizio stanno concedendo le autorizzazioni e funzionalità come le notifiche verranno attribuite correttamente a ogni app.

Creare un tale grado di isolamento è la soluzione più auspicabile nel caso d'uso di più PWA indipendenti, quindi consigliamo vivamente di questo approccio.

Se le app sui sottodomini vogliono condividere tra loro dati locali, potranno comunque farlo tramite i cookie oppure, per scenari più avanzati, potranno prendere in considerazione la sincronizzazione dello spazio di archiviazione tramite un server.

È buona prassi creare PWA diverse in origini distinte utilizzando sottodomini.

Utilizzo della stessa origine

Il secondo approccio consiste nel creare le diverse PWA sulla stessa origine. Sono inclusi i seguenti scenari:

Percorsi non sovrapposti

Più PWA o "app web" concettuali, ospitate nella stessa origine, con percorsi non sovrapposti. Ad esempio:

• https://example.com/app1/
• https://example.com/app2/

Percorsi sovrapposti/nidificati

Più PWA nella stessa origine, il cui ambito è nidificato all'interno dell'altro:

• https://example.com/ ("app esterna")
• https://example.com/app/ ("app interna")

L'API del service worker e il formato manifest consentono di eseguire una delle operazioni indicate sopra, utilizzando l'ambito a livello di percorso. Tuttavia, in entrambi i casi, l'utilizzo della stessa origine presenta molti problemi e limitazioni, la cui radice deriva dal fatto che il browser non le considera completamente "app", pertanto questo approccio è sconsigliato.

L'utilizzo di percorsi (sovrapposti o meno) per fornire due PWA indipendenti ("app1", "app2") nella stessa origine è sconsigliato.

Nella sezione successiva, analizzeremo queste sfide in modo più dettagliato e cosa si può fare se non è possibile utilizzare origini separate.

Sfide per più PWA della stessa origine

Di seguito sono riportati alcuni problemi pratici comuni a entrambi gli approcci di origine stessa:

• Spazio di archiviazione: i cookie, lo spazio di archiviazione locale e tutte le forme di spazio di archiviazione locale del dispositivo vengono condivisi tra le app. Per questo motivo, se l'utente decide di cancellare i dati locali per un'app, verranno cancellati tutti i dati dell'origine. Non c'è modo di farlo per una singola app. Tieni presente che Chrome e alcuni altri browser invitano attivamente gli utenti a cancellare i dati locali quando disinstallano un'app, il che influisce anche sui dati delle altre app nell'origine. Un altro problema è che le app dovranno anche condividere la propria quota di spazio di archiviazione, il che significa che se una delle due occupa troppo spazio, l'altra ne risentirà negativamente.
• Autorizzazioni: le autorizzazioni del browser sono legate all'origine. Ciò significa che se l'utente concede un'autorizzazione a un'app, questa verrà applicata contemporaneamente a tutte le app dell'origine. Potrebbe sembrare una buona cosa (non dover chiedere un'autorizzazione più volte), ma ricorda: se l'utente blocca l'autorizzazione per un'app, impedirà alle altre di richiederla o di utilizzare la funzionalità. Tieni presente che anche se le autorizzazioni del browser devono essere concesse una sola volta per origine, le autorizzazioni a livello di sistema devono essere concesse una volta per app, a prescindere dal fatto che più app rimandino alla stessa origine.
• Impostazioni utente:le impostazioni vengono impostate anche in base all'origine. Ad esempio, se due app hanno dimensioni dei caratteri diverse e l'utente vuole regolare lo zoom solo in una di esse per compensare, non potrà farlo senza applicare l'impostazione anche alle altre app.

Queste sfide rendono difficile incoraggiare questo approccio. Tuttavia, se non puoi utilizzare un'origine separata (ad es. un sottodominio), come discusso nella sezione Utilizzare origini separate, tra le due opzioni con la stessa origine che abbiamo presentato, è vivamente consigliato utilizzare percorsi non sovrapposti anziché percorsi sovrapposti/nidificati.

Come accennato, le sfide discusse in questa sezione sono comuni a entrambi gli approcci di origine stessa. Nella sezione successiva approfondiremo i dettagli sul perché l'utilizzo di percorsi sovrapposti/nidificati è la strategia meno consigliata.

Problemi aggiuntivi per i percorsi sovrapposti/nidificati

Un altro problema con l'approccio dei percorsi sovrapposti/nidificati (dove https://example.com/ è l'app esterna e https://example.com/app/ è l'app interna) è che tutti gli URL nell'app interna verranno effettivamente considerati parte sia dell'app esterna sia dell'app interna.

In pratica, si verificano i seguenti problemi:

• Promozione dell'installazione: se l'utente visita l'app interna (ad esempio in un browser web), quando l'app esterna è già installata sul suo dispositivo, il browser non mostrerà i banner promozionali di installazione e l'evento BeforeInstallPrompt non verrà attivato. Il motivo è che il browser controlla se la pagina corrente appartiene a un'app già installata e conclude che è così. La soluzione alternativa è installare l'app interna manualmente (tramite l'opzione del menu del browser "Crea scorciatoia") o installare prima l'app interna, prima di quella esterna.
• Notifiche e API Badging: se l'app esterna è installata, ma non l'app interna, le notifiche e i badge provenienti dall'app interna verranno attribuiti erroneamente all'app esterna (ovvero all'ambito più vicino di un'app installata). Questa funzionalità funziona correttamente nel caso in cui entrambe le app siano installate sul dispositivo dell'utente.
• Acquisizione di link: l'app esterna potrebbe acquisire gli URL che appartengono all'app interna. Ciò è particolarmente probabile se l'app esterna è installata, ma non l'app interna. Analogamente, i link all'interno dell'app esterna che rimandano all'app interna non faranno registrare i link nell'app interna, poiché sono considerati all'interno dell'ambito dell'app esterna. Inoltre, su ChromeOS e Android, se queste app vengono aggiunte al Play Store (come Attività web attendibili), l'app esterna acquisirà tutti i link. Anche se l'app interna è installata, il sistema operativo offrirà comunque all'utente la possibilità di aprirle nell'app esterna.

Conclusione

In questo articolo abbiamo esaminato diversi modi in cui gli sviluppatori possono creare più app web progressive correlate all'interno dello stesso dominio.

In sintesi, ti consigliamo vivamente di utilizzare un'origine diversa (ad esempio utilizzando sottodomini) per ospitare PWA indipendenti. Ospitarle nella stessa origine presenta molte sfide, principalmente perché il browser non le considera app distinte.

• Origini separate: opzione consigliata
• Stessa origine, percorsi non sovrapposti: non consigliato
• Stessa origine, percorsi sovrapposti/nidificati: vivamente sconsigliato

Se non è possibile utilizzare origini diverse, utilizzando percorsi non sovrapposti (ad es. https://example.com/app1/ e https://example.com/app2/, consigliamo vivamente di utilizzare percorsi sovrapposti o nidificati, come https://example.com/ (per l'app esterna) e https://example.com/app/ (per l'app interna).

Risorse aggiuntive

• App web progressive nei siti con più origini

Un ringraziamento speciale per le revisioni e i suggerimenti tecnici: Joe Medley, Dominick Ng, Alan Cutter, Daniel Murphy, Penny McLachlan, Thomas Steiner e Darwin Huang

Foto di Tim Mossholder su Unsplash