Примечание: это часть серии из 12 частей, так что следите за новостями!
Далее ››

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

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

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

I. Кодовая база

Одна кодовая база отслеживается в системе контроля версий, многие развертывают

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

  • Используйте контроль версий (Git и т. Д.), Сохраняя код в репозитории или _repo_. Кодовая база - это репо (или набор репозиториев с одним и тем же корневым коммитом).
  • Одна кодовая база для каждого приложения. Между кодовыми базами и приложениями всегда существует взаимно однозначная связь.
  • Сами приложения соответствуют 12 фактору.
  • Несколько приложений, использующих один и тот же код, являются нарушением 12-го фактора.
  • Каждая кодовая база развертывается (развертывание является запущенным экземпляром приложения) несколько раз, вероятно, в рабочем месте, в одном или нескольких промежуточных местоположениях и каждой локальной копии разработчика.
  • В каждом развертывании могут быть активны разные версии, при этом локальная постановка, содержащая коммиты, не работает, а постановка, содержащая коммиты, - нет.

Есть несколько вещей, которые я считаю преимуществами этого фактора:

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

Как это применимо к JavaScript?

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

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

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

Как только вы это сделаете, может возникнуть соблазн просто написать несколько правил проверки в обоих приложениях и надеяться, что они совпадут. Тесты ни для одного из приложений не пройдут неудачно, но всякий раз, когда меняется правило, разработчикам приходится вручную обновлять правила в обоих приложениях, и я, конечно, не стал бы доверять себе, чтобы каждый раз прибегать к этому. В JavaScript также есть много неинтуитивных частей, связанных с приведением типов, датами и неизвестно чем еще, что делает правила проверки и изменения этих правил нетривиальными. К счастью, вы, вероятно, уже используете диспетчер пакетов JavaScript, npm, для установки чего-то вроде Express или React, поэтому вы можете создать и опубликовать свой собственный пакет npm и просто использовать его в обоих приложениях. Затем все, что вам нужно сделать, это убедиться, что номера версий в обоих приложениях совпадают, и вуаля они совместимы. Если вам не нужны специальные правила, вы можете использовать существующие отличные инструменты, такие как Валидатор, для достижения того же результата.

Существует множество различных способов развертывания приложений JavaScript, от Heroku до AWS, но подробности этого выходят за рамки данной статьи. Что более важно, так это то, как вы тестируете как до, так и после развертывания, чтобы убедиться в этом развертывании. Скорее всего, вы захотите использовать инструмент модульного тестирования, такой как Jest, инструмент тестирования пользовательского интерфейса, такой как WebDriver, и некоторую их комбинацию для запуска тестов интеграции, компонентов и E2E.

У вас есть примеры?

Конечно! Если вы посмотрите на аккаунт Агентства по пищевым стандартам на GitHub, вы увидите несколько репозиториев, ссылающихся на register-a-food-business. Это различные приложения и библиотеки, составляющие услугу Зарегистрировать пищевой бизнес. Вы заметите, что существует разделение между репозиториями внешнего интерфейса и службы, которые представляют собой внешнее приложение и службу, которая помещает данные в базу данных.

Также существует репо register-a-food-business-validation, которое содержит общие правила проверки для приложений.

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

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

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