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

Sto pianificando di scrivere un’applicazione web in stile spina dorsale / backbone.js che in pratica trasferisce semplicemente un file application.js di grandi dimensioni sul 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 del 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

  • Crea 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?

    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 biblioteche come il derby mostrano la promise, ma non ci sono ancora.

    Ne ho parlato di recente 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.

    Potrei 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.

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

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

    È progettato in modo tale da poter utilizzare una funzione require () simile a una preelaborata o al volo generata dall’origine del modulo, 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 controparte lato server per la sincronizzazione del modello, che sembrerebbe essere il primo objective che stai cercando, oltre a codice che ha senso essere condiviso, come modelli e convalida, per essere condivisa utilmente.

    Un’altra cosa da considerare è requirejs, che usa 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.

    Era richiesto il tempo reale? 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 veloce in esecuzione, a cui è ansible accedere con il file application.js. Immagino che tu possa caricare file js “classici” dal pubblico nel nodo tramite eval ().

    Le cose sono migliorate molto ora e cose del genere

    la codifica influenzata da browserify può aiutarci a raggiungere facilmente questo objective

    ci sarà sempre un codice non comune tra i lati server e client, ma l’objective sarà sempre quello di mantenere tutto il codice logico in diversi moduli (che verranno poi utilizzati da entrambi gli ambienti). Questo è anche meglio dal punto di vista TDD, inoltre mantiene il conteggio della tastiera più basso.

    Dai un’occhiata a cose come questo stack – http://mindthecode.com/lets-build-an-angularjs-app-with-browserify-and-gulp/

    Detto questo, la tua opzione1 non mi sembra gestibile, se avessi i coder giusti che codificano il codice giusto.