2012-09-25 23 views
6

im in attesa di costruire RT applicazioni web con NodeJS. Venendo da Rails, mi sono innamorato della programmazione di NodeJS e Async JS.scrittura applicazioni Real-Time con NodeJS

eseguire alcuni esperimenti con il nodo, e poi come ho gli strumenti e le risorse di ricerca per abituarsi con, ho ottenuto sopraffatto con il sacco di roba lì.

ho trovato è un sacco di librerie e componenti di là, e praticamente ottenuto confuso su come un grande scala ben redigendi e implementato RT web app dovrebbe essere costruito.

Quindi l'applicazione verrà eseguita su NodeJS, utilizzando il framework Express.

Ho letto su knockout.js, una libreria sul lato client per fornire elementi in tempo reale come l'aggiornamento automatico dell'interfaccia utente, e suppongo che potrei confinarlo con jQuery. Inoltre, ho trovato socket.io. L'autore dice: Socket.IO aims to make realtime apps possible in every browser and mobile device, blurring the differences between the different transport mechanisms. It's care-free realtime 100% in JavaScript. Così socket.io è circa la compatibilità. E a proposito di backbone.js? Dove va?

Con così tanta roba, mi sono scioccato. Cosa dovrei imparare? Quali moduli vale la pena studiare? Mi sto concentrando su NodeJS e Express ma la maggior parte dei libri/screencast copre vecchie versioni di nodejs. Quindi sono guidato dalla sua API ufficiale. Ora sto qui chiedendo il tuo consiglio e per organizzare in qualche modo tutte le informazioni là fuori. Correggimi se le mie supposizioni non sono precise, per favore indicami la giusta direzione e sentiti libero di suggerire qualsiasi altro modulo che possa aiutare nel mio apprendimento.

Grazie in anticipo

risposta

7

potrebbe essere utile per voi di separare le librerie laterali node.js del server (tramite NPM ecc ...) da tutto il lato client (browser) biblioteche e tecnologie come jQuery, spina dorsale , knockout ecc ... quando ci pensate. Anche il socket.io che espone una connessione socket persistente tra il browser e il server (per evitare il polling) non impone quali tecnologie lato client utilizzate.

Concentrarsi sull'esposizione di un solido web-api (random example) dal server e le tecnologie client possono essere scambiate, aumentate ecc. Senza alcun effetto sul server. L'unico posto che intersecano è se stai usando una tecnologia di visualizzazione come Jade. È anche un'opzione per avere una separazione pura in cui il server serve solo i file client e il client è un'applicazione javascript più spessa (utilizzando knockout, jquery, ecc.) Che chiama un buon server web API.

Alcune persone cercano di unificare i modelli client e server, ad esempio this article utilizzando backbone e nodo. Dipende dalla quantità di dati con cui lavori per dire se è fattibile, ma accoppia il client e il server e rende lo stato server che può avere aspetti negativi (scalabilità, richiede affinità, ecc ...). Personalmente, divento cauto su quanta magia (legatura, stato, sincronizzazione ecc ...). Nodo significa mantenere le cose semplici, leggere e veloci. È un server di rete front-end veloce.

I miei 2 centesimi (e alcuni possono non essere d'accordo). Inizia con il nodo sul server e scegli lo spazio di archiviazione (mongoDb ecc ...). Progetta a solid RESTful (hypermedia) API - una buona webapi indipendentemente dal client. Quindi inizia con un html/css/js di base, magari con un client jquery e aggiungi cose come knockout ecc ... man mano che espandi le tue competenze client. Ciò ti consentirà di sostituire le tue tecnologie client indipendentemente dal tuo server man mano che la nuova tecnologia cambierà (e lo faranno).

Questo è il segno distintivo di un sistema ben progettato - la capacità di sostituire componets/sotto-sistemi senza dover riscrivere tutto :)

Speranza che aiuta a chiarire un po 'della nebbia :)