with setup práctico nodejs node example ejemplo diferencias con bootstrap app javascript angularjs node.js

javascript - setup - Estructurando una aplicación Node.js y AngularJS



node js angular 4 (6)

1) Por lo general, tiene algún sentido hacer que los archivos saas/less públicos, ya que es posible que desee utilizar la conversión menos-> css del lado del cliente al realizar la depuración (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 diseños diferentes dependiendo de su entorno.

3) Incluso si el procesamiento del lado del cliente es el camino a seguir, puede mantener la representación del diseño / vistas del lado del servidor, 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 servidor 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 servidor y del lado del cliente que personalmente no me gusta.

Verifique esta comparación de marcos 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.

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 tanto AngularJS como Node.js desde cero al mismo tiempo.

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

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

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

Encontré una estructura de directorio de ejemplo para una aplicación Node.js / AngularJS here ...

... que sugiere la siguiente estructura de directorio.

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 archivos de front-end y back-end. Esta solución coloca todos los archivos front-end en el directorio 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 subirlos 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 servidor solo tendrá que entregar una plantilla (la plantilla principal de la aplicación) y todos los demás HTML se construirán en el front-end, ¿no tendría más sentido mantener el archivo 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 cuenta 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 directorios.

Como se sugirió, en su mayoría se trata de preferencias 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 diseño: 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 tiempo.

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

También podría considerar mirar a http://yeoman.io/ para generar esqueletos de proyectos.

Yeoman es un conjunto 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 directorios y esqueletos para que pueda construir. 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 menos como un buen punto de partida).

Para responder a sus preguntas individuales:

  1. Cualquier archivo que se compila en el lado del servidor debe mantenerse fuera de su carpeta pública. Sugeriría que no se guarden los archivos PSD maestros, maquetas o cualquier otro archivo que no esté destinado al consumo público (ya sea por navegador 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 menos visitados, pero sigue siendo una buena idea. Comenzaría por servir los archivos localmente para el desarrollo inicial. Deje la optimización de activos para cuando se acerque a su fecha de transmisión. Cuando llegue este momento, también querrás configurar tu almacenamiento en caché correctamente. Yeoman, por ejemplo, presenta una buena forma de versionar sus activos. Esto le da la ventaja de las memorias caché de larga duración, pero le permite enviar actualizaciones de los archivos a los clientes.

  3. Si su archivo de índice no requiere ninguna representación del lado del servidor, 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 archivos 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.

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.

Las cosas se vuelven más fáciles a medida que pasa el tiempo. 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 directorio MEAN stack. ¡Usemos gente de convenciones! Solo usa la estructura de directorios de mean.io. MEAN también es útil porque arroja todas las cosas buenas como Grunt , Bower , etc.

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 directorios inicial. Así que he fusionado el esqueleto Node.js Express.js (ejecutando Express.js desde la línea de comando 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 - archivos de configuración de karma y otros.
    • scripts : scripts desarrollador (compilación, prueba e implementación)
    • test - e2e y pruebas unitarias.
  • logs
  • node_modules : esta respuesta de desbordamiento de pila 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.
  • routes - routes Node.js
  • server - programas "shebang" Node.js del lado del servidor, daemons, programas cron, lo que sea.
  • server.js - renombrado de app.js solo para hacerlo más obvio, esto es del lado del servidor.

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 directorio de cliente debe estar en tu directorio raíz.

¿Por qué sugiero de esta manera? Porque si desea cambiar su proyecto de JavaScript de pila 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 directorio como "servidor" en el mismo nivel de carpeta que como "css", "imagen" ... La ventaja de esto es que cuando necesita o no necesita un back-end, simplemente agregue o elimine el directorio "servidor", y no afectaría la estructura del proyecto de origen.

Me gusta esto: