Version e strategia di aggiornamento del client per le applicazioni Web

0

Sto scrivendo un'app Web e mi sto chiedendo quali sono gli aggiornamenti futuri e in che modo l'aggiornamento dell'app Web influirà sull'esperienza utente.

In particolare, mi chiedevo in che modo un'azienda come Google si avvicina a questo problema. Ad esempio, ho visto diversi esempi in cui una particolare app di google chiede all'utente se desidera eseguire l'aggiornamento a "i nuovi documenti di google" o simili. Questa è l'esperienza che vorrei fornire, ma non sono sicuro di come procedere. Se è importante, sto scrivendo un'app che utilizza backbone.js e ha un componente lato client JS pesante. Ho visto diverse discussioni parlare di versioning del componente REST o del componente WebServices, ma nessuno che discute l'effettivo codice lato client o componenti di back-end (ovviamente, il back-end potrebbe non avere molta importanza se è tutto dietro un webservice versione)

Sono interessato a come ottengono questo risultato, dal punto di vista di un'applicazione e da un punto di vista del backend (presumibilmente) DB.

Quindi sembra che ci siano diversi problemi.

  • Dove nella web root vengono pubblicate le applicazioni con versione?

  • Come servi più versioni a diversi utenti?

  • Come si esegue la versione del back-end datastore?

  • Dato che utilizzo il backbone, sono particolarmente interessato a progettare il router per questo tipo di app. Se le varie versioni vivono in una sottodirectory, come posso creare un router appropriato?

Ci sono probabilmente anche altre considerazioni. Qualsiasi consiglio sarebbe benvenuto.

    
posta meecect 28.05.2012 - 22:21
fonte

3 risposte

1

L'utilizzo di flag di funzionalità potrebbe aiutare. Fondamentalmente un flag di funzionalità indica al sistema se un utente dovrebbe vedere un determinato elemento di funzionalità. Ad esempio, se hai appena aggiunto un'opzione per le impostazioni utente, puoi copiarlo con un flag di funzionalità per controllare chi vede la funzione. Alcuni dei criteri che un flag di funzionalità può considerare includono:

  • Impostazioni globali (consentire a tutti o nessuno)
  • Utenti specifici (consentire specifici utenti beta)
  • Utenti casuali (consentire una percentuale di utenti, ad esempio per il test A / B)
  • Timestamp (consentire l'uso dopo la data di avvio o in un momento specifico del giorno)

I flag di funzionalità possono completare l'uso del bilanciamento del carico e delle distribuzioni sfalsate. Ad esempio, se vuoi andare in diretta con una funzione in un momento preciso, eseguirai un'implementazione scaglionata e poi invertirai l'interruttore. Più in generale, ciò consente di modificare il comportamento del sito in esecuzione senza dipendere dal modo in cui le distribuzioni sono scadute.

    
risposta data 29.05.2012 - 14:19
fonte
1

Non è possibile per motivi di sicurezza chiedere al client web-utente se desidera aggiornare l'app web-server. Un'app web con accesso in scrittura nella propria cartella di programma renderà felici molti hacker.

Su un'app per android / iphone hai un'app per dispositivi mobili installata localmente che può essere aggiornata localmente se l'utente lo consente.

l'esempio con l'aggiornamento a 'the new google docs' non è l'aggiornamento software sul server ma una delle due funzionalità che sono entrambe implementate sul server nello stesso momento e il "upgrade-switch" chiede solo quale dei due caratteristiche da usare.

    
risposta data 29.05.2012 - 14:53
fonte
0

Se desideri essere in grado di scaglionare l'aggiornamento degli utenti di cui hai bisogno (in astratto):

  • più server web dietro un sistema di bilanciamento del carico in modo da poter avere due (o più) versioni del sito web in diretta in qualsiasi momento.
  • un sistema di database / login comune in modo da avere un punto di accesso e un modo per registrare quale versione del sito normalmente accede a ciascun utente.

Quindi quando un utente accede al database indicherà quale versione del sito è richiesta e quindi il servizio di bilanciamento del carico indirizzerà l'utente alla versione appropriata. Chiaramente è molto più complicato di così, ma questo è il principio di base.

Normalmente avresti solo due versioni, ma potresti anche includere una terza versione con larghezza di banda ridotta come versione di riserva e / o mobile del sito utilizzando la stessa tecnologia.

    
risposta data 28.05.2012 - 22:26
fonte

Leggi altre domande sui tag