Estructurando una aplicación Node.js y AngularJS

Estoy a punto de intentar mi primer proyecto AngularJS, y tiene sentido usar Node.js para el back-end, a pesar de que significa aprender AngularJS y Node.js desde cero al mismo time.

Lo primero que trato de entender es una buena estructura de files. Hasta ahora, mi plantilla pura de HTML / CSS tiene la siguiente estructura de directory …

_site/ Fonts/ Javascript/ SASS/ Stylesheets/ Index.html 

(_site es un directory de trabajo para PSD, etc.)

Encontré una estructura de directory de ejemplo para una aplicación Node.js / AngularJS aquí …

… que sugiere la siguiente estructura de directory.

 app.js --> Application configuration package.json --> For npm public/ --> All of the files to be used in on the client side css/ --> CSS files app.css --> Default stylesheet img/ --> Image files js/ --> JavaScript files app.js --> Declare top-level application module controllers.js --> Application controllers directives.js --> Custom AngularJS directives filters.js --> Custom AngularJS filters services.js --> Custom AngularJS services lib/ --> AngularJS and third-party JavaScript libraries angular/ angular.js --> The latest AngularJS angular.min.js --> The latest minified AngularJS angular-*.js --> AngularJS add-on modules version.txt --> Version number routes/ api.js --> Route for serving JSON index.js --> Route for serving HTML pages and partials views/ index.jade --> Main page for the application layout.jade --> Doctype, title, head boilerplate partials/ --> AngularJS view partials (partial jade templates) partial1.jade partial2.jade 

Entonces, esto se ve bastante bien para mí (excepto por el hecho de que no usaría Jade).

Todavía tengo las siguientes preguntas …

  1. Quiero mantener separados todos los files de front-end y back-end. Esta solución coloca todos los files front-end en el directory público / que tiene sentido porque la mayoría necesita ser pública, pero ¿tiene sentido colocar aquí las carpetas SASS y _site? Podría simplemente mantenerlos allí, pero no uploadlos cuando los ponga en producción, pero parece incorrecto porque no deberían ser públicos. Tampoco pertenecen al nivel raíz con todas las cosas de back-end.

  2. ¿No sería mejor cargar AngularJS desde un CDN ?

  3. Dado que el server solo tendrá que entregar una plantilla (la plantilla principal de la aplicación) y todos los demás HTML se buildán en el front-end, ¿no tendría más sentido mantener el file index.html estático, eliminar la carpeta de vistas y crear un parciales / carpeta en público / como lo hace la aplicación original AngularJS Seed?

Me doy count de que todo esto es una cuestión de opinión, y técnicamente podría ponerlos donde quiera, pero espero que alguien con más experiencia que yo pueda aconsejarme sobre las trampas de varias estructuras de directorys.

1) Por lo general, tiene algún sentido hacer que los files saas/less públicos, ya que es posible que desee utilizar la conversión less-> css del lado del cliente al realizar la debugging (less.js lo hace). Sin embargo, no estoy seguro de qué contiene su _site (por cierto, debe usar la carpeta en minúsculas para su proyecto, especialmente para las cosas públicas) .

2) Por lo general, es una buena práctica cargar AngularJS desde Google CDN en producción, usando solo una versión local para el desarrollo, podría tener dos layouts diferentes dependiendo de su entorno.

3) Incluso si el procesamiento del lado del cliente es el path a seguir, puede mantener la representación del layout / vistas del lado del server, es probable que lo necesite en algún momento (acceso de administrador, procesamiento de correo electrónico, etc.). Sin embargo, puede ser útil utilizar el nombre de los partials de AngularJS en la carpeta pública para ayudar a evitar la confusión entre las views lado del server y los partials lado del cliente.

Claramente debe ir por lo que parece ser la cosa más lógica para hacer en este momento, probablemente moverá las cosas a medida que se familiarice con el sistema exprés.


Debe verificar el marco expreso existente para ver cómo estructuran su aplicación. Por ejemplo, TowerJS tiene una carpeta de config bastante limpia, sin embargo mezclan el código del lado del server y del lado del cliente que personalmente no me gusta.

Verifique esta comparación de frameworks MVC de NodeJS para ver cómo otros hacen cosas. Sin embargo, claramente comenzaría con el código de vanilla express para tener el control total y comprender cómo funcionan las cosas antes de comprometerme en cualquiera de estos frameworks.

Las cosas se vuelven más fáciles a medida que pasa el time. He usado Yeoman para el front-end de AngularJS, y hace la vida mucho más fácil: http://yeoman.io/

Opción 1, MEAN.io

¡MEAN es un impresionante acrónimo! Prefiero la estructura de directory MEAN stack. ¡Usemos gente de convenciones! Solo usa la estructura de directorys de mean.io. MEAN también es útil porque arroja todas las cosas buenas como Grunt , Bower , etc.

Ingrese la descripción de la imagen aquí

Opción 2, Angular-seed + Express.js

He buscado en GitHub proyectos Node.js / AngularJS (probablemente no lo suficiente) y no he visto nada realmente bueno para una estructura de directorys inicial. Así que he fusionado el esqueleto Node.js Express.js (ejecutando Express.js desde la línea de command sin usar EJS ni Jade / Pug ) con el proyecto angular ( clonarlo desde GitHub ). Luego moví un montón de cosas. Esto es lo que se me ocurrió:


  • developer : cosas que solo los desarrolladores usarán. No necesita ser desplegado.
    • config – files de configuration de karma y otros.
    • scripts : scripts desarrollador (compilation, testing e implementación)
    • test – e2e y testings unitarias.
  • logs
  • node_modules : esta respuesta de desbordamiento de stack recomendada para poner esto en Git. Sin embargo, esto ahora puede estar obsoleto .
  • public – Esto viene casi directamente de la carpeta de aplicaciones de semillas angulares.
    • css , img , js , lib , partials : bastante obvio, agradable y corto.
  • routesroutes Node.js
  • server – progtwigs "shebang" Node.js del lado del server, daemons, progtwigs cron, lo que sea.
  • server.js – renombrado de app.js solo para hacerlo más obvio, esto es del lado del server.

Ingrese la descripción de la imagen aquí

Como se sugirió, en su mayoría se trata de preferences personales y lo que funciona para el proyecto en el que está trabajando en ese momento. Todo el mundo que le hable tendrá diferentes ideas, y cada proyecto tiene su propio layout: lo que funciona para uno puede no funcionar para el otro. Espero que pruebes algunas estructuras diferentes y pronto encontrarás una que sea la más cómoda, pero esto seguirá evolucionando con el time.

He descubierto que la estructura de Angular Seed es la más limpia, pero de nuevo es una preference personal (aunque es útil que haya sido diseñada por el equipo de Angular).

También podría considerar mirar a Yeoman para generar esqueletos de proyectos.

Yeoman es un set robusto y obstinado de herramientas, bibliotecas y un flujo de trabajo que puede ayudar a los desarrolladores a crear rápidamente aplicaciones web atractivas y atractivas.

Es una gran herramienta para iniciar y administrar proyectos (similar a la forma en que lo hace Rails) y creará una estructura de directorys y esqueletos para que usted pueda build. Brian Ford escribió una excelente publicación sobre el uso de Yeoman con Angular.

También sugiero ver las grabaciones de Meetup de Angular en su canal de YouTube. Recientemente asistí a una reunión en Mountain View donde surgieron estas preguntas. Miško recomendó Semillas angulares y Yeoman (al less como un buen punto de partida).

Para responder a sus preguntas individuales:

  1. Cualquier file que se comstack en el lado del server debe mantenerse fuera de su carpeta pública. Sugeriría que no se guarden los files PSD maestros, maquetas o cualquier otro file que no esté destinado al consumo público (ya sea por browser o usuario) dentro de carpetas públicas.

  2. Siempre es bueno servir activos estáticos (JS, imágenes, CSS) desde un CDN si espera una gran cantidad de tráfico. No es tan importante para los sitios less visitados, pero sigue siendo una buena idea. Comenzaría por servir los files localmente para el desarrollo inicial. Deje la optimization de activos para cuando se acerque a su date de transmisión. Cuando llegue este momento, también querrás configurar tu almacenamiento en caching correctamente. Yeoman, por ejemplo, presenta una buena forma de versionar sus activos. Esto le da la ventaja de las memorys caching de larga duración, pero le permite enviar actualizaciones de los files a los clientes.

  3. Si su file de índice no requiere ninguna representación del lado del server, sírvalo estáticamente. Me gusta mantener mi backend desacoplado del backend tanto como sea posible con las aplicaciones de Angular. Ayuda a mantener la separación de la preocupación; Al desarrollar los files del cliente, no necesita pensar en el backend (Angular es ideal para esto).

Realmente, solo necesitas jugar; Pruebe cosas diferentes, lea publicaciones en el blog, obtenga ideas de otros, haga preguntas (como lo ha hecho aquí, y en la página de la comunidad Angular de Google+), mire videos y, si puede, asista a reuniones: los Encuentros son realmente geniales para esto.

No estoy de acuerdo con todas las publicaciones anteriores. Ellos están pegados desde otro lugar o no tienen su propia mente. Según mis experiencias, es mejor aplanar los códigos del lado del cliente. Quiero decir que el código dentro de tu directory de cliente debe estar en tu directory raíz.

¿Por qué sugiero de esta manera? Porque si desea cambiar su proyecto de JavaScript de stack completa por uno sin back-end, pero solo incluye el frontend, es mucho más fácil. Quiero decir que la mayoría de los proyectos escritos con JavaScript se centran en la interfaz.

Es mejor poner su código de back-end en un directory como "server" en el mismo nivel de carpeta que como "css", "image" … La ventaja de esto es que cuando necesita o no necesita un back-end, simplemente agregue o elimine el directory "server", y no afectaría la estructura del proyecto de origen.

Me gusta esto:

Ingrese la descripción de la imagen aquí

Estaba investigando exactamente lo mismo.

Mis pensamientos iniciales se dirigieron hacia el uso de Express Generator y Angular Seed .

Entonces encontré una solución mucho más agradable:

Uno de los generadores yeoman más populares le proporciona una estructura para las aplicaciones Node.js y AngularJS.

Creo en el poder de la estandarización y las nuevas personas que se unan al proyecto apreciarán la estructura unificada.

Mira este esqueleto

https://github.com/Giancarlo1974/SailsAngular

Se integra Angular 4 + Bootstrap 4 para el cliente y Node Sails JS para el server

Uno de los puntos fuertes de esta solución es: 1) Automatización de tareas 2) Agnosticismo de la database