¿Cómo debo escribir una aplicación web node.js con el código del servidor y del lado del cliente?

Question

Estoy planeando escribir una aplicación web de estilo spine/backbone.js que básicamente transfiere un gran archivo application.js al navegador del cliente que se comunica con el backend node.js usando ajax. El problema es que no sé cómo estructurar ese proyecto, ya que nunca he visto ejemplos de tal aplicación. Puedo imaginar algunos pros y contras con diferentes formas de hacerlo

• Mantenga todo en una carpeta de proyectos. Tanto el lado del servidor como el del lado del cliente residen en las mismas carpetas, lo que significa que pueden compartir recursos como la validación de entrada del formulario y los archivos de idioma. Parece una buena solución, pero no tengo ni idea de cómo combinaría solo el código que necesita el cliente, y no el código del servidor. En general, no sé cómo lograr esto. Si se ha hecho antes, me gustaría ver algún código de muestra, tal vez incluso un git repo

• Crea dos proyectos por separado. Uno para el cliente y otro para el servidor. Esto parece mucho más simple y directo, pero no tan elegante cuando se trata de compartir recursos. Tendría que escribir código como validación de entrada de formulario dos veces.

¿Alguna idea?

Answer 1

Su primera situación es muy complicada y sugeriría que todavía no hemos llegado. Algunos argumentarían que hay pocas razones para tratar de llegar allí, ya que los extremos frontales/posteriores siempre tendrán la tarea de tareas ligeramente diferentes y, a veces, drásticamente diferentes. Bibliotecas como derby son prometedoras, pero aún no están del todo disponibles.

Discutí esto recientemente con un amigo y llegamos a la conclusión de que tal vez la mejor apuesta por el momento sería serializar modelos sobre websockets, y luego asegurarnos de que el servidor de nodos y la aplicación cliente permanecen sincronizados.

Puedo trabajar en una biblioteca de este tipo, pero por ahora todavía estoy desarrollando con 2 carpetas y copias de modelos en ambos lados. El marcado de diseño se envía desde el servidor, y el resto del contenido se muestra en el lado del cliente después de recibir JSON del servidor. Francamente, la cantidad de duplicación no es tan sustancial. Un poco irritante pero también mantiene una mayor flexibilidad para crecer en diferentes direcciones.

Answer 2

Esta no será una respuesta completa a su pregunta, pero una biblioteca que podría ayudar si decide realizar tal esfuerzo podría ser Browserify.

Está diseñado para que pueda usar una función require() similar con un archivo preprocesado o sobre la marcha generado a partir de un módulo, js que contiene muchos módulos diferentes. Estos módulos se pueden compartir con el lado del servidor a través del mismo mecanismo require().

No conozco la especificidad de una red troncal implementada en el servidor como una parte del servidor para la sincronización del modelo, que parece ser el primer objetivo que está buscando, alojando el código que tiene sentido para ser compartido, tales como modelos y validación, para compartir de manera útil.

Otro aspecto a tener en cuenta es requirejs, que utiliza módulos de carga asíncrona de etiqueta de script más tradicionales fjs, pero también funciona en node.js alojando los mismos módulos de AMD para ser compartido entre el código de nodo y el de cliente.

Answer 3

Hay un buen artículo cubrir este tema: http://blog.nodejitsu.com/scaling-isomorphic-javascript-code

Answer 4

se requería tiempo real? De lo contrario, el enfoque Derby podría ser un poco demasiado pesado.Express.js propone una estructura donde el cliente js se separa en una carpeta pública y proporciona métodos para ejecutar una API RESTful rápida, que luego puede acceder con su application.js. Supongo que puede cargar archivos js "clásicos" de público a nodo a través de eval() también.

Answer 5

Las cosas han cambiado mucho por delante ahora, y cosas como

browserify codificación influenciada pueden ayudar a lograr esto fácilmente

siempre habrá algo de código infrecuente entre servidor y cliente lados, pero el objetivo será siempre para mantener todo el código lógico en diferentes módulos (que luego se utilizan en ambos entornos). Esto también es mejor desde el punto de vista de TDD, también mantiene el conteo de su teclado en menos.

Tener un vistazo a cosas como esta pila - http://mindthecode.com/lets-build-an-angularjs-app-with-browserify-and-gulp/

Habiendo dicho que su option1 no parecía que manejable para mí, si tuviera los codificadores adecuados de codificación del código correcto.