JavaScript front-end puro con API Web rispetto alle visualizzazioni MVC con ajax

Questa è stata più una discussione per ciò che i pensieri delle persone sono in questi giorni su come dividere un'applicazione web.

Sono abituato a creare un'applicazione MVC con tutte le sue viste e controller. Normalmente creerei una vista completa e la restituirei al browser su una richiesta a pagina intera, a meno che non ci fossero aree specifiche che non volevo popolare subito e quindi avrei usato gli eventi di caricamento della pagina DOM per chiamare il server per caricare altre aree usando AJAX.

Inoltre, quando si trattava di un aggiornamento parziale della pagina, chiamavo un metodo di azione MVC che restituiva il frammento HTML che avrei potuto usare per popolare parti della pagina. Questo sarebbe per le aree che non volevo rallentare il caricamento iniziale della pagina o per quelle che si adattavano meglio alle chiamate AJAX. Un esempio potrebbe essere il paging della tabella. Se vuoi passare alla pagina successiva, preferirei che una chiamata AJAX ottenesse tali informazioni piuttosto che utilizzare un aggiornamento di pagina intera. Ma la chiamata AJAX restituirà comunque un frammento HTML.

La mia domanda è. Sono i miei pensieri su questo arcaico perché vengo da uno sfondo .net piuttosto che da uno sfondo puro front-end?

Uno sviluppatore di front-end intelligente con cui lavoro, preferisce non fare più o meno nulla nelle visualizzazioni MVC e preferirebbe fare tutto sul front-end. Fino alle chiamate API Web che popolano la pagina. Quindi, piuttosto che chiamare un metodo di azione MVC, che restituisce HTML, preferirebbe restituire un oggetto standard e usare javascript per creare tutti gli elementi della pagina.

Il modo di sviluppatore del front-end significa che qualsiasi vantaggio che ottengo normalmente con la convalida del modello MVC, inclusa la convalida lato client, sarebbe sparito. Significa anche che qualsiasi beneficio che ottengo con la creazione delle viste, con modelli html fortemente tipizzati ecc.

Credo che ciò significherebbe che avrei bisogno di scrivere la stessa validazione per la validazione front-end e back-end. Il javascript dovrebbe anche avere molti metodi per creare tutte le diverse parti del DOM. Ad esempio, quando aggiungo una nuova riga a una tabella, normalmente utilizzerei la vista parziale MVC per creare la riga, e quindi la restituire come parte della chiamata AJAX, che viene quindi iniettata nella tabella. Usando un modo front-end puro, il javascript prenderebbe un oggetto (per esempio un prodotto) per la riga dalla chiamata API e quindi creerebbe una riga da quell'oggetto. Creazione di ogni singola parte della riga della tabella.

Il sito Web in questione avrà molte aree diverse, dall'amministrazione, ai moduli, alla ricerca di prodotti, ecc. Un sito Web che non credo debba essere progettato in un'unica applicazione.

Quali sono i pensieri di tutti su questo?

Sono interessato a sentire dagli sviluppatori front-end e dagli sviluppatori back-end.

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

I motivi per cui questo è preferibile a un sviluppatore sul lato client sono molto simili ai motivi per cui nessuno vuole HTML nel database. Che cosa dovrebbe fare lo sviluppatore lato client quando desidera ricorrere a un tavolo, ad esempio quando gli viene consegnato l'HTML? Il costo delle prestazioni di gestione di tutto ciò che è sul client è banale rispetto al fare un'altra richiesta del 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 di tabelle HTML da esso è un lavoro piuttosto banale per uno sviluppatore lato client esperto.

E a che serve l'architettura back-end a un front-end per un altro dispositivo che potrebbe aver bisogno di fare qualcosa di esotico come implementare widget che sono canvas al 100% o una struttura HTML totalmente diversa? Perché un sviluppatore lato client dovrebbe caricare Visual Studio o bussare alla porta degli sviluppatori back-end per apportare una modifica strettamente presentativa?

Per quanto riguarda le tue preoccupazioni sulla perdita della convalida del modello fortemente tipizzato, fidati di me quando dico che se hai a che fare con uno sviluppatore lato client competente, non troverai alcun framework .NET o strumento di Visual Studio più carbone-to- analista da diamante a polvere su un HTML ben formato e valido di quello che è.

Dal punto di vista dello stack completo, mi piace perché significa che non dovrò mai cercare la logica aziendale o delle app che alcuni yutz hanno deciso di abbandonare nel livello dei modelli. Per non parlare del carico per utente che viene rimosso dai server mentre in molti casi migliora effettivamente l'esperienza di caricamento per l'utente nei browser moderni con computer moderni.

Penso che sia anche più facile ragionare sull'architettura back-end quando l'hai completamente isolata da tutte le cose di presentazione. Non stai più afferrando i dati per trasformarli in un po 'di HTML. Lo stai mettendo insieme per creare una struttura di dati indipendente dall'implementazione che si preoccupa più di un uso generale di quello che verrà fatto dall'altra parte. IMO, che tende a portare a una maggiore coerenza nel modo in cui le cose vengono gestite poiché i dati sono ora un obiettivo finale piuttosto che il secondo all'ultimo passaggio di un processo e ci sono meno opportunità per le preoccupazioni non correlate di incrociare i loro fili.

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

• Hai l'esperienza pertinente in casa? la creazione di un'app guidata dal lato client è molto diversa da un'app basata principalmente sul server con un set di competenze completamente diverso.
• Quanto tempo vuoi che impieghi e quali browser devi supportare? - più fai sul client più problemi con il browser dovrai affrontare; IE8 è doloroso e le prestazioni JavaScript sono piuttosto scarse, ma ci sono molte aziende che eseguono configurazioni XP / IE.
• Su quali dispositivi verranno visualizzati i tuoi utenti dal sito? L'analisi e l'esecuzione di JavaScript potrebbero essere veloci su una versione recente di Chrome, ma non su un dispositivo mobile precedente, in particolare non una grande quantità di JavaScript con un carico di logica aziendale
• Quanto è importante il carico iniziale? Il template del server è più veloce del template del client

Questo elenco non è affatto esaustivo e sembra un bashing lato client che non è mia intenzione, ho realizzato siti con una forte enfasi sul front-end.

Per me dipende davvero dall'esperienza utente e dalla riusabilità dell'API. Per affrontare ciascuno di questi.

Se stai per creare un'app o offrire un'API, ha molto senso utilizzare un progetto API .Net, questo quindi costituisce la logica, il controllo e l'implementazione multipiattaforma. In questo scenario può essere favorevole un approccio lato client completo, l'API può essere gestita separatamente e fornisce semplicemente un'interfaccia per l'applicazione. È possibile modificare comodamente la logica e il refactor e mantenere l'interfaccia invariata. È possibile scrivere facilmente diverse applicazioni per supporti diversi utilizzando lo stesso codice di sfondo.

L'argomento più forte per una soluzione di front-end puro (secondo me) è quello dell'esperienza dell'utente.

(Se si considerano tutti gli aspetti negativi) un'applicazione browser JavaScript pura offre un miglioramento sostanziale 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 ha questo taglio netto, quindi si tratta di valutare se i flussi di lavoro di singoli utenti traggono vantaggio da un'interfaccia altamente dinamica.

Prendo una visione abbastanza pragmatica di ciò, non è né una cosa né una questione; JavaScript ovviamente giocherà abbastanza felicemente con le tecnologie Server e non devi scegliere l'uno o l'altro - ogni sito non è un'app Web a pagina singola - ma non c'è nulla che ti fermi usando Knockout, backbone e simili su singole pagine per migliorare le cose dove è ritenuto necessario.

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

Da un lato, adoro scrivere JavaScript e adoro il browser come ambiente di esecuzione.

D'altra parte, entrambi sembrano una macchina da corsa di Formula 1 con buchi nel motore. Si riduce davvero a questo: puoi impedire la duplicazione della logica di business tra C # e JavaScript? In tal caso, utilizzare qualsiasi metodo per generare la vista che ritieni degna. Se stai duplicando la logica di business in due lingue, potresti avere uno sviluppatore front-end che vuole solo scrivere JavaScript e non ha una visione d'insieme.

Per quanto riguarda le differenze tecniche:

Rendering di un parziale e consegna al cliente:

• Facile e veloce da implementare
• Impedisce la duplicazione della logica di business back-end 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 cellulare debole mentre si è seduti su un treno dell'ora di punta che accelera giù per la pista a 60 miglia all'ora e 1.000 altri telefoni cellulari si disconnettono simultaneamente da un ripetitore cellulare e provano a riconnettersi al ripetitore successivo.

Fornitura di JSON e rendering di un modello lato client:

• Può comportare un payload HTTP più piccolo rispetto all'HTML, il che può rendere l'applicazione più reattiva su connessioni di rete inaffidabili o lente
• Molti linguaggi di template JavaScript sono completamente disponibili, il che significa che non abbiamo bisogno di un backend solo per generare un po 'di HTML

A volte penso che i nuovi framework JavaScript stiano gettando il bambino fuori con l'acqua della vasca da bagno --- amico, spero di non diventare un programmatore scontroso di curmudgeon ...

Nella mia ultima applicazione ho combinato API REST 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 modelli HTML predefiniti 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, oppure rimuove i dati cancellati o aggiorna i dati modificati.

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

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 hackerato. Tutte le convalide vengono eseguite sul back-end. Le convalide sul lato client vengono effettuate solo per i tipi di input.

Professionisti:

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

Contro:

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

Spero che sia di aiuto.

Saluti,

Per quanto riguarda l' validationaspetto di Web Api: è possibile eseguire la "convalida del modello" e rispondere con una risposta http di 400 richieste errate.

Consultare /programming/11686690/handle-modelstate-validation-in-asp-net-web-api/25050285#25050285