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

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

  src
      ├── app.js         входная точка приложения
      ├── /api           слой контроллеров: маршруты api
      ├── /config        конфигурационные установки, переменные окружения
      ├── /services      слой сервисов: бизнес-логика
      ├── /models        слой данных: модели БД
      ├── /scripts       NPM скрипты
      ├── /subscribers   асинхронные обработчики событый
      └── /test          тестовые кейсы

Здесь каталоги /API (слой контроллеров), /services и /models (слои доступа к данным) представляют три слоя, которые мы обсуждали в предыдущем разделе. Каталог /scripts может использоваться для хранения сценариев автоматизации рабочего процесса для построения (например, развертывания) конвейеров (pipelnes), а каталог /test используется для хранения тестовых кейсов. Назначение директорий /config и /subscriber мы рассмотрим позже в этой статье, когда будем говорить о конфигурационных файлах, переменных окружения и pub/sub-моделях.

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

Модель "издатель/подписчик" - это популярная модель обмена данными, в которой есть два взаимодействующих субъекта - издатели и подписчики. Издатели (отправители сообщений) посылают сообщения по определенным каналам без какого-либо знания о принимающих сущностях. Подписчики (получатели сообщений), с другой стороны, проявляют интерес к одному или нескольким из этих каналов без каких-либо знаний об издающих сущностях.

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

export default class UserService() {
      async function signup(user) {
        // 1. Create user record
        // 2. Generate auth key
        // 3. Send confirmation email
        // ...  
  }
}

Давайте посмотрим, как мы можем упростить и эффективно модулировать это с помощью модели pub/sub.

Модель pub/sub может быть настроена в Node.js с помощью API Events. В приведенном выше примере вы могли бы запрограммировать свой код так, чтобы при получении запроса сначала генерировалось событие 'signup'. В этом случае вашему сервисному модулю нужно сделать только один вызов для генерации соответствующего события, в отличие от нескольких вызовов функций в модели не pub/subsetting.

 var events = require('events');
      var eventEmitter = new events.EventEmitter();
      export default class UserService() {
        async function signup(user) {
          // emit 'signup' event
          eventEmitter.emit('signup', user.data)
        }
      }

Для обработки таких событий вы можете иметь несколько подписчиков, которые, по сути, являются слушателями событий, ожидающими определенных событий. Эти подписчики могут быть собраны в отдельные файлы в зависимости от их назначения и храниться в каталоге /subscribers, который мы рассматривали в разделе "Структура папок" выше. Теперь давайте создадим примеры файлов подписчиков для нашего примера выше:

// email.js
    // ...
    eventEmitter.on('signup', async ({ data }) => {  // event listener 
      // send email 
    })
    // ...

// auth.js
    // ...
    eventEmitter.on('signup', async ({ data }) => {	// event listener
      // generate auth key
    })
    // ...

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

Используйте линтеры кода (статические анализаторы кода) и руководства по стилю; добавляйте комментарии.

Основная цель линтинга и форматирования - улучшить качество кода и сделать его легко читаемым. Большинство рабочих процессов по настройке кода всегда содержат линтер и форматер кода. Линтер ищет и предупреждает о синтаксически (и даже семантически) ошибочном коде, в то время как форматер кода (как следует из названия) работает над больше над стилистическими аспектами вашего кода, чтобы обеспечить набор рекомендаций по форматированию и стилизации, согласованных во всем проекте. Одними из самых популярных линтеров для Javascript являются ESLint, JSLint и JSHint. Для форматирования кода вы можете использовать Prettier. Хорошо то, что большинство IDE/редакторов кода, таких как Visual Studio Code (VSCode), Atom и т.д., понимают важность написания качественного кода и предоставляют плагины для линтинга и форматирования, которые очень интуитивно понятны и просты в настройке.

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

Здесь следует отметить, что мы также должны быть разумны в своих комментариях, т.е. не комментировать слишком много и не комментировать слишком мало. Беспокоитесь о том, как найти баланс? Говоря словами Майкла Гэри Скотта, "Ты научишься, детка. Ты научишься!".

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

Используйте промисы, синтаксис async/await. Javascript широко известен своими функциями обратного вызова (функции, которые могут быть переданы в качестве аргумента другим функциям). Они также позволяют определять асинхронное поведение в Javascript. Проблема с обратными вызовами заключается в том, что по мере увеличения количества цепочек операций ваш код становится все более громоздким, что приводит к тому, что печально известно как "ад обратных вызовов". Чтобы решить эту проблему, в ES 6 (ECMASCRIPT 2015) появился API Promises, который значительно упростил написание асинхронного кода в Javascript. В дополнение к этому в ES 8 (2017) был введен синтаксис async/await, чтобы еще больше упростить ситуацию и сделать API еще более интуитивным и естественным.

Поэтому рекомендуется отказаться от громоздких функций обратного вызова в пользу синтаксиса async/await и promises в вашем приложении Node.js. Это позволяет сделать код чище, читабельнее, легче обрабатывать ошибки и тестировать; все это при сохранении четкого потока управления и более последовательного функционального программирования.

Чтобы дать вам представление о том, насколько проще может быть ваша жизнь с async/await, вот сравнение обоих способов написания асинхронного кода.

Пример кода с callback функциями

<script>
    function get_data() {
        $.get('https://url.com/one', () => {
            $.get('https://url.com/two', () => {
                $.get('https://url.com/three', (res) => {
                    console.log(res)
                })
            })
        })
    }
</script>

Пример кода с async/await

<script>
    async function get_data() { // async function
        await $.get('https://url.com/one')
        await $.get('https://url.com/two')
        let res = await $.get('https://url.com/three')
        console.log(res)
    }
</script>

По мере расширения вашего приложения вы заметите, что некоторые глобальные параметры конфигурации и настройки должны быть доступны для всех модулей. Хорошей практикой всегда является хранение этих параметров вместе в отдельном файле в папке config в вашем проекте. Мы рассматривали эту папку ранее в разделе "Структура папок" этой статьи. Эта папка может содержать все различные параметры конфигурации, сгруппированные в файлы в зависимости от их использования.

  /config
        ├── index.js
        ├── module1.js
        └── module2.js

Эти параметры конфигурации могут содержать как обычные, базовые настройки, так и защищенные ключи API, URL подключения к базе данных и т.д. Последние должны храниться в файлах .env как переменные окружения. Вот как файл .env хранит данные в виде пар ключ-значение:

DB_HOST=localhost
DB_USER=root
DB_PASS=my_password_123

Эти .env файлы являются секретными файлами, которые не подлежат отслеживанию и версионированию (Git) и поэтому не фиксируются и не публикуются (за исключением первого раза с пустыми значениями).

Доступ к этим переменным окружения можно получить в коде с помощью пакета dotenv от npm, как показано ниже.

// app.js
require('dotenv').config()

console.log(process.env.DB_HOST) 
console.log(process.env.DB_USER)

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

// config/database.js

      require('dotenv').config()

      export default {
        host: process.env.DB_HOST,		
        user: process.env.DB_USER,
        pass: process.env.DB_PASS,
      }

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

Юнит-тесты составляют основу большинства систем тестирования. Здесь отдельные блоки/компоненты тестируются в изоляции от остального кода для проверки их корректности. Это позволяет проверить ваш код на (логически) более низком уровне, чтобы убедиться, что каждый из внутренних компонентов работает точно, как ожидалось. Ниже приведен пример очень базового модульного теста (unit test)

// example.test.js

const assert = require('assert');

describe('Basic addition test', () => {
 it('should add up to 3', () => {
        assert.equal(2 + 1, 3);
    });
 
it('should equal 8', () => {
        assert.equal(4 * 2, 8);
    });
});

Эти тестовые примеры проверяют, возвращают ли компоненты вашего кода ожидаемые результаты или нет. Для разработки таких наборов тестов разработчикам Node.js предлагается множество фреймворков тестирования. Одними из самых популярных являются Mocha, Jest и Jasmine.

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

Javascript предоставляет множество функций для вывода и логирования информации. Для записи общей информации в журнал и отладки можно использовать - console.log(), console.info(), сonsole.debug() Для логирования ошибок и предупреждений - console.error(), console.warn() Он также позволяет передавать сообщения журнала либо на консоль, либо в файловый поток (с помощью оператора ' > '). Однако, если вы ищете больше функциональности и удобства для настройки логирования, вы можете рассмотреть возможность использования сторонних библиотек логирования в своем коде. Одними из наиболее распространенных библиотек логирования для Node.js являются Winston, Bunyan и Morgan.

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

Но вместо того, чтобы позволять Node.js выбрасывать исключения, прерывать выполнение кода и даже иногда выходить из строя, мы бы предпочли взять на себя управление потоком управления нашего приложения, обрабатывая эти условия ошибок. Именно этого мы можем добиться с помощью обработки исключений с использованием блоков try/catch. Предоставляя разработчикам возможность программно управлять такими исключениями, мы сохраняем стабильность, облегчаем отладку, а также предотвращаем негативный опыт конечного пользователя. Ниже приведен базовый пример блока try/catch в Node.js.

 try {
          if (xyzHappens) {
            throw "my error message ⚠️"; // 🛫				
          }
        }

        catch (e) {
          console.log(e); // 🛬
        }

        finally {
          console.log("Finally executed! 🏁");
        }

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

Такие фреймворки, как Express.js, позволяют невероятно просто настроить Gzip-сжатие с помощью промежуточного ПО сжатия. Использование Gzip-сжатия также является советом номер один, который документация Express.js рекомендует для повышения производительности приложений. Взгляните на то, как выглядит код для этого:

  var compression = require('compression')
  var express = require('express')
  var app = express()
  app.use(compression())	

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

В то время как вы работаете над оптимизацией производительности на стороне сервера, важно также следить за своим внешним кодом - быть в курсе размеров обслуживаемых веб-страниц. Поэтому перед обслуживанием необходимо минифицировать HTML, CSS, Javascript с помощью таких инструментов, как HTMLMinifier, CSSNano и UglifyJS. Эти минификаторы удаляют ненужные пробелы и комментарии из ваших файлов, а также выполняют некоторые тривиальные оптимизации компилятора, что в целом приводит к уменьшению размера файла.

Поэтому использование Gzip-сжатия вместе с минифицированным кодом фронтенда - это верный путь!

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

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

Вот модуль в нашем коде, который раскрывает две функции для работы с произвольным классом Emoji. Он также использует модуль yellow-emojis, который, как можно предположить, работает с банком данных желтых эмодзи.

    const Emoji = require('./Emoji');
        const YellowEmojis = require('./yellow-emojis');

        async function getAllEmojis() {
          return YellowEmojis.getAll(); // 🌕 🌟 💛 🎗 🌼
        }

        async function addEmoji(emojiData) {
          const emoji = new Emoji(emojiData);

          return YellowEmojis.addEmoji(emoji);
        }

        module.exports = {
          getAllEmojis,
          addEmoji
        }	

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

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

 const Emoji = require('./Emoji');

            function EmojisService(emojiColor) {

                async function getAllEmojis() {
                    return emojiColor.getAll();					
                }

                async function addEmoji(emojiData) {
                    const emoji = new Emoji(emojiData);

                    return emojiColor.addEmoji(emoji);
                }

                return {
                    getAllEmojis,
                    addEmoji
                };		

            }

            module.exports = EmojisService

Здесь мы создаем новую функцию (EmojisService) для нашего сервиса, которая принимает нашу зависимость (emojiColor) в качестве параметра вместо того, чтобы зацикливаться на работе только с одним типом цвета (желтым). Это то, что мы подразумеваем под инъекцией зависимостей. Благодаря этому наш сервис представляет собой скорее общий интерфейс, который не только легко использовать повторно, но и легче тестировать. Это происходит потому, что в предыдущем случае нам пришлось бы создать заглушку yellow-emojis для тестирования модуля. Теперь же мы можем напрямую передать нашу зависимость emojiColor в тестовый пример.

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

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

• Nodemon (автоматически перезапускает приложение при обновлении файлов кода)
• Gulp, Grunt (автоматические программы для выполнения задач)
• Winston (фреймворк для ведения логов)
• Agenda (планирование заданий)
• Moment (работа с датой и временем)

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

"Всегда пишите код так, как будто парень, который будет поддерживать ваш код, будет жестоким психопатом, который знает, где вы живете". - Мартин Голдинг

• DRY (Don't Repeat Yourself): переиспользуйте код
• Принцип единственной ответственности (SRP)
• KISS (keep it simple and straightforward) провозглашает, что простота кода – превыше всего
• Разделение ответственности (Separation of Concerns)
• YAGNI (You ain't gonna need it) - не писать лишнего кода
• Избегайте преждевременной оптимизации
• Принципы программирования S.O.L.I.D
• Инъекция зависимостей (Dependency injection)

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

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

В этом статье мы сначала рассмотрели внутренние аспекты архитектуры Node.js - мы узнали о его однопоточной архитектуре и механизме циклов событий для выполнения асинхронного кода. Затем мы перешли к пониманию различных аспектов того, что требуется для создания надежного, устойчивого и масштабируемого приложения Node.js. Мы рассмотрели 12 лучших практик, которые охватывают все: от логической структуры проекта до обзора логирования, тестирования, форматирования, линтинга, до тонкостей написания асинхронного кода и многого другого.

Теперь, когда вы знаете все о создании надежных, пуленепробиваемых приложений Node.js, идите вперед и внедрите все, что вы узнали сегодня, в свои существующие проекты или создайте их с нуля и поделитесь ими с миром. Удачи!