Come dovrei andare a scrivere un'applicazione web node.js con codice lato server e client?

Question

Sto pianificando di scrivere un'applicazione web stile spina dorsale/backbone.js che in pratica trasferisce semplicemente un file application.js di grandi dimensioni nel browser del client che comunica con il backend node.js utilizzando ajax. Il problema è che non so come strutturare un progetto del genere, dal momento che non ho mai visto esempi di tale applicazione. Posso immaginare alcuni pro e contro con diversi modi per farlo

• Mantieni tutto in una cartella di progetto. Sia il lato server che il codice lato client risiedono nelle stesse cartelle, il che significa che possono condividere risorse come la convalida dell'input dei moduli e i file di linguaggio. Questa sembra una buona soluzione, ma non ho idea di come raggrupperei solo il codice di cui il client ha bisogno, e non il codice del server. Solo in generale, non so come farlo. Se è stato fatto prima, mi piacerebbe vedere qualche codice di esempio, forse anche un repository git

• Creare due progetti separati. Uno per il client e uno per il server. Questo sembra molto più semplice e diretto, ma non così elegante quando si tratta di condividere risorse. Dovrei scrivere codice come convalida dell'input del modulo due volte.

Qualche idea?

Answer 1

La tua prima situazione è uno scenario molto complicato e suggerirei che non siamo ancora arrivati. Qualcuno potrebbe obiettare che ci sono poche ragioni per provare ad arrivarci, dato che i front-end saranno sempre incaricati di compiti leggermente e talvolta drasticamente diversi. Le librerie come derby mostrano promessa, ma non sono ancora del tutto disponibili.

Ne ho discusso recentemente con un amico e siamo giunti alla conclusione che forse la migliore scommessa per ora sarebbe quella di serializzare i modelli su websocket, e quindi assicurarsi che il server nodo e l'app client rimangano sincronizzati.

Posso lavorare su una tale libreria, ma per ora sto ancora sviluppando con 2 cartelle e copie di modelli su entrambi i lati. Il markup del layout viene inviato dal server, con tutti gli altri contenuti resi sul lato client dopo aver ricevuto JSON dal server. Francamente, la quantità di duplicati non è così sostanziale. Un po 'irritante ma mantiene anche una maggiore flessibilità per crescere in direzioni diverse.

Answer 2

Questa non sarà una risposta completa alla tua domanda, ma una libreria che potrebbe aiutarti se scegli di perseguire tale sforzo potrebbe essere Browserify.

È progettato in modo da poter utilizzare una funzione require() simile con un pre-elaborato o al volo generato dall'origine del modulo, il file js contenente molti moduli diversi. Questi moduli possono essere condivisi con il lato server attraverso lo stesso meccanismo require().

Non conosco l'essenza di un Backbone implementato sul lato server come parte del contatore lato server per la sincronizzazione del modello, che sembrerebbe essere il primo obiettivo che si sta cercando, oltre al codice che ha senso essere condiviso, come i modelli e la convalida, per essere condivisi in modo utile.

Un'altra cosa da osservare è requirejs, che utilizza più tradizionali tag di script che caricano moduli f js asincroni, ma funziona anche all'interno di node.js, consentendo di condividere gli stessi moduli AMD tra il nodo e il codice client.

Answer 3

C'è un buon articolo coprire questo argomento: http://blog.nodejitsu.com/scaling-isomorphic-javascript-code

Answer 4

È stato in tempo reale richiesto? Altrimenti l'approccio Derby potrebbe essere un po 'troppo pesante.Express.js propone una struttura in cui il client js è separato in una cartella pubblica e fornisce metodi per ottenere un'API RESTful rapida in esecuzione, a cui è possibile accedere con il file application.js. Immagino che tu possa caricare file js "classici" dal pubblico nel nodo tramite eval().

Answer 5

Le cose si sono spostati molto più avanti ora, e cose del genere

browserify codifica influenzato possono aiutarci a raggiungere questo facilmente

ci sarà sempre un certo codice non comuni tra server e client lati, ma l'obiettivo deve essere sempre per mantenere tutto il codice logico in diversi moduli (che vengono successivamente utilizzati da entrambi gli ambienti). Questo è anche meglio dal punto di vista TDD, inoltre mantiene il conteggio della tastiera più basso.

Date un'occhiata a cose come questa stack - http://mindthecode.com/lets-build-an-angularjs-app-with-browserify-and-gulp/

Detto che il vostro opzione1 non sembrava che gestibile a me, se tu avessi i programmatori giusti codifica il codice giusto.