Comment dois-je écrire une application web node.js avec le code côté serveur et côté client?

Question

Je prévois d'écrire une application web style spine/backbone.js qui transfère simplement un gros fichier application.js au navigateur du client qui communique avec le backend node.js en utilisant ajax. Le problème est que je ne sais pas comment structurer un tel projet, puisque je n'ai jamais vu d'exemples d'une telle application. Je peux imaginer des avantages et des inconvénients avec différentes façons de le faire

• Conservez tout dans un dossier de projet. Le code côté client et le côté serveur résident dans les mêmes dossiers, ce qui signifie qu'ils peuvent partager des ressources telles que la validation des entrées de formulaire et les fichiers de langue. Cela semble être une bonne solution, mais je n'ai aucune idée de la façon dont je regrouperais uniquement le code dont le client a besoin, et non le code du serveur. En général, je ne sais pas comment accomplir cela. Si cela a déjà été fait, j'aimerais voir un exemple de code, peut-être même un repo git.

• Créez deux projets distincts. Un pour le client et un pour le serveur. Cela semble beaucoup plus simple et direct, mais pas aussi élégant quand il s'agit de partager des ressources. Je devrais écrire le code tel que la validation d'entrée de forme deux fois.

Des pensées?

Answer 1

Votre première situation est un scénario très délicat et je dirais que nous ne sommes pas encore là. Certains diront qu'il y a peu de raisons d'essayer d'y arriver, car les tâches avant/arrière seront toujours confiées à des tâches légèrement et parfois radicalement différentes. Les bibliothèques comme derby sont prometteuses, mais ne sont pas encore là. J'ai discuté de cela récemment avec un ami et nous sommes arrivés à la conclusion que peut-être le meilleur pari pour l'instant serait de sérialiser les modèles sur les Websockets, et ensuite s'assurer que le serveur de nœud et l'application client restent synchronisés.

Je peux travailler sur une telle bibliothèque, mais pour l'instant je suis encore en développement avec 2 dossiers et des copies de modèles des deux côtés. Le balisage de mise en page est envoyé depuis le serveur, tout le contenu étant rendu côté client après réception du JSON du serveur. Franchement, le montant de la duplication n'est pas vraiment important. Un peu irritant mais maintient également une plus grande flexibilité pour se développer dans des directions différentes.

Answer 2

Ce ne sera pas une réponse complète à votre question, mais une bibliothèque qui pourrait vous aider si vous choisissez de poursuivre une telle entreprise pourrait être Browserify.

Il est conçu pour que vous puissiez utiliser une fonction require() similaire avec un fichier js prétraité ou généré à la volée à partir de la source du module, contenant de nombreux modules différents. Ces modules peuvent être partagés avec le serveur via le même mécanisme require(). Je ne connais pas l'explication d'un backbone implémenté du côté serveur comme une partie serveur côté serveur pour la synchronisation du modèle, cela semblerait être le premier objectif que vous cherchez, en changeant le code qui a du sens pour être partagé, tels que les modèles et la validation, pour être utilement partagés. Une autre chose à considérer est requirejs, qui utilise des modules de chargement asynchrones plus traditionnels, mais fonctionne également dans node.js, permettant aux mêmes modules AMD d'être partagés entre le nœud et le code client.

Answer 3

Il y a un bon article traite de ce sujet: http://blog.nodejitsu.com/scaling-isomorphic-javascript-code

Answer 4

était-temps réel nécessaire? Sinon, l'approche de Derby pourrait être un peu trop lourde.Express.js propose une structure dans laquelle le client js est séparé dans un dossier public et fournit des méthodes pour exécuter une API RESTful rapide, à laquelle vous pouvez accéder avec votre application.js. Je suppose que vous pouvez charger des fichiers js «classiques» du public dans le nœud via eval() aussi.

Answer 5

Les choses ont beaucoup bougé avant maintenant, et des choses comme le codage influencé

de browserify peuvent nous aider à atteindre ce facilement

il y aura toujours un code hors du commun entre les côtés serveur et client, mais le but est toujours conserver tout le code logique dans différents modules (qui sont ensuite utilisés dans les deux environnements). Cela est également meilleur du point de vue TDD, et permet également de réduire le nombre de pressions sur votre clavier.

Jetez un oeil à des choses comme cette pile - http://mindthecode.com/lets-build-an-angularjs-app-with-browserify-and-gulp/

Cela dit que votre option1 ne semble pas facile à gérer pour moi, si vous aviez les codeurs à droite de codage le bon code.