Pure Front-end JavaScript con API Web contro MVC con ajax

Sono anche un po 'scettico sul fatto che ogni nuova app web debba essere una SPA, ma una cosa sono al 100% venduta come generalista, con la maggior parte della sua esperienza sul lato client è un'architettura orientata ai servizi che distribuire dati grezzi anziché HTML al client è la strada da percorrere se si caricano pagine / viste precompilate dal server e si fanno molte cose dinamiche con i dati dopo il caricamento della pagina o si costruisce quasi tutto al 100% con JavaScript.

I motivi per cui questo è preferibile a un dev del lato client sono molto simili ai motivi per cui nessuno vuole l'HTML nel database. Cosa dovrebbe fare il Dev del lato client quando vuole ricorrere a un tavolo, ad esempio quando gli è stato consegnato l'HTML? Il costo delle prestazioni di gestione di tutto ciò sul client è banale rispetto a fare un'altra richiesta server per farlo per te. Inoltre, la costruzione di HTML è piuttosto ben coperta in JS-land. L'ordinamento dei dati e la creazione di nuove righe della tabella HTML al di fuori di esso è un lavoro piuttosto banale per un esperto del lato client.

E a che serve l'architettura back-end per un front-end per un altro dispositivo che potrebbe aver bisogno di fare qualcosa di esotico come i widget di implementazione che sono al 100% di tela o una struttura HTML completamente diversa? Perché un dev del lato client deve caricare uno studio visivo o bussare alla porta del back-end per realizzare un tweet rigorosamente di presentazione?

Per quanto riguarda le tue preoccupazioni sulla perdita della convalida del template strongmente tipizzato, credimi quando dico che se hai a che fare con uno sviluppatore competente sul lato client, non troverai .NET framework o strumento di Visual Studio che è più carbone -to-diamante-a-polvere-schifosamente anale di HTML ben formato, valido di quello che lui / lei è.

Dal punto di vista dello stack completo, mi piace perché significa che non avrò mai a che fare con la logica di business o app che alcuni yutz hanno deciso di inserire nel livello dei template. Per non parlare del carico per utente che si stacca dai server, mentre in molti casi migliora effettivamente l'esperienza di caricamento per l'utente nei moderni browser con computer moderni.

Penso che sia più facile ragionare sull'architettura back-end quando l'hai completamente isolata da tutte le presentazioni. Non stai più afferrando i dati per schiacciarli in qualche HTML. Lo stai mettendo insieme per creare una struttura dati indipendente dall'implementazione che si occupa più di un uso generale rispetto a quello che verrà fatto con l'altra parte. IMO, che tende a portare a una maggiore coerenza nel modo in cui le cose vengono gestite dal momento che i dati sono ora un obiettivo finale piuttosto che la seconda all'ultima fase di un processo e ci sono meno opportunità per i problemi non correlati di far passare i fili.

Offro il mio valore di 2 penny molto soggettivo (per quello che vale;)). Non c'è una risposta giusta o sbagliata a questo e ci sono molte considerazioni sul mondo reale oltre ai tuoi punti, ad esempio:

• Hai un'esperienza pertinente in casa? la creazione di un'app guidata dal cliente è molto diversa da una basata prevalentemente su server con un set di abilità completamente diverso.
• Quanto tempo desideri e quali browser devi supportare? - più fai sul client più problemi con il browser ti troverai ad affrontare; IE8 è doloroso e le prestazioni di JavaScript sono piuttosto scarse, ma ci sono molte aziende che eseguono setup XP / IE.
• Quali dispositivi verranno visualizzati dai tuoi utenti sul sito? L'analisi e l'analisi di JavaScript potrebbero essere veloci su una versione recente di Chrome, ma non su un dispositivo mobile precedente, soprattutto non su una grande quantità di JavaScript con un carico di logica aziendale al suo interno
• Quanto è importante il carico iniziale? La templatura del server è più veloce di quella del client

Questa lista non è affatto esaustiva e suona come un attacco al client che non è mia intenzione, ho realizzato siti con una strong enfasi sul front end.

Per me dipende in realtà dall'esperienza utente e dalla riutilizzabilità dell'API. Per indirizzare ognuno di questi.

Se stai realizzando un'app o offri un'API, è logico utilizzare un progetto API .Net, che quindi costituisce la logica, il controllo e l'implementazione di una piattaforma multipla. In questo scenario, un approccio client completo può essere favorevole, l'API può essere gestita separatamente e fornisce un'interfaccia alla tua applicazione. È possibile modificare comodamente la logica e il refactator e mantenere l'interfaccia allo stesso modo. Puoi facilmente scrivere diverse applicazioni per diversi media utilizzando lo stesso codice di background.

L'argomento più strong per una soluzione di front end pura (a mio avviso) è quella dell'esperienza utente.

Fa (considerando tutti gli aspetti negativi) una pura applicazione per browser JavaScript offre un sostanziale miglioramento dell'usabilità e dell'esperienza utente su un sito web tradizionale?

Quando si creano siti che funzionano come applicazioni native; Direi che la risposta è un ovvio sì. Tuttavia, la maggior parte dei siti non presenta questo taglio pulito, quindi si tratta di valutare se i flussi di lavoro degli utenti individuali traggono vantaggio da un'interfaccia altamente dinamica.

Prendo una visione abbastanza pragmatica di ciò, non è né una questione né una questione; JavaScript ovviamente giocherà molto felicemente insieme alle tecnologie Server e non dovrai scegliere l'uno o l'altro - ogni sito non è un'app web a singola pagina - ma non c'è niente che ti impedisca di usare Knockout, backbone e simili nelle singole pagine per migliorare le cose dove è ritenuto necessario.

Ho una relazione di amore-odio con applicazioni pesanti front-end.

Da una parte, mi piace scrivere JavaScript e adoro il browser come ambiente di esecuzione.

D'altra parte, entrambi si sentono come una macchina da corsa di Formula 1 con buchi nel motore. Si riduce davvero a questo: puoi evitare la duplicazione della logica di business tra C # e JavaScript? Se è così, usa qualsiasi metodo per generare la vista che ritieni meritevole. Se stai duplicando la logica di business in due lingue, potresti avere uno sviluppatore front-end che vuole solo scrivere JavaScript, e non riesce a vedere il quadro generale.

Per quanto riguarda le differenze tecniche:

Rendering parziale e consegna al client:

• Facile e veloce da implementare
• Impedisce che la logica di backend business venga duplicata sul front-end
• Può comportare un payload HTTP molto più grande per il browser. Non è una brutta cosa su un desktop con una connessione ad alta larghezza di banda. Molto male su un telefono debole mentre sei seduto su un treno dell'ora di punta che sfreccia sulla pista a 60 miglia all'ora e altri 1.000 telefoni cellulari si disconnettono simultaneamente da una torre cellulare e tentano di riconnettersi alla torre della cella successiva.

Consegna di JSON e rendering di un modello lato client:

• Può comportare un payload HTTP inferiore rispetto all'HTML, che può rendere l'applicazione più reattiva rispetto a connessioni di rete lente o inattendibili
• Molti linguaggi JavaScript dei template sono pienamente disponibili, il che significa che non abbiamo bisogno di un back-end solo per generare un codice HTML

A volte penso che i nuovi framework JavaScript stiano lanciando il bambino con l'acqua del bagno --- l'uomo spero di non diventare un programmatore scontroso e maldestro ...

Nella mia ultima applicazione ho combinato REST API e front-end JavaScript.

Quello che ho fatto è stato:

• Ho creato un'API REST per le operazioni CRUD.
• Ho creato un'applicazione Javascript che carica l'HTML predefinito modelli e popola con i dati restituiti dall'API REST.

Fondamentalmente il front-end JS comunica con l'API REST per le operazioni CRUD e popola l'HTML con i dati restituiti o creati, o rimuove i dati eliminati o aggiorna i dati modificati.

Quindi abbiamo puro HTML, abbiamo l'elaborazione fatta sul client, abbiamo meno utilizzo della larghezza di banda non dovendo caricare tutto l'HTML e possiamo offrire un'esperienza realmente Web 2.0 agli utenti.

Non eseguo convalide aziendali sul front end per la sicurezza e la duplicazione del codice, poiché chiunque può modificare i dati prima di inviarli al server e dobbiamo convalidare nuovamente i dati sul server. Pertanto, questo sarebbe facilmente violato. Tutte le convalide vengono eseguite sul back-end. Le convalide sul lato client sono fatte solo per i tipi di input.

Pro:

• Possibilità di apportare modifiche in HTML a causa del fatto che non viene generato di JS;
• Minore consumo di larghezza di banda usando ajax e JSON;
• Minor consumo dell'elaborazione del server, poiché l'HTML è popolato il lato client;
• Esperienza utente migliorata usando JS per cambiare lo schermo, permettendo uso di effetti e aumento della velocità di rendering.
• Migliore utilizzo del protocollo HTTP, utilizzando REST.

Contro:

• 2 applicazioni da mantenere;
• Dipende dall'elaborazione del client, che può essere negativa a causa di un hardware scadente.

Spero che questo aiuti.

Saluti,

Riguardo all'aspetto validation in Web Api - È possibile eseguire la "validazione del modello" e rispondere con una risposta http 400 di richiesta errata.

Consulta link