Я работал над несколькими серверными технологиями, начиная с PHP, затем перешел на RoR, прежде чем взялся за NodeJS. Мне нравится, как NodeJS упрощает разработку серверной части для разработчиков интерфейса; и не только это, экосистема NPM помогает разработчикам с легкостью приступить к работе со сложными проектами без необходимости заново изобретать велосипед путем разработки основных пакетов.

За эти годы я пробовал и тестировал различные структуры папок для своих проектов (признаюсь: я никогда не ссылался на какую-либо структуру папок в Интернете, поскольку хотел разработать что-то свое, с чем мне было бы удобно работать, а не быть предвзятым). заранее — как иронично, когда я пишу этот учебник 🙂), и я, наконец, достиг стадии, когда я чувствую себя достаточно уверенно, чтобы поделиться чем-то, что работает для большинства моих проектов NodeJS.

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

  1. Веб-сайт с целевой страницей
  2. Базовая аутентификация
  3. Панель инструментов
  4. Вы используете Express как фреймворк
  5. Создавайте инструменты для внешнего интерфейса, такие как Gulp, Webpack.
  6. Применимо, если вы используете фреймворки/библиотеки Frontend, такие как React, Angular, Vue.js и т. д.
  7. Применимо, если вы хотите создать приложение только для API.

Это довольно стандартный сценарий для любого приложения.

И последнее, но не менее важное: структура более или менее представляет собой монорепозиторий. Вы можете взять некоторые хорошие части и применить их к своим приложениям, если ваши приложения Node предназначены для использования только в качестве API или веб-сайта.

Структура папки проекта NodeJS

Структура папок, которой я обычно следую, во многом вдохновлена ​​RoR, поскольку я работал с Ruby и RoR до перехода на NodeJS.

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

/app
├── config/
│   ├── db.conf.js
│   ├── app.conf.js
│   ├── app.keys.js
│   ├── db.keys.js
│   ├── init.js
├── database/
│   ├── Redis.database.js
│   ├── Mongo.database.js
│   ├── init.js
├── routes/
│   ├── App.routes.js
│   ├── Auth.routes.js
│   ├── Dashboard.routes.js
├── utils/
│   ├── Logger.util.js
├── middleware/
│   ├── App.middleware.js
│   ├── ErrorHandler.middleware.js
│   ├── init.js
├── models/
│   ├── User.model.js
├── controllers/
│   ├── App.controller.js
│   ├── User.controller.js
├── helpers/
│   ├── App.helper.js
├── views/
│   ├── layouts/
│   ├── partials/
│   ├── support/
│   │   ├── index.ejs
│   ├── documentation/
│   │   ├── index.ejs
│   ├── index.ejs
│   ├── about.ejs
│   ├── contact.ejs
/public
├── dist/
├── images/
│   ├── dashboard/
│   ├── auth/
│   ├── documentation/      
├── sitemap.xml
/samples
├── .env.sample
├── db.conf.sample
├── app.conf.sample
├── app.keys.sample
/src
├── javascript/
├── css/
/node_modules
/server.js
/package.json
/.env

Краткое описание структуры проекта

Конфигурация и пример

Конфигурацию можно разделить на три основные категории:

  1. Конфигурация системы
  2. Конфигурация приложения
  3. Ключи приложений

Сохраните переменные конфигурации в .env (dotenv), которые необходимы для настройки вашего приложения, таких как порт приложения, среда (производство, подготовка и т. д.). Конфигурация .env будет доступна в вашем приложении, поскольку они устанавливаются глобально как переменные ENV.

Затем вы можете создать несколько файлов конфигурации, относящихся к приложению, например:

  • Подключение к базе данных: специфические для базы данных конфигурации, такие как хост, порт и имя.
  • Конфигурация приложения: допустимый размер полезной нагрузки запроса, занесение IP-адресов или регионов в черный список и т. д.
  • Конфигурация аутентификации: URL-адреса обратного вызова OAuth и т. д.

И последнее, но не менее важное: вы можете создать несколько файлов и хранить соответствующие ключи, такие как клиентские и секретные ключи OAuth, ключи базы данных, ключи Mailer и т. д.

Важно! Не передавайте ни один из этих файлов конфигурации в Git. Скопируйте структуру конфигурации с фиктивными значениями и зафиксируйте в git, используя образцы файлов в папке /sample.

База данных

Здесь вы можете создавать подключения к своим базам данных, таким как Redis, MySQL, MongoDB и т. д.

Затем вы можете запросить необходимую конфигурацию и ключи, чтобы инициировать соединение здесь. Это также облегчит вам управление всем, что связано с вашим подключением к базе данных, в одном файле, например, добавление прослушивателей вокруг успешных подключений, ошибок и отключений и т. д.

Позже эти соединители можно было загружать в файлы инициализации по мере необходимости.

Маршруты

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

  • Маршруты сайта
  • API-маршруты
  • Маршруты аутентификации
  • Маршруты документации

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

const express = require("express");
...
const websiteRoutes = require("@routes/Website.routes");
const apiRoutes = require("@routes/Api.routes");
...
app.use("/", websiteRoutes);
app.use("/api", apiRoutes);

Как видите, перемещение маршрутов в отдельные файлы также упрощает использование этих маршрутов вашим приложением.

Утилиты

Ваше приложение может иметь несколько служебных функций, таких как регистрация важной информации, или что-то статичное и не имеющее отношения к другим классам/файлам, в отличие от помощников (определенных позже в этом посте), которые могут помочь другим классам или модулям в вашем приложении.

ПО промежуточного слоя

Ваше приложение будет иметь несколько функций промежуточного программного обеспечения, которые можно разделить и инициировать в одном файле. Эти помощники могут варьироваться от критически важного промежуточного программного обеспечения, такого как анализатор тела, глобальные обработчики ошибок, промежуточное программное обеспечение аутентификации, включения CORS, присоединения пользовательских заголовков или настройки механизма просмотра в ExpressJS.

Модели

Каждая коллекция (если MongoDB) или таблица (если MySQL) будет иметь отдельный файл модели. Например: коллекция пользователей будет иметь свой собственный файл User.model.js, который может быть расширен для определения структуры схемы для коллекции, установки значений по умолчанию в БД или проверки ввода пользователя перед сохранением значений в базе данных.

Контроллеры

Контроллеры будут нести ответственность за обработку всех входящих запросов к вашему приложению, которые либо будут отображать страницу в ответ, могут отправлять полезную нагрузку JSON или будут обрабатывать другие важные действия, связанные с API, такие как POST, PUT, DELETE и т. д.

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

Помощники

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

Взгляды

Вам может не понадобиться эта папка, если вы разрабатываете приложение только для API или используете отдельную библиотеку SSR, например Next или Nuxt. Это может быть полезно при использовании Express View Engine, такого как Pug или EJS.

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

Общественный

Как следует из названия, все, что находится в этой папке, будет общедоступно для пользователей вашего сайта. CSS, JavaScript и изображения будут частью этой папки.

Ваше приложение может использовать такие инструменты, как Webpack и Gulp, которые компилируют (минимизируют, предварительно обрабатывают) ваши файлы (S)CSS и JS и перемещают их в общедоступную папку, на которую позже будут ссылаться веб-страницы.

Вы также можете создать и вывести свое приложение React (или аналогичную библиотеку/фреймворк) в папке dist/.

Источник

Поскольку папка App отвечает за обработку всей внутренней логики, папка Src будет содержать ваши файлы JavaScript и CSS, если вы используете SASS, ES 6/Next, которые необходимо транспилировать, скомпилировать, минимизировать и углифифицировать, прежде чем их можно будет передать на сервер. конечные пользователи.

Папка Src будет содержать такие каталоги, как CSS и JavaScript, которые можно настроить в соответствии с вашими потребностями.

Простое объяснение для файлов init.js, прежде чем я закрою эту статью, файлы init.js потребуют остальные файлы и экспортируют их в другие файлы вашего приложения, так что вам не нужно каждый раз запрашивать несколько файлов, если вы хотите использовать их все.

Заключение

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

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

Полезные ресурсы

Наконец, я хотел бы поделиться некоторыми пакетами, которые я использую для управления конфигурацией, упрощая процесс запроса файлов на различных уровнях вложенности, а также некоторыми пакетами Linting для значительной стандартизации вашего кода.

  1. ДотЭНВ
  2. модуль-псевдоним
  3. Похорошее
  4. ЭСЛинт