Структурирование приложения Node.js и AngularJS

Я собираюсь попробовать свой первый проект AngularJS, и имеет смысл использовать Node.js для задней части, хотя это означает одновременное изучение как AngularJS, так и Node.js.

Первое, что я пытаюсь раздобыть, - хорошая файловая структура. Пока мой чистый шаблон HTML/CSS имеет следующую структуру каталогов...

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

(_site - это рабочий каталог для PSD и т.д.)

Я нашел примерную структуру каталогов для Node.js/AngularJS app здесь....

..., который предлагает следующую структуру каталогов.

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

Итак, это выглядит неплохо для меня (за исключением того, что я не буду использовать Jade).

У меня все еще есть следующие вопросы...

  • Я хочу, чтобы все интерфейсные и клиентские файлы были разделены. Это решение ставит все файлы front-end в общедоступный/каталог, который имеет смысл, потому что большинство должно быть общедоступным, но имеет ли смысл размещать здесь SASS и _site? Я мог бы просто держать их там, но не загружать их, когда я их запускаю, но это кажется неправильным, потому что они не должны быть публичными. Они также не относятся к корневому уровню со всеми исходными материалами.

  • Не лучше ли загружать AngularJS из CDN?

  • Учитывая, что серверу потребуется только один шаблон (основной шаблон приложения), и все остальные HTML будут построены на интерфейсе, не имеет смысла держать файл index.html статическим, удалите папку представлений и создайте папку partials/public под общим/как это делает оригинальное приложение SealJS Seed?

Я понимаю, что все это вопрос мнения, и я мог бы технически разместить их там, где захочу, но я надеюсь, что кто-то более опытный, чем я, мог бы посоветовать мне подводные камни различных структур каталогов.

Ответ 1

1) Как правило, имеет смысл сделать файлы saas/less общедоступными, так как вы захотите использовать на стороне клиента less- > css-преобразование при отладке (less.js делает это). Не уверен, что у вас есть _site (кстати, вы должны использовать папку нижнего регистра для своего проекта, особенно для общедоступных вещей).

2) Обычно рекомендуется загружать AngularJS из Google CDN при производстве, используя только локальную версию для разработки, вы можете иметь два отдельных макета в зависимости от вашей среды.

3) Даже если рендеринг на стороне клиента - это способ, вы можете сохранить рендеринг макета/представлений на стороне сервера, вам, вероятно, понадобится его в какой-то момент (доступ администратора, рендеринг электронной почты и т.д.). Однако может быть полезно использовать имя partials из AngularJS в общей папке, чтобы избежать путаницы между серверной стороной views и клиентской стороной partials.

Вы должны явно пойти на то, что кажется наиболее логичным в текущее время, вы, вероятно, будете двигаться вокруг, когда будете знакомы с выражением.


Вы должны проверить существующую структуру Express, чтобы посмотреть, как они структурируют свое приложение. Например, TowerJS имеет довольно чистую папку config, однако они смешивают серверный и клиентский код, которые я лично делаю не нравится.

Проверьте это comparaison NodeJS MVC frameworks, чтобы увидеть, как другие делают вещи. Тем не менее, я бы явно начал с кода ванильного экспресса, чтобы быть в полном контроле и понимать, как все работает, прежде чем перехватывать какие-либо из фреймворков.

Ответ 2

С течением времени все становится легче. Я использовал Yoman для front-end AngularJS, и это облегчает жизнь: http://yeoman.io/

Вариант 1, MEAN.io

MEAN - удивительный акроним! Я предпочитаю структуру каталога стека MEAN. Пусть используют людей конвенций! Просто используйте структуру каталогов из mean.io. MEAN тоже удобен, потому что он выбрасывает все лакомства, такие как Grunt, Bower и т.д.

Enter image description here

Вариант 2, Angular -seed + Express.js

Я искал GitHub для проектов Node.js/AngularJS (возможно, недостаточно сложно) и не видел ничего хорошего для начальной структуры каталогов. Поэтому я объединил Node.js Express.js(запустил Express.js из командной строки, не используя EJS и Jade/Pug) скелет с Angular - (клонировать его из GitHub). Затем я переместил массу вещей вокруг. Вот что я придумал:


  • developer - материал, который будет использовать только разработчик (ы). Не требуется развертывание.
    • config - файлы конфигурации кармы и другие.
    • scripts - скрипты разработчика (сборка, тестирование и развертывание)
    • test - e2e и модульные тесты.
  • logs
  • node_modules - этот столбец и ответ на переполнение рекомендуется поместить в Git. Однако это может быть устаревшим.
  • public - Это почти прямо из папки Angular -seed.
    • css, img, js, lib, partials - довольно очевидный и приятный и короткий.
  • routes - Node.js.
  • server - серверная "shebang" Node.js программы, демоны, программы cron, что угодно.
  • server.js - переименован из app.js, чтобы сделать его более очевидным, это серверная сторона.

Enter image description here

Ответ 3

Как и предполагалось, в основном это зависит от личных предпочтений и того, что работает для проекта, над которым вы работаете в то время. Каждый, с кем вы разговариваете с вами, будет иметь разные идеи, и каждый проект имеет собственный дизайн - то, что работает для одного, может не работать для другого. Я ожидаю, что вы попробуете несколько разных структур и скоро найдете тот, который будет наиболее удобным - но это все равно будет развиваться с течением времени.

Я обнаружил, что структура Seed Angular является самой чистой, но опять же, что личные предпочтения (хотя это помогает, что она разработана командой Angular).

Вы также можете рассмотреть Yeoman для создания скелетов проекта.

Yeoman - это надежный и упрямый набор инструментов, библиотек и рабочий процесс, который может помочь разработчикам быстро создавать красивые, привлекательные веб-приложений.

Это отличный инструмент для начальной загрузки и управления проектами (аналогично тому, как это работает Rails), и создаст структуру каталогов и файлы скелетов, которые вы сможете использовать. Брайан Форд написал отличный пост об использовании Yeoman с Angular.

Я также предлагаю посмотреть записи Angular на своем канале YouTube. Недавно я посетил встречу в Mountain View, где возникли эти вопросы. Мишко рекомендовал Angular Seed and Yeoman (по крайней мере, как хорошую отправную точку.)

Чтобы ответить на ваши индивидуальные вопросы:

  • Любые файлы, скомпилированные на стороне сервера, должны храниться вне вашей общей папке. Я бы предложил не держать таких мастеров PSD, макеты или любые другие файлы, которые не предназначены для публичных (браузером или пользователем) внутри общих папок.

  • Всегда полезно обслуживать статические активы (JS, изображения, CSS) из CDN, если вы ожидаете большой объем трафика. Это не так важно для менее посещаемых сайтов, но все же хорошая идея. Я начну с обслуживая файлы локально для начальной разработки. Оставить актив оптимизация, когда вы приближаетесь к своей живой дате. Когда это придет время, вы также захотите, чтобы ваше кеширование было настроено правильно. Например, Йомен представляет хороший способ управлять вашими активами. Это дает вам преимущество долговечных кэшей, но позволяет вам нажимать обновления файлов клиентам.

  • Если вы - индексный файл, не требующий рендеринга на стороне сервера, служить ему статически. Мне нравится, чтобы мой backend был отделен от как можно больше с помощью Angular приложений. Это помогает поддерживать разделение озабоченности; при разработке клиентских файлов вы не нужно думать о бэкэнде вообще (Angular отлично подходит для этого.)

Действительно, вам просто нужно поиграть; пробовать разные вещи, читать сообщения в блогах, получать идеи от других, задавать вопросы (как вы это делали здесь и на странице сообщества Angular Google+), просматривать видеоролики и, если можно, посещать встречи - Meetups действительно отлично подходят для это.

Ответ 4

Я не согласен со всеми предыдущими сообщениями. Они либо вставляются из другого места, либо не имеют собственного ума. Из моего опыта лучше сгладить ваши клиентские коды. Я имею в виду, что код внутри вашего каталога клиента должен находиться в корневом каталоге.

Почему я предлагаю этот способ? Потому что, если вы хотите изменить свой проект JavaScript с полным стеком на один без бэкэнд, но только с интерфейсом, это намного проще. Я имею в виду, что большинство проектов, написанных с использованием JavaScript, ориентированы на интерфейс.

Лучше поместить ваш backend-код в каталог, такой как "сервер", на том же уровне папки, что и "css", "image"... Преимущество этого заключается в том, что когда вам нужен или не нужен бэкэнд, просто добавьте или удалите каталог "server", и это не повлияет на структуру проекта происхождения.

Вот так:

Введите описание изображения здесь

Ответ 5

Я изучал то же самое.

Мои первоначальные мысли были направлены на использование Express Generator и Angular Семя.

Тогда я нашел гораздо более приятное решение:

Один из самых популярных генераторов yoman предоставляет вам структуру для приложений Node.js и AngularJS.

Я верю в силу стандартизации, и новые люди, присоединяющиеся к проекту, оценят единую структуру.