Архитектура внешнего интерфейса (JavaScript, TypeScript)

вступление

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

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

Обзор

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

Есть два основных направления для веб-приложений:

  • Веб-сайт с общедоступным содержанием
  • Веб/собственное приложение

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

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

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

Список предлагаемых технологий

  • Состояние — Редукс
  • Реагировать, реагировать-маршрутизатор
  • Пользовательский интерфейс — MUI или Bootstrap
  • Linting — Husky, ESLint, красивее
  • Тестирование — Шутка
  • CI/CD — Gitlab

Структура папок

Следующая структура папок может использоваться как для средних, так и для небольших приложений:

  • Компоненты — все компоненты. Каждый может иметь вход/выход
  • Контейнеры — компоненты, определяющие определенный макет
  • Страницы — страница будет использовать один из контейнеров и содержать компоненты.
  • Маршруты — содержит объявления маршрутов.
  • Конфигурация — константы
  • Услуги
  • Специальные файлы API
  • Авторизация
  • Общие службы — такие как трассировки/журналы, системные уведомления и т. д.
  • Магазин — файлы хранилища Redux. Такие как редукторы
  • Корневая папка будет содержать package.json, ESLint и т. д.
  • .ENV — константы, специфичные для среды

Для крупных проектов с несколькими приложениями рекомендуется прочитать статью Семантическая группировка папок с помощью Nx.

Основные основные функции

  • Регистрация, отслеживание
  • Авторизация: Отправить учетные данные -> получить токен. Все манипуляции с конфиденциальными данными должны проходить через Заголовок авторизации.
  • Централизованные системные уведомления
  • Общие всплывающие окна: всплывающее окно подтверждения
  • Статистика активности пользователя: серверная часть должна сохранять каждое действие/запрос пользователя для дальнейшего анализа, в противном случае можно использовать внешний сервис.

Модульность кода

Модульность достигается за счет разделения функций на компоненты. У каждого из них должна быть одна обязанность. Компоненты будут иметь данные ввода/вывода.

Управление состоянием

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

Существует два типа компонентов:

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

Производительность

  • Вызовы APi В кешировании браузера — редко обновляемые данные должны храниться в кеше браузера. Это достигается установкой кэширования заголовков для HTTP ответов.
  • Кэширование файлов приложения — изображения, шрифты, пакеты js должны кэшироваться в браузере.
  • Уменьшите повторный рендеринг компонентов, ограничив поток состояний.
  • Отложенная загрузка — приложение будет загружать только необходимые файлы пакетов. Достигается методами расщепления кода.

Качество кода

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

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

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

Читаемость кода может быть достигнута с помощью плагинов CodeMetrics, SonarLint, SonarQubevscodeили аналогичных. Инструмент проанализирует когнитивную сложность кода и предложит улучшения. В общем, функции/методы должны быть короткими и избегать многоуровневых вложенных циклов или условий.

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

Модульное тестирование

Каждый компонент должен быть покрыт тестом не менее чем на 70%. Jest — одна из хорошо поддерживаемых библиотек для этой цели.

Версии

Git — наиболее предпочтительный вариант для контроля версий.

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

Развертывание

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

Приложение должно иметь несколько сред развертывания, таких как Stage, Dev, Production. На сцене будет последняя мастер-версия. После того, как он пройдет тесты QA, его можно будет перевести в производственный режим.

Специальные возможности

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

Инструмент разработчика Chrome Lighthouse можно использовать для анализа уровня доступности, обеспечиваемого приложением.

UI

  • Используйте одну из хорошо поддерживаемых сред пользовательского интерфейса, например Mui или Bootstrap.
  • Поддержка нескольких тем. Как минимум два: светлый и темный режимы должны быть
  • Отзывчивый — мобильный подход. Гарантирует, что у приложения не будет недостатка в функциональности на всех устройствах.

Безопасность

При создании Frontend-приложения следует учитывать как минимум следующие моменты.

Внешний интерфейс:

  • Пользовательские данные санитария. React и Angular изначально поддерживают санитарию.
  • Аутентифицировать безопасное хранилище токенов в файлах cookie только HttpOnly. Обратитесь к пояснению на странице OWASP.

Серверная часть:

  • Ограничьтеколичество HTTP-запросов на пользователя, чтобы избежать DDOS-атак.
  • Ограничьте количество попыток входа
  • Правила OWASP

Миграция

Разделение стилей — при создании пользовательских стилей отделяйте набор файлов SCSS, содержащих все общие стили. В случае миграции в другую библиотеку SPA стили можно использовать повторно.

Мигрировать большую кодовую базу всегда сложно. Например, приложение Angular мигрирует на React. В большинстве случаев каждая SPA-библиотека имеет свою архитектуру, и скопировать компоненты будет невозможно.

Однако такие инструменты, как NX или Module Federation, могут управлять микроинтерфейсами и обеспечивать постепенный переход от одной библиотеки SPA к другой.

Заключение

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

Давайте подытожим то, что мы узнали:

  • Определите тип проекта, если он основан на контенте или приложении
  • Производительность
  • Модульность
  • Государственное управление
  • Качество кода: TypeScript, линтинг
  • Стабильность: Модульные тесты
  • Версии: Git
  • Развертывание: GitLab
  • Пользовательский интерфейс: MUI, Bootstrap
  • Доступность
  • Безопасность
  • Миграция

Больше контента на plainenglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Получите эксклюзивный доступ к возможностям написания и советам в нашем сообществе Discord.