Best practice per il calcolo dei dati in applicazioni Web simili a GIS

Question

Best practice per il calcolo dei dati in applicazioni Web simili a GIS

#1 da (1 voti)

4

Supponiamo di avere una semplice applicazione simile a GIS, che presenta (usando Google Maps o qualcosa di simile) tracce registrate. Ogni traccia consiste di punti (porzioni di dati) con dati geografici e informazioni aggiuntive, come velocità, altitudine e attributi simili.

Basandomi su questi parametri aggiuntivi, voglio calcolare alcune informazioni extra, come la velocità media. Che tipo di dati deve ricevere il client Web e su quale lato è il migliore per eseguire i calcoli necessari:

lato client : il client riceve (tramite AJAX) pura matrice di dati (punti con parametri aggiuntivi) e tutti i calcoli vengono eseguiti in Javascript nel browser,
lato server : il client riceve il contenuto pronto per essere inserito nelle posizioni corrette, come il valore della velocità media e tutti i calcoli vengono eseguiti sul server.

Personalmente ho sempre scelto (in qualche modo automaticamente) la prima opzione, poiché pensavo (correggimi, se sbaglio) questo mi dà più flessibilità. Ma, adesso, dopo aver letto alcuni documenti e pagine, posso vedere chiaramente che potrei sbagliarmi. Quindi, qual è la migliore pratica in questa situazione?

server-side client-side client-server

posta trejder 13.05.2013 - 11:22

fonte

1 risposta

Leggi altre domande sui tag server-side client-side client-server

Devo scrivere un wrapper all'interno di un oggetto manager? Trovare il numero massimo di numeri congruenti

score 1 · Accepted Answer

Penso che le cose più importanti in questo caso siano Tempo di risposta (a carico della pagina) e Responsività (nella GUI durante l'interazione).

C'è una parte del caso di utilizzo dell'applicazione in cui alcuni dati statici, più o meno costanti vengono inviati al browser, ma da quel momento in poi l'interazione con l'utente determinerà quali dati dovranno essere effettivamente calcolati.

Se memorizzi i dati elaborati nel tuo server, prima di qualsiasi richiesta possibile, potresti finire con spazio di archiviazione ridondante (dato che velocità, accelerazione, potenza, pendenza sono direttamente derivati dalla posizione);
Se CREATE i dati elaborati su richiesta per ogni richiesta, potreste finire con un sovraccarico di elaborazione E un certo impatto nel tempo di risposta per elaborare e inviare i dati;
Se INVIA dati grezzi e inserisci dati derivati sul lato client, questo potrebbe avere un impatto collettivo sul tempo di risposta, perché i dati dovrebbero essere inviati e calcolati comunque, solo in un ordine diverso rispetto al caso precedente, perché il calcolo è delegato al cliente. Sarebbe "buono per te" e creerebbe una buona reattività della GUI per il client durante l'interazione (tutti i dati sarebbero sempre disponibili) al costo di un tempo di caricamento più lento;
Io mando i dati dal server e non calcoli nulla finché l'utente non lo richiede esplicitamente (ad esempio, selezionando una traiettoria, o un segmento di una traiettoria), allora si dovrebbe avere il miglior tempo di risposta e la reattività dell'interfaccia dipenderà solo dal volume di dati puro e dalla strategia che si utilizza per eseguire calcoli in modo asincrono (in modo da non congelare l'interfaccia utente), fornendo chiare indicazioni visive del progresso, come barre di avanzamento o cursori rotanti.

Sono un ciclista appassionato e un appassionato di mappe, e mi sembra che l'ultimo approccio sia il più utilizzato in siti come STRAVA e RideWithGPS. Lo scenario più comune sono le tracce con poche centinaia di punti e i tipi di calcoli sono abbastanza semplici e adatti agli algoritmi javascript (aritmetica di base e trigonometria).

Spero che questo aiuti!