Dividendo le responsabilità tra client e server

Which direction should I go? What should I taking into consideration?

Non posso dirti quale direzione andare perché ciò richiederà un'attenta considerazione del dominio del problema, degli utenti finali e alcuni test. Tuttavia, posso aiutarti a capire cosa prendere in considerazione.

Load Balancing

I server delle applicazioni sono corretti. Potresti avere 2, 3 o anche 4, ma qualunque sia il numero, hai un certo numero. Puoi ridimensionare orizzontalmente aggiungendo server, ma c'è un costo lineare diretto per questo.

D'altra parte, hai N client. Ogni utente che visita il tuo sito ha la propria CPU e memoria. In termini di esecuzione del codice, questa è CPU e memoria libere :) Difficile da superare.

I tuoi clienti forniscono anche un livello di isolamento. Il lavoro di un cliente non influisce sul lavoro di un altro per quanto riguarda il codice lato client. Se tutto viene eseguito sul server, una richiesta HTTP che va storta può impantanare un server condiviso da molti utenti.

Sicurezza

Non credere che il client esegua calcoli che influenzano i dati che vengono condivisi con altri utenti a meno che tale calcolo sia derivato da dati che sono stati immessi comunque. Ad esempio, sarebbe opportuno utilizzare JavaScript nel browser per convertire l'utente inserito "05-15-2014" in una data ISO, ma se il server deve registrare il tempo in cui il client ha eseguito un'azione, non chiedere al il cliente deve fornire il tempo. Basta catturare l'ora sul server quando si verifica quella richiesta.

Performance

I browser possono essere lenti a fare un sacco di numeri crunch. Fino alla recente guerra del browser JavaScript, JavaScript in generale era un linguaggio lento, non dovuto a problemi con la lingua, solo alle implementazioni di runtime. Se il server è in grado di calcolare qualcosa utilizzando una CPU veloce e di qualità server e inviarlo, ciò potrebbe funzionare meglio che lasciare che sia il client a farlo.

La prevedibilità

Le macchine client variano. Ci sono utenti che eseguono Safari su Mac, Chrome su un computer Windows 7 a 64 bit con 8 GB di RAM e utenti che eseguono IE8 su Windows XP a 32 bit. Non è possibile prevedere come verrà eseguito il codice lato client perché ci sono fattori importanti fuori dal proprio controllo. I tuoi server, d'altra parte, sono molto sotto il tuo controllo. Puoi monitorare le loro prestazioni e ridimensionarle in base alle esigenze per bilanciare prestazioni e costi.

Larghezza di banda

Il calcolo di qualcosa sul server potrebbe essere più veloce, ma se si finisce per dover trasferire un grande set di dati verso il client su Internet, non solo c'è un componente di latenza, ma è probabile che venga addebitato l'utilizzo della larghezza di banda . Pertanto, se disponi di un calcolo economico che genera un set di dati di grandi dimensioni (diciamo un array di tutti i numeri pari fino a 1 milione), lascia che sia il client a farlo.

Monitoraggio

I tuoi server sono sotto il tuo controllo e quindi puoi monitorare le loro prestazioni. Se le richieste a una pagina specifica restituiscono risultati al client dopo 5 secondi, è più facile rilevare e eseguire il debug sui server. Esistono strumenti e meccanismi per monitorare le prestazioni lato client, ma i trade-off e le complessità sono in genere più elevati (ad esempio, come si fa a riportare i dati in una posizione centrale e a segnalarli?), Ad esempio:

1. Come si riportano i dati in un posto centrale?
2. Risultato prestazionale dell'esecuzione di codice aggiuntivo
3. Per i clienti in cui le prestazioni sono estremamente negative, potresti persino non ottenere le misurazioni, il che distorce le tue metriche perché le peggiori prestazioni sono ciò di cui hai bisogno di sapere di più.

Le prestazioni lato server possono essere monitorate tramite file di registro.

C'è una cosa che hai menzionato nell'ultimo paragrafo che spicca per me:

the client is already feels bloated and complicated.

L'approccio moderno alla relazione client / server è un parallelo della relazione tra uomo e macchina.

Client Simile alla programmazione iOS, dovremmo percepire il front-end angolare come un View-Controller. Non utilizzare i modelli nel frontend, utilizzare i servizi . Questi servizi si connettono ai tuoi modelli che vivono interamente sul server. View-Controller è uno strumento diretto dell'utente. L'utente utilizza il client per capire che wtf sta succedendo nei propri dati all'interno dell'applicazione e per esprimere i propri desideri ("azioni") all'interno del sistema.

Server Qui usiamo il framework Express (o qualsiasi altra cosa) per implementare l'architettura MVC. Raccomando di indirizzare tutti i servizi angolari alle rotte / api / XXX che servono una corretta API hypermedia. (La mia implementazione MEAN preferita è link )

Il prossimo passo qui è quello di ri-fattore per creare spazio per l'innovazione. Crea un diagramma di livello superiore dell'intera applicazione. Disegna una linea verticale al centro e scrivi "Backend" a sinistra e "Frontend" a destra.

Dove la tua applicazione sembra gonfia, ASCIUGA fuori. Dove la tua applicazione si sente complicata, prova un esercizio in cui reimmagini quella parte da zero. Amputare una pratica ingannevole e complicata, soprattutto se sta sprecando il tuo tempo di sviluppo.

Disegna nuovamente il tuo schema di livello superiore tre volte da zero e mantieni la mente agile e aperta a buttare fuori codice errato se ti fa risparmiare tempo in futuro.

Posso concepire alcune considerazioni da destreggiarsi, in ordine di priorità:

Prestazioni

• L'elaborazione della visualizzazione sul client potrebbe essere più lenta di quella sul server: l'utente noterà?
• L'elaborazione della visualizzazione sul server aumenterà il carico, eventualmente rallentando o ritardando altre richieste.
• I dati trasmessi dal server al client saranno più o meno se l'elaborazione viene eseguita sul server? Di quanto?

Se il rendimento in termini di prestazioni dell'elaborazione sul client è accettabile, potrebbe essere la scelta migliore.

Modifica della libreria di visualizzazione del grafico

È una buona idea disaccoppiare i moduli in un prodotto software in modo che le modifiche possano essere apportate a una senza influenzare le altre, ma a meno che tu non abbia un alto grado di certezza che dovrai modificare un dato modulo, introducendo la complessità supportarlo potrebbe imporre un prezzo non necessario.

Una diversa libreria di visualizzazione del grafico richiederebbe una diversa rappresentazione del grafico di input? Quindi è probabile che il lato server cambi con una nuova libreria, quindi potrebbe essere meglio eseguire l'elaborazione sul server per isolare il lato client.

Una libreria di visualizzazione di grafici diversa produrrebbe un output che deve essere consumato in modo diverso? Probabilmente il lato client dovrà essere modificato, quindi potrebbe essere meglio eseguire l'elaborazione sul lato client per isolare il lato server.

Modifiche all'API del server

L'elaborazione sul server richiederà una modifica all'API del server, ma non deve sostituire la possibilità di richiedere la rappresentazione JSON esistente che hai ora. Per fornire rappresentazioni diverse per la stessa risorsa, definire un tipo di supporto personalizzato per la rappresentazione di visualizzazione, ad esempio application/vnd.example.my-graph-display , quindi utilizzarlo quando il client richiede la visualizzazione della risorsa. Quando il client ha bisogno della rappresentazione JSON, usa application/json .

Infine, la soluzione per pianificare una futura sostituzione di Sigma.js con un'altra libreria di visualizzazione grafica è la stessa sia sul client o sul server: creare un'interfaccia per astrarre la libreria e scrivere un Adapter per tradurre le tue chiamate di interfaccia nell'API Sigma.js. Quando cambi le implementazioni di visualizzazione del grafico, scrivi un nuovo adattatore e puoi sostituire l'implementazione senza modificare il codice che utilizza l'interfaccia.