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

Примечание для людей, впервые выбирающих Express

Если вы разрабатываете небольшое приложение, хотите иметь полный контроль, понимать, как все устроено, или если у вас есть требования, которые не соответствуют традиционным API, Express хорошо подходит для этой работы.

Однако, если вы планируете разработать простые конечные точки REST API или GraphQL и готовы изучить новую библиотеку, чтобы сразу получить большую помощь, вам следует как минимум потратить несколько часов, прежде чем выбирать Express и изучите альтернативы более высокого уровня для вашего варианта использования, такие как Feathers, Loopback, HAPI, NestJS, Sails.js или другие.

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

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

1 | Git, SemVer и хранение метаинформации

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

Вы можете легко инициализировать и разместить свой репозиторий Git на таких сервисах, как GitHub, GitLab, Bitbucket и других - вы обнаружите, что большинство сервисов различаются по своему пользовательскому интерфейсу, но не так сильно по своим функциям. Самый известный сервис - GitHub, и большинство пакетов, которые вы будете использовать в своем проекте Express, размещены там; так что чтобы с ним познакомиться, выбираем GitHub. (Он также недавно добавил Github Actions, который является их предложением CI, а хостинг недавно стал бесплатным даже для частных репозиториев).

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

Кроме того, даже для частных репозиториев в идеале следует добавить файл CHANGELOG.md. Здесь вы будете отслеживать, по крайней мере, каждый производственный выпуск или важную веху вашего приложения, чтобы в будущем было легче проверить, откуда могут возникнуть проблемы, а также лучше понять, что произошло. Вы можете найти лучшие методы работы с журналом изменений на https://keepachangelog.com/en/1.0.0/.

Вехи вашего кода должны быть версированы с использованием семантического управления версиями (https://semver.org), наиболее распространенной схемы управления версиями, которую вы также найдете в большинстве других пакетов.

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

Чтобы действительно иметь возможность откатывать или сравнивать версии, каждая версия должна стать тегом git (например, v2.5.3).

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

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

2 | Текущая среда: Docker

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

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

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

Использование контейнеров также поможет развернуть ваше приложение в производственной среде, если вы так захотите. Все основные облачные провайдеры в настоящее время предлагают планировщики (например, AWS Fargate или Kubernetes,…), которые берут ваш образ Docker, запускают его, масштабируют, если необходимо, и перезапускают, если что-то выходит; Это означает, что вам не нужно беспокоиться о менеджерах процессов, таких как PM2.

Dockerfile для репозитория Express может выглядеть так:

FROM node:12.18.3-alpine
USER node
COPY package.json .
RUN npm install
COPY . .
EXPOSE 80
CMD ["node", "server.js"]

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

Node.js предлагает использовать только версии с долгосрочной поддержкой (LTS) для производственных приложений, которые на момент написания были 12.18.3. Вы можете увидеть текущую версию LTS, посмотрев на nodejs.org.

Кроме того, убедитесь, что вы не запускаете что-либо в контейнерах Docker с правами root, чтобы уменьшить векторы атак.

Для более сложных, но меньших по размеру образов вы также можете использовать многослойные образы Docker и отдельные контейнеры сборки и приложения; и вы можете использовать функцию кэширования Docker, убедившись, что наименее измененные файлы сначала копируются в ваш образ (например, package.json).

3 | Диспетчер пакетов: NPM

Когда дело доходит до разработки на JavaScript, существует два основных менеджера пакетов: Yarn и NPM.

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

Основные отличия для большинства случаев использования заключаются в том, что в то время как Yarn 2 фиксирует уменьшенную версию ваших зависимостей в вашем репозитории и предлагает встроенный пользовательский интерфейс CLI для проверки и обновления устаревших пакетов, NPM не делает это прямо из коробки.

Однако для простоты мы рекомендуем просто использовать то, что поставляется с каждой установкой Node.js, и придерживаться NPM, и переключаться на Yarn только в том случае, если у вас действительно есть причина для этого.

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

4 | Visual Studio Code в качестве IDE

Если вы разрабатываете на JavaScript, скорее всего, вы уже используете Visual Studio Code.

VS Code - это бесплатная IDE от Microsoft, которая не имеет ничего общего с Visual Studio, но была создана с нуля с использованием веб-инструментов, таких как Electron с TypeScript, и в настоящее время доступна для большинства операционных систем.

Согласно опросам StackOverflow, это самая популярная IDE, и это не случайно: она быстрая, легко настраиваемая, поддерживает множество плагинов и очень легко расширяется вашими собственными плагинами.

Настройки VS Code могут храниться в репозитории и отдельно, а это значит, что это также удобно, если у вас есть разные проекты с разными языками, требованиями к плагинам или другими настройками. Вы даже можете сохранить, какие плагины VS Code нужны репозиторию, чтобы при переключении компьютеров вы могли легко настроить свою IDE.

5 | Стандарт форматирования кода: красивее

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

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

Он работает с большинством файлов (например, JavaScript, TypeScript, HTML; с React, YML,…) и имеет интеграцию для большинства IDE.

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

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

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

npx prettier --write .

Вы также можете проверить, соответствуют ли ваши файлы в src стандартам кодирования, запустив:

npx prettier -c "src/**/*.*"

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

6 | TypeScript

Если мы хотим, чтобы все было очень просто, мы могли бы пропустить это и придерживаться JavaScript; однако добавление TypeScript в ваш проект имеет много преимуществ, даже если вам не нравится синтаксис (пока) или у вас нет возможности его использовать (пока).

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

Вам следует подумать о добавлении TypeScript через Babel в свой проект. Таким образом, создание вашего проекта происходит быстрее, чем с использованием обычного TypeScript, и вы можете использовать Babel для дальнейших задач, таких как импорт файлов, которые не поддерживаются Node.js (например, схемы GraphQL).

7 | Линтинг, чтобы избежать распространенных ошибок: ESLint

Даже с TypeScript вы все равно должны убедиться, что добавляете линтер. Это гарантирует, что вы следуете разумным передовым практикам, таким как отказ от хранения неиспользуемых переменных, добавление super () в конструкторы классов и т. Д. Самый популярный линтер на данный момент - ESLint; полный список рекомендуемых значений по умолчанию см. на https://eslint.org/docs/rules/

В идеале постарайтесь не деактивировать рекомендуемые правила, если у вас нет уважительной причины. Особенно, если у вас есть устаревший код, часто лучше настроить ESLint так, чтобы он обрабатывал проблемы как «предупреждения», а не полностью отключал его; Таким образом, вы можете со временем улучшить свой устаревший код вместо того, чтобы игнорировать проблемы с качеством.

8 | Шутка для модульных тестов

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

Кроме того, вы можете установить jest-html-reporter, если вы используете CI и хотите получить подробный выходной артефакт.

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

9 | Ведение журнала с поддержкой облака: Pino

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

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

Традиционно для журналов HTTP используется формат журнала Apache, при этом приложения регистрируются без определенного формата; это затруднит вам программное использование ваших журналов в дальнейшем.

Чтобы подготовиться к агрегации журналов в будущем, чтобы иметь возможность использовать такие сервисы, как AWS CloudWatch Insights, и дать возможность структурировать вывод журнала, вы должны стремиться использовать JSON в качестве формата журнала по умолчанию.

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

Самым быстрым регистратором, который также ведет журнал с использованием JSON по умолчанию, является Pino, который также поставляется с пакетом pino-http для регистрации экспресс-запросов HTTP без необходимости большой настройки.

10 | HTTP-заголовок / вспомогательное ПО промежуточного слоя Express.js

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

Если вы не используете прокси-сервер, а ваше приложение и интерфейс (-ы) не используют один и тот же домен, вы столкнетесь с проблемами совместного использования ресурсов между источниками: современные браузеры не позволят вашим интерфейсам получить доступ к вашему Express-приложению, если последний не отправьте правильные заголовки CORS, чтобы браузер мог это сделать. Вы можете исправить и настроить это, установив пакет cors.

Есть также другие заголовки, которые вы можете захотеть установить, например заголовки кеша; Вы можете легко настроить эти HTTP-заголовки с помощью шлема.

Большинство приложений Express получают параметры из запросов, часто из тела запроса; чтобы иметь доступ к телу запроса, не разбирая его вручную, установите body-parser, который сделает это за вас.

Кстати, старайтесь, чтобы лимит тела body-parser был как можно ниже. Искаженные запросы огромного размера могут легко заблокировать ваш экземпляр Node.js, поэтому чем меньше размер ограничения, тем лучше.

Стоит упомянуть, но, надеюсь, не требуется для вашей настройки сжатие GZip. Если вы действительно не можете выполнить сжатие через прокси, балансировщик нагрузки или CDN, вы можете установить пакет сжатия для Express. Однако имейте в виду, что это может повлиять на производительность вашего сервера.

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

app.disable("x-powered-by");

Обратите внимание: если вы решите использовать шлем, вам не нужно делать это вручную, так как шлем автоматически сделает это за вас.

11 | Формат конечной точки API: GraphQL или OpenAPI

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

Сегодня API чаще всего описываются либо с использованием OpenAPI 3 (ранее известного как Swagger), если вы создаете REST API, либо с использованием конечных точек GraphQL.

Для маршрутов RESTful в Express уже есть все готово, хотя вы можете установить полезные помощники, такие как swagger-jsdoc. Это позволяет вам хранить определение API рядом с вашими маршрутами (чтобы вы могли проектировать и изменять как в одном месте, если есть изменения), а также иметь файл JSON, который вы можете просматривать с помощью проводника OpenAPI.

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

Для GraphQL вы можете использовать одно из промежуточных программ GraphQL, например express-graphql, и сгенерировать свои определения TypeScript из GraphQL с помощью @ graphql-codegen / cli; или вы можете установить более удобные альтернативы, такие как apollo-server-express, в зависимости от того, как вы разрабатываете своих клиентов.

12 | Запросить проверку с использованием стандартов

Если вы не используете подход «с включением батарей» для своих маршрутов, вам все равно следует стремиться использовать стандартный способ проверки данных запросов, попадающих в ваш API.

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

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

Даже пользовательские валидаторы могут быть легко определены; а недавно Ajv стал частью OpenJS Foundation.

Ajv можно легко использовать для ваших маршрутов с помощью промежуточного программного обеспечения express-json-validator-middleware.

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

13 | Отчеты об ошибках для лучшей видимости

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

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

Большинство из них - платные, такие как Bugsnag, Sentry или Raygun; однако некоторые из них предлагают бесплатные учетные записи для начинающих (например, Bugsnag) или свой исходный код для самостоятельного размещения (например, Sentry).

14 | Конечные точки проверки связи и работоспособности

Даже если вы не добавляете сложные проверки работоспособности в свое приложение, вы должны хотя бы предоставить маршрут / ping, который возвращает код состояния 200:

router.get("/ping", () => { return "OK"; });

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

Маршрут ping должен быть очень легким, так как он, вероятно, будет вызываться очень часто, но вы можете в конечном итоге добавить дополнительную (общедоступную) информацию, такую ​​как номер версии, или изменить статус на 500, если ваша база данных больше не работает, в зависимости от в вашем случае использования.

Кроме того, вы можете реализовать более сложный маршрут проверки работоспособности, такой как @ godaddy / terminus, квазистандарт, если ваша проверка работоспособности должна возвращать больше информации, чем просто код состояния 200.

15 | Непрерывная интеграция

Вам следует настроить конвейер непрерывной интеграции с помощью одного из многих поставщиков CI, например GitHub Actions, CircleCI, SemaphoreCI или AWS CodePipeline.

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

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

Ваш конвейер должен хотя бы запускать команду npm audit, чтобы вы не забыли проверить свои зависимости на предмет проблем безопасности; команда npx prettier -c 'src/**/*.*', чтобы случайно не зафиксировать неверно отформатированный код; а также запустите команду ESLint, чтобы отслеживать потенциальные проблемы с качеством.

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

Вы можете запустить несколько команд на одном этапе конвейера и поймать код ошибки следующим образом:

$ RESULT=0
$ ncu --errorLevel 2 || RESULT=$((RESULT + $?)) || true
$ npm audit || RESULT=$((RESULT + $?)) || true
$ license-checker --summary --failOn BSD || RESULT=$((RESULT + $?)) || true
$ if [ $RESULT -gt 0 ]; then exit 1; fi

CI также должен создать образ Docker и пометить изображение (например, используя тег репозитория / ветку + номер сборки), чтобы вы могли его развернуть; и, в зависимости от вашего опыта, вы также можете добавить проверки, чтобы узнать, не устарели ли ваши пакеты, добавили ли вы журнал изменений для новых тегов и многое другое.

16 | Автоматическое обновление зависимостей

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

Добавление в ваше приложение таких сервисов, как Greenkeeper (теперь часть Snyk) или Renovate, значительно помогает сократить объем рутинной работы, необходимой для поддержки вашего приложения. Они обновляют ровно одну зависимость за раз, в отдельной ветке, чтобы ваши тесты могли запускаться и чтобы вы могли объединять обновления одно за другим, уменьшая место для ошибок и упрощая откат в случае возникновения проблем. .

Даже если вы решите не добавлять подобную службу, вам следует подумать о добавлении шага CI, который выводит, какие пакеты вашей службы устарели, чтобы вы могли вручную обновить их. Просто установите npm-check-updates через NPM, чтобы хотя бы покрыть ваши зависимости JavaScript.

17 | Ограничение скорости для предотвращения проблем с производительностью

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

Это можно сделать с помощью одного из пакетов ограничения скорости, например express-rate-limit. Они гарантируют, что вы не сможете случайно или целенаправленно задействовать свой API с множеством запросов одновременно, что заблокирует цикл событий Node.js и приведет к недоступности вашего сервиса.

18 | Хостинг статических файлов вне Express

Node.js не предназначен для обработки статических файлов. Наличие доступа к ним многих пользователей приведет к возникновению узких мест из-за однопоточного процесса Node.

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

Корзина S3, к которой могут получить доступ ваши интерфейсы, легко настраивается; Вы можете получить бесплатную учетную запись AWS, добавить в нее ведро, включить статический хостинг веб-сайтов, и все готово. Со временем вы можете добавить CloudFront CDN для повышения производительности, ведения журналов, управления версиями и всего, что вам может понадобиться.

19 | Проверки безопасности

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

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

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

Вам также следует проверить свою инфраструктуру (например, SSL Labs может сказать вам, используете ли вы устаревшие протоколы SSL), а также зависимости вашего программного обеспечения - не только пакеты NPM через вышеупомянутый аудит npm, но и образы Docker с использованием таких инструментов, как Клэр или Снык.

20 | Хостинг с образами Docker

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

Чтобы максимально упростить себе жизнь, вы всегда должны стремиться к сервису без гражданства. Это означает сохранение всего состояния (данных вашей службы, информации о состоянии пользователя и т. Д.) Вне вашего приложения в базе данных или Redis, чтобы при завершении работы вашего приложения и повторном запуске не происходило потери данных.

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

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

Большинство облачных провайдеров также поставляются с такими инструментами, как AWS Secrets Manager для обработки секретов ваших приложений (таких как токены, пароль вашей базы данных и т. Д.), И их можно настроить с помощью кода (например, через Terraform), чтобы ваша инфраструктура также была воспроизводимой. , и версионирование, среди других преимуществ.

Если вы уже используете AWS для своего стека, вам следует изучить Fargate и CodePipelines. Fargate предлагает автоматический слив соединения при развертывании нового образа, чтобы вы могли избежать простоев; а CodePipelines может использовать расширенные функции развертывания синих / зеленых.