Creare più applicazioni web progressive nello stesso dominio

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

Chase Phillips

Demián Renzulli

Matt Giuca

Nel post del blog sulle app web progressive in siti multi-origine, Demian ha discusso delle sfide che i siti creati su più origini devono affrontare quando cercano di creare un'unica app web progressiva che li abbraccia tutte.

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

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

Come discusso nell'articolo, il criterio same-origin impone diverse restrizioni, 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 quelli che hanno già siti creati in questo modo, di prendere in considerazione la migrazione a un'architettura del sito di origine singola quando possibile.

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

Come avrai notato, utilizziamo termini diversi, ma correlati, come domini e origini. Prima di andare avanti, rivediamo questi concetti.

Glossario tecnico

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

Come suggerisce il nome, same-origin policy imposte limitazioni sulle origini, quindi faremo riferimento principalmente al termine in tutto l'articolo. Ciononostante, di tanto in tanto utilizzeremo "domini" o "sottodomini" per descrivere la tecnica utilizzata, al fine di creare le diverse "origini".

Il caso di più PWA correlate

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

• Un sito di e-commerce vuole creare un'esperienza autonoma per consentire ai venditori di gestire il loro inventario e assicurarsi 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 grande evento sportivo, per consentire agli utenti di ricevere le statistiche sulle loro competizioni preferite tramite notifiche e installarla come app web progressiva, assicurandosi che gli utenti la riconoscano come app creata dalla testata giornalistica.
• Una società vuole creare app separate per chat, posta e calendario e vuole che funzionino come singole app, legate al nome dell'azienda.

Utilizzo di origini separate

L'approccio consigliato in casi come questi è che ogni app concettualmente distintamente attiva sulla propria origine.

Se vuoi utilizzare lo stesso nome di dominio all'interno di tutti i domini, puoi utilizzare i sottodomini. Ad esempio, una società che fornisce più servizi o app internet può ospitare un'app di posta su https://mail.example.com e un'app di calendario su https://calendar.example.com, offrendo al contempo il servizio principale della sua attività all'indirizzo https://www.example.com. Un altro esempio è un sito di sport 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 principale dello sport, ospitato su https://www.example.com. Questo approccio può essere utile anche per le piattaforme che consentono di creare app indipendenti con il brand. 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 garantisce l'isolamento tra le app, il che significa che ognuna può gestire le diverse funzionalità del browser in modo indipendente, tra cui:

• Installabilità: ogni app ha un proprio manifest e fornisce la propria esperienza installabile.
• Spazio di archiviazione: ogni app ha le proprie cache, 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 ambiti registrati.
• Autorizzazioni: l'ambito delle autorizzazioni dipende anche dalle origini. Grazie a ciò, gli utenti sapranno esattamente per quale servizio stanno concedendo le autorizzazioni e funzionalità come le notifiche verranno attribuite correttamente a ciascuna app.

La creazione di un simile grado di isolamento è la più desiderabile nel caso d'uso di più PWA indipendenti, per cui consigliamo vivamente questo approccio.

Se le app nei sottodomini vogliono condividere dati locali tra loro, potranno comunque farlo tramite i cookie oppure, per scenari più avanzati, potrebbero valutare la possibilità di sincronizzare lo spazio di archiviazione tramite un server.

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 sulla stessa origine, con percorsi non sovrapposti. Ad esempio:

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

Percorsi sovrapposti/nidificati

Più PWA sulla stessa origine, una del cui ambito è nidificata all'interno dell'altra:

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

L'API e il formato manifest dei service worker consentono di eseguire una delle operazioni precedenti, 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" distinte, pertanto questo approccio è sconsigliato.

Nella sezione successiva, analizzeremo in maggiore dettaglio queste sfide 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 basati sulla stessa origine:

• Spazio di archiviazione: i cookie, lo spazio di archiviazione locale e tutti i tipi di spazio di archiviazione locale del dispositivo vengono condivisi tra le app. Per questo motivo, se l'utente decide di cancellare i dati locali di un'app, verranno cancellati tutti i dati dall'origine; non è possibile farlo per una singola app. Tieni presente che Chrome e alcuni altri browser chiederanno attivamente agli utenti di cancellare i dati locali quando disinstallano una delle app, con ripercussioni anche sui dati delle altre app nell'origine. Un altro problema è che le app dovranno condividere anche la propria quota di archiviazione, il che significa che se una delle due occupa troppo spazio, l'altra viene influenzata negativamente.
• Autorizzazioni: le autorizzazioni sono collegate all'origine. Ciò significa che se l'utente concede un'autorizzazione per un'app, questa verrà applicata contemporaneamente a tutte le app su quell'origine. Potrebbe sembrare una cosa positiva (non dover chiedere più volte un'autorizzazione), ma ricorda che se l'utente blocca l'autorizzazione per un'app, gli altri non potranno richiedere l'autorizzazione o utilizzare quella funzionalità.
• Impostazioni utente:vengono applicate anche le impostazioni 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 queste 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 esempio un sottodominio), come descritto nella sezione Utilizzare origini separate, tra le due opzioni con la stessa origine presentate, è vivamente consigliato utilizzare percorsi non sovrapposti, sopra i percorsi sovrapposti/nidificati.

Come accennato, le sfide discusse in questa sezione sono comuni a entrambi gli approcci basati sulla stessa origine. Nella prossima sezione analizzeremo in dettaglio perché l'utilizzo di percorsi che si sovrappongono/nidificati è la strategia meno consigliata.

Ulteriori sfide relative a percorsi sovrapposti/nidificati

Il problema aggiuntivo con l'approccio per 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 che di quella interna.

In pratica, ciò presenta 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 nel dispositivo dell'utente, il browser non mostrerà i banner promozionali di installazione e l'evento beforeInstallPrompt non viene attivato. Il motivo è che il browser controlla e verifica se la pagina corrente appartiene a un'app già installata e ne conclude che lo è. La soluzione alternativa consiste nell'installare manualmente l'app interna (tramite l'opzione di menu del browser "Crea scorciatoia") o prima di installare l'app interna, quindi l'app esterna.
• Notifiche e API Badging: se l'app esterna è installata, ma quella interna non lo è, le notifiche e i badge provenienti da quest'ultima verranno erroneamente attribuiti all'app esterna (che è l'ambito di inclusione più vicino a un'app installata). Questa funzionalità funziona correttamente nel caso in cui entrambe le app siano installate sul dispositivo dell'utente.
• Acquisizione link: l'app esterna potrebbe acquisire gli URL che appartengono all'app interna. Questo è 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 verranno acquisiti 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 aprirla nell'app esterna.

Conclusione

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

Per riassumere, 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 considererà completamente distinte.

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

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

Altre risorse

• App web progressive in siti multiorigine

Grazie mille per le recensioni tecniche e i suggerimenti: Joe Medley, Dominick Ng, Alan Cutter, Daniel Murphy, Penny McLachlan, Thomas Steiner e Darwin Huang

Foto di Tim Mossholder su Unsplash