L'elaborazione / filtraggio deve essere eseguita lato client o lato server per le applicazioni basate su catalogo

1

Targeting per dispositivo per il catalogo XML del prodotto

Al momento disponiamo di un servizio Web che genera un XML di prodotti in base ai parametri get nella richiesta. Il servizio web viene utilizzato da un'applicazione mobile Windows.

Di fronte al webservice abbiamo un acceleratore / cache HTTP che memorizza nella cache i risultati per URL identici.

Gli uomini d'affari vogliono una nuova funzione per consentire ai prodotti di essere indirizzati a specifiche configurazioni del dispositivo.

Consideriamo che una configurazione del dispositivo può essere fatta di parametri come:

  • modello hardware
  • firmware
  • posizione geografica
  • provider cellulare
  • ecc ...

Questo può ridurre drasticamente il rapporto hit / miss della cache (efficienza) poiché invieremo un parametro "deviceConfigId" che sarà diverso per molti dispositivi, ma influenzerà l'elenco delle applicazioni emesse. Stiamo parlando di minimo 10.000 configurazioni. Il nostro rapporto hit / miss è passato dal 75% al 40% dopo l'aggiunta di alcune nuove funzionalità e filtri tramite l'URL un anno fa.

Fatta eccezione per l'utilizzo di meccanismi come Edge Server Include ( link ), una delle idee su cui stiamo flirtando è quella di filmare parte del filtro sui dispositivi mobili.

Spostamento del lato client del filtro

Gli sviluppatori di dispositivi mobili si lamentano perché questo potrebbe rendere i loro dispositivi mobili meno reattivi. I dispositivi client dovranno scaricare tutte le informazioni sul prodotto (pagina per pagina mentre le persone scorrono verso il basso) ma il dispositivo dovrà filtrare le voci. Inoltre, all'inizio del caricamento del dispositivo è necessario scaricare un elenco di regole applicabili alla configurazione specifica per applicarle a tutte le richieste future e ai prodotti elencati nell'XML.

Mantenimento di tutti i filtri sul back-end

Gli sviluppatori di backend rabbrividiscono con l'idea di aggiungere "deviceConfigId" a tutte le richieste. Ciò richiederà l'aggiunta di ulteriori infrastrutture e risorse di rete. Il problema può essere risolto aggiungendo un bilanciamento del carico migliore e aggiungendo più server dietro di esso (oltre a passare a tecnologie più distribuite in seguito).

Se consideriamo che l'esperienza dell'utente dovrebbe essere la priorità più alta e che i dispositivi più lenti / più vecchi dovrebbero funzionare nel modo più fluido possibile, sembra che dovremmo usare il filtro lato server per le schede di prodotto.

Tuttavia, i dispositivi più recenti stanno uscendo e i dispositivi più vecchi vengono espulsi continuamente. Forzare i client a fare un po 'di filtraggio ma tenere il carico fuori dal back-end è piuttosto allettante.

Ci sono altri pro / contro e, soprattutto, soluzioni a tale problema?

Grazie

    
posta Menelaos Bakopoulos 18.02.2014 - 20:25
fonte

1 risposta

1

Un buon sviluppatore mobile dovrebbe essere in grado di gestire il filtraggio sul client senza compromettere la reattività utilizzando un lettore di dati avanzati. Oggigiorno, poiché i dispositivi sono multi-core, il filtraggio dovrebbe essere rapido su insiemi di dati di dimensioni ragionevoli senza influire sull'interfaccia utente. Tuttavia, il tempo necessario per tirare giù l'XML potrebbe rendere l'esperienza dell'utente non così eccezionale. L'app rimarrà reattiva poiché i tuoi sviluppatori non stanno tirando giù i dati sul thread dell'interfaccia utente (giusto?). Puoi attenuarne una parte usando la compressione HTTP in quanto XML è un ottimo candidato per la compressione.

Uno dei motivi per cui scelgo di adottare un approccio lato server è che puoi correggere bug o apportare modifiche senza dover utilizzare nuove versioni di un'app mobile. Se non hai mai superato il processo di approvazione degli app per gli store di app, questa è una grande vittoria. Inoltre, non devi preoccuparti delle persone che eseguono vecchie versioni della tua app dal momento che hai il controllo della versione sul server.

Un'altra opzione è applicare il filtro sul lato server dopo la memorizzazione nella cache. In questo modo puoi mantenere e utilizzare la cache già in atto.

    
risposta data 19.02.2014 - 02:28
fonte

Leggi altre domande sui tag