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

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

Подготовка

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

необходимые

  • Команда согласовала набор технологий
  • Лицензии, стоимость инфраструктуры и т. д. покрыты
  • Определена операционная модель (включая SLA)
  • Проработан бизнес-план

рекомендуемые

  • Доступен список поддерживаемых браузеров

Пример

Список поддерживаемых браузеров можно указать так же просто, как набор правил Список браузеров, например, последние 2 версии, IE 10. Самое замечательное то, что этот набор правил можно просто добавить в package.json нашего веб-приложения, и он будет выбран автоматически.

Дополнение может быть таким простым, как:

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

Инфраструктура

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

необходимые

  • Процесс сборки полностью автоматизирован
  • Включены отчеты об ошибках (например, LogRocket)
  • Резервная копия данных находится на месте и надежно хранится

рекомендуемые

  • Доступны скрипты Terraform (или аналогичные)?
  • Масштабируемость определена
  • Статические ресурсы размещаются на CDN

Пример

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

В качестве примера смотрим на LogRocket:

Это почти все! Остальное — это (индивидуальное) сочетание использования официальных инструментов для доступа к собранным данным и API для интеграции в наши собственные инструменты.

Техническая база

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

необходимые

  • Доступны сквозные тесты для всех поддерживаемых браузеров
  • Выпущенный JS упакован и минимизирован
  • Выпущенный CSS упакован и минимизирован
  • Создаваемый CSS имеет автоматический префикс

рекомендуемые

  • Структура пакета поощряет повторное использование кеша
  • Выпущенный HTML минимизируется
  • Все испускаемые ресурсы можно кэшировать (например, использовать хешированное имя)
  • Выпущенный HTML минимизируется
  • Все испускаемые ресурсы можно кэшировать (например, использовать хешированное имя)

Пример

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

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

Использовать его так же просто, как запустить

Выходной каталог по умолчанию обычно является желаемым ("dist").

Доступность и мобильность

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

необходимые

  • Существует представление для мобильных устройств
  • Ненужные ресурсы не скачиваются

рекомендуемые

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

Пример

Если мы запустим, например, Google Lighthouse в SPA без какого-либо элемента noscript, мы получим логическое предупреждение. Дать пользователям понять, что причина того, что они ничего не видят (или не выходят за рамки какого-то счетчика загрузки), может быть связана с отсутствием поддержки JavaScript, имеет решающее значение для прогрессивных веб-приложений.

К счастью, исправить это так же просто, как добавить простое сообщение noscript к body, например:

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

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

необходимые

  • Никакие секреты, ключи или токены не передаются клиенту
  • HTTPS требуется и активен для каждого вызова.

рекомендуемые

  • Используется заголовок HSTS.
  • Поля загрузки защищены службой антивирусного сканирования
  • Разместите, например, rel="noopener"на внешних ссылках

Пример

Размещение отношения noopener (или даже nofollow) в тегах привязки является прямым.

Конфиденциальность

Потенциально, мой опыт немца (то есть европейца) делает меня особенно чувствительным к этой теме, однако в GDPR есть нечто большее, чем просто раздражающие сообщения «мы используем файлы cookie». Понимание и оценка потребности пользователя в достаточной конфиденциальности и защите данных необходимы для создания доверительной среды. Имейте в виду, что довольно часто дьявол кроется не непосредственно в нашем коде, а в каком-то компоненте, который мы используем для удобства.

необходимые

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

рекомендуемые

  • Возможен детальный контроль над используемыми файлами cookie и сторонними интеграциями.

Пример

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

Представление

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

необходимые

  • Проведен тест скорости Lighthouse (в т.ч. разные скорости соединения)

рекомендуемые

  • Используйте HTTP/2 для всех ресурсов
  • Предварительно загружать вторичные ресурсы (через <link>)
  • Поместите скрипт как асинхронный внизу

Пример

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

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

Веб-аналитика

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

необходимые

  • Предоставляется осмысленный файл robots.txt.

рекомендуемые

  • Предоставляется код отслеживания производства и отслеживаются нужные события
  • Переходы между страницами (SPA) отслеживаются правильно
  • Метаданные (например, свойства пользователя) настроены правильно

Пример

Предоставление правильного robots.txt может быть таким же простым, как предоставление следующего текстового файла (подается с text/plain как content-type) в корневом каталоге:

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

Необычные дополнения

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

необходимые

(нет)

рекомендуемые

  • Учебники в приложении и полезные справочные сообщения
  • Горячие клавиши

Пример

Такие вещи, как QuestionMark.js, легко настроить, но они дают профессиональным пользователям еще более быстрые возможности ввода.

Вывод

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

Ссылки

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