Использование нескольких redux хранилищ в React приложении быть довольно сложным.

В приложении с React-Redux рекомендуется иметь только одно хранилище (один store). Но если по какой-то странной/особой причине вам нужно иметь более одного  store, вы столкнетесь с проблемами.

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

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

Чтобы справиться с этой проблемой нам необходимо выполнить некоторые приготовления

Для этого нам понадобится react-redux 7 или выше. Поскольку версии ниже не используют Context API React. Мы будем использовать контексты для доступа к нескольким хранилищам без повторного использования провайдеров.

Создайте контекст для каждого store. Вы также можете импортировать ReactReduxContext из react-redux и использовать его для каждого из stor-ов, который вы хотите использовать в нужный момент.

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

Нам также нужно создать пользовательские dispatch хуки и selector хуки. Если вы используете хуки по умолчанию (useSelector, useDispatch), он будет использовать хранилище с контекстом по умолчанию, если таковой имеется.

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

Если вы предпочитаете подключать store компонентом высшего порядка (HOC), вы можете сделать:

Это все. Если у вас будут вопросы, пожалуйста пишите комментарии. Спасибо.

За основу данной статьи, использована статья Handling multiple stores in a React-Redux application от автора Vikas Kumar

В современном мире "Фронтенда" необходимо писать не только клиентские приложения на JavaScript, но и серверную часть на NodeJS. Чаще всего такие сервера называют аббревиатурой BFF (Back For Frontend). Часто приходится использовать сервер для рендеринга HTML. Отлаживать такие приложения иногда становится довольно проблематично. Поэтому, я хочу поделиться своим методами.

Давайте же приступим.

Самое первое, что приходит в голову - это флаг --inspect при запуске программы на NodeJS (см. доку).

Создадим файл index.js со следующим содержимым:

Запустим командой node --inspect index.js

В консоли видим вывод:

Debugger listening on ws://127.0.0.1:9229/f7a0b5f7-edf1-4874-83d6-49b07c009f65
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.

Отлично! Интервал начал свой счет, а программа подключилась к дебаггеру Хрома. Если совсем просто, то при установке Google Chrome устанавливаются дополнительные модули которые слушают сообщения на специальных портах. Обычно это порты 9229 и 9222 (могут быть и другие). Получается, что запуск NodeJS программы начинает слать весь свой вывод на один из этих портов.

Теперь мы можем открыть Инспектор прямо в инструментах разработчика браузера Google Chrome. Если ваше приложение запущено с инспектором, то вы увидите иконку  NodeJS на панели devtools.

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

Пока все супер. Пока запущенный процесс один. Проблемы начинаются когда в разработке участвуют несколько процессов. Чаще всего это запуск веб сервера, webpackDevServer, собирается это все с помощью Webpckack (это тоже процессы node и не один). А запускаются все эти процессы одним родительским, скажем, react-create-app.

В таком случае запуск react-create-app с флагом привяжет инспектор только к родительскому процессу. Но как подключить инспектор к дочерним процессам? Этого тоже можно легко добиться.

Создадим второй файл child.js и обновим содержимое обоих файлов.

index.js

child.js

Таймеры мы запускаем чтобы процессы NodeJS не завершались. Мы используем модуль spawn для запуска дочернего процесса. Так же подписываемся на все события data. Подробнее про дочерние процессы можете почитать здесь.

Итак, смотрим что получилось:

В консоли мы видим логи из родительского сервиса, и логи из дочернего.

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

Можем поступить иначе. Добавьте следующую строчку в файл child.js и запустите родительский процесс, но теперь без флага --inspect.

Смотрим:

Мы видим как подключился инспектор, и подключился именно к дочернему процессу, как мы и хотели. В обычном терминале видим вывод родительского процесса, а в инспекторе вывод дочернего процесса.

Это случилось благодаря методу _debugProcess у глобального объекта process.

process - глобальная переменная на весь процесс nodeJS.

_debugProcess - метод позволяющий подключиться к инспектору на горячую.

process.pid - Уникальный идентификатор текущего процесса.

It' s awesome! Теперь можно в любом месте ваших программ вставить этот вызов и процесс nodeJS подключится к инспектору.  Совсем не нужно думать, что это за процесс, сервер или сборщик. Можно даже сделать snippet для быстрой вставки команды. Я так и сделал:

В предыдущем способе все хорошо, но есть одно НО. Он требует перезагрузки процесса. Т.е. если вы вставили snippet, вам придется выполнить рестарт процесса, например сделать рестарт create-react-app, что может быть довольно затратным по времени.

Бывают случаи, когда перезагружать процесс вообще не желательно, например когда пытаешься найти баг и нужно подключить инспектор действительно "на горячую". И такой способ тоже имеется. Данный способ подойдет владельцам операционных систем UNIX Like (Такие, как MacOS или дистрибутивы Linux).

Изучим пару важных вещей: Сигнал и программу kill.

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

На той же официальной доке про инспектор написано следующее: 

Node.js также начнет прослушивать отладочные сообщения, если получит сигнал SIGUSR1. (SIGUSR1 недоступен в Windows.) В Node.js 7 и более ранних версиях это активирует устаревший API-интерфейс отладчика. В Node.js 8 и более поздних версиях он активирует Inspector API.

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

Важно понимать, что хоть мы и пишем на JS используя NodeJS, но сама нода написана на С++.

Ок, что же нам нужно сделать? Для начала определим требования.

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

Первое, что нужно сделать, это найти нужный запущенный процесс. Сделать это можно с помощью следующей команды:

ps - программа ps выводит все запущенные процессы.

| - передача текстового вывода в другую программу.

grep - программа фильтр, отбросит все ненужные строчки.

node - слово которое должно присутствовать в строке, по сути это регулярное выражение.

У меня получилось так:

Нужный мне процесс 17860 ttys003 0:00.05 node child.js

Отлично, процесс найден, как же послать в него сигнал SIGUSR1? Для этого используется, программа kill. Обычно эта программа "убивает" процессы (на самом деле просто шлет сигналы об их завершении), но может использоваться иначе, для отсылки любых других сигналов в запущенные процессы.

Это все! Теперь достаточно просто послать нужный сигнал на нужный процесс:

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

Jest поставляется с функцией создания отчетов, которые помогают нам понять покрытие тестами. Этот отчет включает покрытие выражений (statements), покрытие функций и покрытие ветвлений (braches).

Это один из примеров отчета о тестовом покрытии, созданного для тестового приложения. В этом отчете говорится, что он имеет 84% покрытие выражений (statements), 100% ветвей и 100% функций и 84% покрытие строк в целом. Так же, возможно посмотреть отчет по каждому файлу в отдельности.

Так что же такое покрытие выражений, веток, функций, строк? Каждый параметр отвечает на свой собственный вопрос.

Function coverage (Покрытие функций) Была ли вызвана каждая функция (или подпрограмма) в программе?
Statement coverage (Покрытие выражений) Выполнено ли каждое выражение в программе?
Branch coverage (Покрытие ветвлений/веток) Выполнена ли каждая ветвь (также называемая DD-путем) каждой управляющей структуры (например, в операторах if и case)? Например, для заданного оператора if были ли выполнены как истинная, так и ложная ветви? Другими словами, было ли выполнено каждое решение в программе?
Line coverage (Покрытие строк) Была ли выполнена каждая исполняемая строка в исходном файле?

Для каждого случая указанный процент представляет собой выполненный код по сравнению с невыполненным кодом (executed code vs not-executed code), который равен дроби в процентном формате (например: 50% ветвей, 1/2).

Далее мы можем щелкнуть отдельный компонент или файл src и увидеть отчет о конкретном файле.

Например, index.js не охватывается ни одним оператором.

В файле отчета:

«E» означает «else path not taken» (путь Если не применен), что означает, что для помеченного оператора if/else был проверен путь if, но не else.

«I» означает «if path not taken» (путь Если не применен), что означает что блок if не был проверен.

Nx в левом столбце — это количество раз, когда эта строка была выполнена.

Невыполненные строки или фрагменты кода будут выделены красным цветом.

Отчет также предоставляет цветовые подсказки.

Pink: выражения не покрыты (statements not covered) и функции не покрыты (functions not covered)

Yellow: ветви не покрыты (branch is not covered).

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

Так же если вы направите курсор мыши на выделенные элементы, html отчет подскажет вам о чем идет речь.

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

Я задумал написать статью о безопасных способах передачи данных в Интернете. В первую очередь я задался вопросом "Как работает протокол SSH?". Исследования затянулись, я выяснил много нового и все оказалось совсем не так как представляют большинство. Но прежде чем изучать как работает протокол SSH, необходимо разобраться как работает алгоритм Диффи-Хелмана. Дело в том, что этот алгоритм используется и в протоколе SSH, и при настройке шифрования HTTPS, а так же в других протоколах передачи данных. Тема довольно обширная так, что я решил вынести это в отдельную статью и ссылаться на нее по необходимости. 

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

Алгоритм Диффи-Хелмана (Diffie–Hellman key exchange) - это криптографический протокол, который позволяет двум пользователям безопасно обмениваться секретными ключами через небезопасный канал связи.

Этот алгоритм (так же его называют протокол, метод) был разработан Уитфилдом Диффи и Мартином Хелманом в 1976 году. В то время они работали в лаборатории исследования компьютерных наук в Стэндфордском университете и занимались проблемой безопасного обмена ключами для шифрования данных.

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

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

Алгоритм Диффи-Хелмана (зачастую просто сокращают до аббревиатуры DH) стал первым протоколом, который позволял безопасно обмениваться ключами через небезопасный канал связи. Он стал основой для многих современных систем шифрования и используется во многих областях, включая интернет-банкинг, электронную почту и защиту данных в облаке.

Как же он работает? Давайте разбираться вместе.

Перед тем как разбирать сам алгоритм, давайте разберем термин Симметричное шифрование, он нам понадобится позднее.

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

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

1) Этап первый

Клиент и Сервер договариваются о двух секретных числах:

p = 29, g = 3

Числа генерируются случайным образом, каждый раз новые, при каждом новом соединении. Данные числа иногда называют "публичными ключами".

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

2) Этап второй

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

3) Этап третий

Клиент выполняет специальную операцию:

Число g, в нашем случае 3, возводит в число которое клиент выбрал случайным образом, в нашем случае это 5, и берется остаток от деления на число p, в нашем случае это 29. Получается число 11. Это число можно передавать по открытым каналам связи. Клиент передает это число на сервер.

4) Этап четвертый

Сервер выполнят такой же расчет, но только со своим секретным случайным числом. В нашем случае 3 в степени 8 и берем остаток от деления на 29, равно 7.
Сервер пересылает получившиеся число клиенту.

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

5) Этап пятый - Генерация симметричного ключа

Теперь клиент и сервер снова производят похожие операции.

Клиент выполняет ту же функцию, что и выше, но только с числом полученным от сервера, в нашем случае это 7.

7 в степени 5 и остаток от деления на 29, равно 16.

Сервер производит то же самое, но с числом полученным от клиента, у нас это было число 11.

11 в степени 8 и остаток от деления на 29, равно 16.

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

Как же получилось так, что клиент и сервер смогли вычислить одинаковое число? Все совсем не сложно. Дело в том, что и клиент и сервер выполняли одни и те же вычисления, но в разном порядке.

(3^5 mod 29)^8 mod 29 = (3^8 mod 29)^5 mod 29

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

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

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

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

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

p - большое простое число минимум 2024 бита.
g - небольшое целое число (первообразный корень по модулю p).

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

Секретные ключ клиента и сервера так же выбираются не обычной случайностью, но как именно мне выяснить не удалось. Вообще эта тема довольно сложная, оставим ее математикам.

Так же алгоритм обеспечивает Совершенную прямую секретность (Perfect forward secrecy). Если злоумышленник записал данные, которыми мы обменивались в течении соединения, а затем получил доступ к серверу, он не сможет их расшифровать. Почему? Просто, ни клиент, ни сервер не хранят симметричный ключ, он используется только в периоде соединения. Этот ключ не может быть восстановлен из переданных данных, поэтому злоумышленник не может узнать его, даже если он перехватит все сообщения, передаваемые по каналу связи. Таким образом, мы можем быть уверены в том, что в будущем никто не сможет расшифровать наши сообщения.

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

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

Алгоритм Диффи-Хеллмана применяется во многих криптографических протоколах и стандартах, включая:

1. TLS/SSL: Протоколы передачи данных, обеспечивающие защищенное соединение между клиентом и сервером.

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

3. IPSec: Протокол безопасности для защиты данных, передаваемых через сети, включая VPN-соединения.

В алгоритме Диффи-Хелмана существуют проблемы безопасности. Например, атака MITM (Man-in-the-Middle) может быть использована для перехвата и изменения передаваемых данных. Также возможна атака на основе подбора ключа, когда злоумышленник пытается угадать секретный ключ, используемый для шифрования данных. Для обеспечения безопасности протокола Диффи-Хелмана необходимо использовать надежные простые числа и другие меры защиты. Но все же данный алгоритм является одним из наиболее распространенных и широко используемых.

Алгоритм Диффи-Хелмана является одним из самых важных алгоритмов криптографии. Он позволяет двум сторонам безопасно обмениваться секретными ключами через небезопасный канал связи. Алгоритм Диффи-Хелмана используется во многих протоколах безопасности, таких как SSL/TLS, SSH и VPN. Важно отметить, что алгоритм Диффи-Хелмана не обеспечивает аутентификацию сторон, поэтому он должен использоваться в сочетании с другими методами аутентификации, такими как цифровые сертификаты.

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

Если вам понравилась статья, не стесняйтесь поделиться ее в соц. сетях. Спасибо.

Diffie–Hellman key exchange

Протокол Диффи — Хеллмана

Обьяснение алгоритма на примере смешивания цветов. 

Андрей Созыкин - Шифрование в TLS/SSL | Защищенные сетевые протоколы

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

В этой статье я отвечу на вопросы: Что такое переносы строк? Какими последовательностями символов они обозначаются, и наверное самый главный вопрос, почему с ними такая путаница?

Если совсем кратко, то при использовании любого текстового редактора, набирая в нем текст, вы делаете переносы строк. Чаще всего, эти переносы строк никак не отображаются в браузере. Для обычного пользователя, это просто перенос строки и все. Но ведь для машины любой текст это просто набор нулей и единиц. Как же тогда редактору понять где нужно сделать переносы строк, отображая очередной текст в текстовом редакторе? Правильно, нужно использовать специальную последовательность нулей и единиц, которые подскажут редактору, где нужно делать переносы. То есть нажимая клавишу Enter, вы не просто делаете перенос строки, а вставляете в ваш текст специальный символ переноса строки. Обычно в редакторах такие символы не отображаются, но их конечно же можно сделать видимыми (Чуть позже я покажу, как можно включить отображение скрытых символов в разных редакторах).

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

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

Итак, давайте разбираться.

Новая строка (часто называется (line ending), концом строки (end of line или EOL), следующей строкой (next line или NEL) или разрывом строки (next line)) — это специальный управляющий символ или последовательность управляющих символов в спецификациях кодировки символов, таких как ASCII, EBCDIC, Unicode и других. Много названий, но суть одна. Этот символ или последовательность символов, используется для обозначения конца строки текста и начала новой.

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

LF (0A в HEX) - расшифровывается как Line Feed или Подача Линии (нет, не кормящая линия)
CR (0D в HEX)  - расшифровывается как Caret Return или возврат каретки.

Операционные системы Linux, MacOS для обозначения переноса строк используют последовательность LF.
OS Windows использует две последовательности одна за другой - CR LF.

Почему так? Будем разбираться дальше. Но перед тем как мы продолжим, обязательно посмотрите видео ниже.

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

Итого:
LF (line feed) - это виртуальная подача бумаги на одну линию.
CR (caret return) - это виртуальный сдвиг каретки, что бы мы могли начать печатать с новой строки.

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

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

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

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

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

Следующая история из статьи на вики.

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

Позже, в эпоху современных телетайпов, были разработаны стандартизированные управляющие коды набора символов, помогающие форматировать текст с пробелами. Кодировка ASCII была разработана одновременно Международной организацией по стандартизации (ISO) и Американской ассоциацией стандартов (ASA), последняя была организацией предшественницей Американского национального института стандартов (ANSI). В период с 1963 по 1968 год проекты стандартов ISO поддерживали использование только CR+LF или LF в качестве новой строки, в то время как проекты ASA поддерживали только CR+LF.

То есть уже в те годы, один стандарт предписывал использовать сразу две последовательности символов для переноса строки (CR+LF), а другой позволял указывать только одну (LF).

Последовательность CR + LF использовалась во многих ранних компьютерных системах, в которых использовались телетайпы - например для Teletype Model 33 ASR. Разделение новой строки на две последовательности скрывало тот факт, что печатающая головка не могла вовремя вернуться из крайнего правого положения в начало следующей строки для печати следующего символа. Любой символ, напечатанный после CR, часто печатался в виде пятна в середине страницы, в то время как печатающая головка все еще перемещала каретку обратно в первое положение. Вот что об этом писал Qualline, Steve (Автор книги по текстовому редактору VIM)  «Решение состояло в том, чтобы сделать новую строку двумя символами: CR, чтобы переместить каретку в первый столбец, и LF, чтобы переместить бумагу вверх». На самом же деле, и этого было мало. Часто приходилось отправлять лишние символы — посторонние CR или NUL, — которые игнорируются телетайпом, но дают печатающей головке время для перемещения к левому полю. Многим ранним видеодисплеям также требовалось несколько символов для прокрутки дисплея.

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

Приложения/редакторы должны были напрямую общаться с машиной Teletype и следовать ее соглашениям, поскольку концепция драйверов устройств, скрывающих такие детали оборудования от приложения, еще не была хорошо разработана. Поэтому текст обычно составлялся для удовлетворения потребностей телетайпов. Это соглашение использовалось в большинстве миникомпьютерных систем от DEC. CP/M (Control Program for Microcomputers — операционная система для массового рынка, созданная в 1974 году для процессоров Intel 8080/85) также использовала его для печати на тех же терминалах, что и мини-компьютеры. Оттуда MS-DOS (1981 г.) приняла CR + LF для совместимости между операционными системами, и это соглашение было унаследовано более поздней операционной системой Microsoft Windows.

Операционная система Multics начала разрабатываться в 1964 году и использовала только LF в качестве новой строки. Multics использовала драйвер устройства для преобразования этого символа в любую последовательность, необходимую принтеру (включая дополнительные символы заполнения), а один байт был более удобен для программирования. То, что кажется более очевидным выбором было — не использовать CR, поскольку CR предоставлял полезную функцию наложения одной строки на другую для создания эффектов полужирного шрифта, подчеркивания и зачеркивания. Возможно, что более важно, использование только LF в качестве разделителя строки уже было включено в проекты возможного стандарта ISO/IEC 646. Unix последовала практике Multics, а более поздние Unix-подобные системы последовали за Unix. Это создавало конфликты между Windows и Unix-подобными операционными системами, из-за чего файлы, созданные в одной операционной системе, не могли быть правильно отформатированы или интерпретированы другой операционной системой.

Понятия возврата каретки (CR) и перевода строки (LF) тесно связаны между собой и могут рассматриваться как по отдельности, так и вместе. В физических носителях пишущих машинок и принтеров две оси движения, «вниз» и «поперек», необходимы для создания новой строки на странице. Хотя конструкция машины (пишущей машинки или принтера) должна учитывать их по отдельности, абстрактная логика программного обеспечения может объединить их вместе как одно событие. Вот почему новая строка в кодировке символов может быть определена как CR и LF, объединенные в одну (обычно называемую CR+LF или CRLF).

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

Ну, и на десерт, видео от автора про пишущую машинку, о том как работает клавиша shift на печатных машинках.

Ссылки на материалы:
CRLF vs. LF: Normalizing Line Endings in Git
Newline

В предыдущей статье я рассказал (точнее начал рассказывать) про кеширование на клиентской стороне. И в частности мы разобрали заголовок Cache-Control.

По правде говоря я не с того начал. Начать стоило с заголовка Expires. Заголовок Expires появился раньше и до сих пор используется некоторыми веб-сайтами. В данной статье я расскажу историю этого заголовка и отличия от Cache-Control

Заголовок Expires появился в HTTP 1.0 в 1996 году. Он был предназначен для указания даты и времени, после которых ресурс считается устаревшим и должен быть повторно загружен с сервера. Это позволяло уменьшить нагрузку на сервер и ускорить загрузку страницы, так как браузер мог использовать закэшированный ресурс, если он еще не устарел. Однако, в HTTP 1.1 был введен более гибкий заголовок Cache-Control (его мы разбирали в прошлой статье), который позволяет более точно управлять кэшированием ресурсов. Несмотря на это, заголовок Expires все еще поддерживается и используется во всех новых версиях протокола HTTP для обратной совместимости.

Заголовок выглядит как Expires: HTTP-date где HTTP-date один из 3-х форматов даты в формате GMT. Но это уже детали.

Отлично. Давайте приступим к практике. Создадим сервер использую NodeJS и Hapi (Вы можете использовать любой фреймворк). Так же сразу добавим отправку на клиента заголовок Expires (34-я строчка):

response.header('Expires', 'Sat, 1 Oct 2050 01:00:00 GMT');

Запустим сервис и проверим в Postman.

В ответе от сервера видим одновременно два заголовка: Expires и Cache-Control
Дело в том, что большинство серверов по умолчанию уже используют некоторые политики кеширования и в частности сервер HapiJS по умолчанию отправляет заголовок Cache-Control со значением no-cache. В случае когда клиент получает два заголовка, решение всегда в пользу более нового - то есть старый Expires учитываться не будет. Нам такой вариант не подходит. Отключим стандартное поведение сервера для роутов специальной опцией.

Должен получиться следующий код:

Перезапускаем сервер и проверяем.

Отлично. Теперь видим что заголовок всего один и тот что нам нужен. Напомню, что запросы в таких программах как Postman или прямая перезагрузка страницы всегда будет делать запрос на сервер, проверять не изменился ли файл на сервере.
Как раз, для того чтобы проверить, работает ли заголовок Expires мы делали несколько роутов. Откроем адрес htttps://localhost:3000/ в браузере, так же откроем DevTools и попробуем перейти по ссылкам.

Контент кешируется - отлично! Обратите внимание - при прямой перезагрузке страницы браузер делает принудительный запрос контента, но при кликах по ссылкам наше случайное число больше не меняется, а это значит что контент взят из кеша и никакие запросы на сервер не выполнялись. Так же это можно понять по колонке Size в DevTools - вы увидите надпись Disk Cache или Memory Cache.

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

Disk Cache - это кэш, который хранится на жестком диске компьютера. Кэш на диске медленнее, чем кэш в оперативной памяти, но он может хранить большие объемы данных, такие как видео и аудио файлы.

Когда вы открываете веб страницу, браузер загружает ресурсы и кэширует их в Memory Cache или Disk Cache, в зависимости от того, какой тип кэша лучше подходит для каждого ресурса. Разные браузеры имеют собственные политики занесения данных в кеш.

На этом можно было бы и закончить, но как всегда дьявол кроется в деталях.

Как мы знаем, Cache-Control используется для более гибкой настройки кеширования. Если заголовок Cache-Control указывает на запрет кэширования, то Expires не имеет смысла. Но что произойдет если оставить заголовок Cache-Control,  но указать в его значениях, к примеру, только опцию публичности? Для этого, давайте вручную, добавим это заголовок.

Не забудьте добавить эти заголовки в оба роута.

Перезагружаем сервер, проверяем. И все работает. Старинца загружена из кеша.

Я проверил в 3-х браузерах: Chrom, Firefox и Safari. Само наличие заголовка Cache-Control не перечеркивает работу заголовка Expires. Это происходит в том случае, если заголовок Cache-Control имеет запрещающие опции, например no-cache или no-store, а так же если Cache-Control переопределяет время жизни кеша в абсолютных секундах: Cache-Control: max-age=30

В последнем случае при использовании двух заголовков кеш буден храниться 30 секунд, а не до 50-го года.

Пока писал статью, ответил еще на несколько вопросов.

Какое максимальное время жизни для кеша?

В rfc2616 сказано так: To mark a response as "never expires," an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future. (Ответ нашел тут)

Какие есть проблемы при использовании заголовка Expires?

Expires работает только с датами в формате GMT, что может привести к проблемам, если на сервере и клиенте установлены разные часовые пояса. Cache-Control использует относительное время, что позволяет избежать этих проблем. 

Кроме того, некоторые браузеры и прокси-серверы могут игнорировать заголовок Expires, поэтому его использование не всегда гарантирует правильное кэширование ресурсов.

Таким образом нужно помнить, что заголовок Expires устарел и нужно использовать Cache-Control. Но Expires все еще работает, и например, в случае невозможности использовать протокол HTTP1.1 а только HTTP1.0 то заголовок Expires будет полезен.

Сам по себе заголовок Expires очень простой и не требует ответных заголовков от клиента.

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

Если статья была полезной, не забудь поделиться с другом! Удачи!

Ссылки на материалы:

Репозиторий с примерами: (https://github.com/Hydrock/article-hapi-caching/blob/main/examples/client-side/index.js)

Спецификация HTTP1.0 (https://www.w3.org/Protocols/HTTP/1.0/spec#Expires)

MDN Expires (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expires)

MDN Cache-Control (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control)

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

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

Для начала вспомним, что означает слово "Кеш"? Согласно ресурсу etymonline, слово "Кеш" ("Cache") происходит от сленга франко-канадских звероловов и означает «укрытие для припасов и провизии» (1660 г.). Так же слово можно перевести как склад, тайник или схрон.

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

Отлично! С понятием разобрались. Как же нам ускорить наше приложение используя Кеш в веб приложении на HapiJS? Об этом ниже.

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

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

В первой части этого этой статьи показано, как легко настроить hapi для отправки этих заголовков клиентам.

Заголовок Cache-Control сообщает браузеру и любым промежуточным кэшам (между браузером и сервером могут находиться промежуточные сервера и прокси), можно ли кэшировать ресурс и на какой срок. Например, Cache-Control:max-age=30, must-revalidate, private означает, что браузер может кэшировать ресурс в течение тридцати секунд, а private означает, что он не должен кэшироваться промежуточными кэшами, а только браузером. Директива ответа must-revalidate указывает, что ответ может быть сохранен в кеше и может повторно использоваться, пока он свежий. Если ответ устаревает, его необходимо проверить на исходном сервере перед повторным использованием.

Давайте напишем простой сервер на Hapi. Создайте файл index.js и напишите следующий код. Затем запустите командой node ./index.js

После запуска откроем адрес http://localhost:3000 в браузере:

Давайте обновим корневой роут добавив опции кеширования:

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

Да, видим заголовок, но почему тогда код ответа при запросе на этот адрес всегда 200? Напомню что статус 200 означает OK - запрос выполнен удачно. Причем в документации сказано, что по умолчанию, такие ответы кешируемые, если нет других инструкций.

Но если мы сделаем несколько запросов подряд, мы все еще видим статус 200, а не ожидаемый статус 304 NOT MODIFIED. Почему? Давайте разбираться вместе.

Сначала я обратил внимание на то, что клиенты тоже отправляют серверу заголовок Cache-Control. Этот заголовок от клиента так же может указать серверу свои собственные требования. Причем в разных браузерах политика по отправляемым значениям может быть разная.

Например Google Chrome отправляет заголовок Cache-Control: max-age=0.

А вот Mozilla Firefox отправляет заголовок Cache-Control: no-cache.

Safari так же отправляет заголовок Cache-Control: no-cache

Так же для экспериментов я буду использовать Postman. Эта программа позволяет удобно разрабатывать и тестировать ваши HTTP запросы.

Что же отправляет Postman? А все тот же Cache-Control: no-cache. Причем значение заблокировано и управляется клиентом (Postman-ом).

На что же влияет этот заголовок отправляемый с клиента серверу? Такой заголовок позволят указать дополнительные параметры кеширования на сервере.

Ок. На браузеры мы повлиять не можем. Но что же с Postman? Можно ли в нем отправку? Ведь это нам нужно для теста.

Заголовок Cache-Control используется для управления кешированием в разных точках сети: на стороне клиента (браузера) и на стороне сервера.

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

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

Таким образом, заголовок Cache-Control может использоваться как на стороне клиента, так и на стороне сервера, чтобы управлять кешированием и оптимизировать работу сети.

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

Давайте отключим заголовок Cache-Control отправляемым из Postman на сервер, ведь мы все равно пока не кешируем контент на сервере, а наличие этого заголовка в запросе лишь запутывает нас в наших экспериментах.

Дело в том, что Postman по умолчанию всегда отправляет заголовок Cache-Control: no-cache. Т.е. Postman говорит серверу - "не кешируй запросы на сервере, я тут пытаюсь протестировать API".

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

Для тестов я отключу этот заголовок на уровне всего приложения:

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

Но в ответе все еще 200? То есть кеш на стороне клиента не используется? Почему? Что мы делаем не так?

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

Необходим заголовок Last-Modified (заголовок от сервера к клиенту) и его пара, заголовок If-Modified-Since (заголовок от клиента к серверу)

Давайте рассмотрим для чего нужны эти заголовки.

HTTP заголовок "Last-Modified" (Последнее изменение) используется для указания даты и времени последнего изменения ресурса (html документа, картинки и др.) на сервере. Это позволяет браузерам и другим клиентским приложениям узнать, был ли ресурс изменен с момента последнего запроса, и если да, то загрузить обновленную версию.

Данный заголовок обычно добавляется автоматически, сервером. Например, если вы отдаете с сервера статику (картинки, pdf документы и прочее), сервер сам может узнавать последнюю дату изменения файла и подставлять заголовок Last-Modified. 

Чаще всего, пользователи Hapi для раздачи статики используют @hapi/inert. Данный плагин автоматически проставит нужные заголовки.

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

После перезапуска сервера, проверим ответ в Postman:

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

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

Однако, по традиции, в HTTP-заголовках используется так называемый "kanonische Form".

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

Термин "Kanonische Form"  происходит из немецкого языка, где он означает "каноническая форма". В контексте HTTP-заголовков он обычно относится к стилю написания заголовков, где первая буква каждого слова заголовка (кроме предлогов, союзов и т. д.) является заглавной, а все остальные буквы - строчными.

Например, в "Content-Type" первая буква каждого слова является заглавной, а в "Accept-Encoding" - только первая буква первого слова. Такой стиль написания заголовков упрощает чтение и облегчает восприятие информации, а также помогает обеспечить единообразие в их записи.

Хотя термин "Kanonische Form" официально не определен в стандарте HTTP, он широко используется в сообществе разработчиков и экспертов по протоколу HTTP.

Таким образом, хотя сервер может обрабатывать заголовки HTTP, написанные как заглавными, так и строчными буквами, рекомендуется использовать "Kanonische Form" для их записи и заглавные буквы для обозначения методов и версии протокола HTTP.

Продолжим. Мы вернули от сервера 2 заголовка: Cache-Control который просит браузер закешировать контент на 30 секунд, и заголовок Last-Modified который сообщает о том когда этот файл был последний раз изменен.

Но мы все еще видим статус 200? Что на этот раз теперь не так?

Да, в этот раз браузер закешировал данные веб страницы, но ведь при следующем запросе контент на сервере мог измениться, поэтому клиент все равно, повторно, создает соединение с сервером при очередном запросе. В этот раз уже сервер должен решить, что отправить клиенту, либо если кеш совпадаем с файлом который сервер желает отдать клиенту и тогда сервер просто отправляет клиенту статус 304 NOT MODIFIED, что разрешает браузеру использовать кеш, либо если кеш отличается от файла на сервере, и тогда сервер отправляет статус 200, контент и новые заголовки Cache-Control и Last-Modified.

Но как сервер узнает, отличается ли кеш на клиенте от файла на сервере? Для этого, ранее, мы отправляли в браузер заголовок Last-Modified.

Теперь в работу вступает его "брат", заголовок If-Modified-Since (Есть еще заголовок If-Unmodified-Since - но об этом в другой раз).

Заголовок If-Modified-Since используется в протоколе HTTP и позволяет серверу проверить, был ли изменен запрашиваемый ресурс после указанной даты и времени. Если ресурс не был изменен, сервер возвращает код состояния HTTP 304 Not Modified, указывая на то, что клиент может использовать свою кэшированную версию ресурса, не загружая его заново.

Добавим этот заголовок в запрос, со значением переданным с сервера.

Ура! Мы видим статус 304. Что же он означает? Он означает, что запрос от клиента был отправлен на сервер, обработчик роута на сервере выполнился, но сервер принял решение вернуть статус 304, так как по заголовку If-Modified-Since знает, что на клиенте есть Кеш, и так как дата модификации  ресурса не поменялась, говорит клиенту - "Используй свой Кеш, нет смысла отправлять файл обратно"

По идее, заголовок If-Modified-Since клиент должен отправлять самостоятельно, ведь теперь он хранит кеш, и должен сказать браузеру когда последний раз модифицировался этот файл. Но Postman этого не делает. Вообще все поведение которое связано с кешированием, в Postman довольно отличается от поведения браузера. Для сравнения взглянем на Chrome.

Мы видим что браузер Chrome самостоятельно при запросе отправляет заголовок If-Modified-Since.

Как насчет Firefox?

А Safari? И тоже работает?

Но подождите, если я сделаю еще несколько запросов, статусы снова становятся 200. Что же это творится?

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

Вот на что я наткнулся в поисках ответа на вопрос:

Nothing in the spec says that user agents MUST or SHOULD send If-Modified-Since, they just MAY.

У браузера Safari, как всегда, свое мнение на этот счет.

Ок. Это поведение не критично, но вот что действительно странно: Почему статус 304. Ведь мы сохранили данные в Кеш браузера, а это означает, что пока не истекло время жизни Кеша, браузер вовсе не должен делать запросы на сервер, браузер должен просто вернуть данные из кеша (это будет видно в devtools) и поставить статус 200. Запрос на сервер вообще не должен происходить.

В нашем же случае мы устанавливаем, время жизни Кеша в 30 секунд. Но несмотря на это браузера все равно делает запрос на сервер, как будто время жизни кеша вышло. Сервер сравнивает дату модификации ресурса, понимает что кеш валидный и отправляет сообщение клиенту 304 NOT MODIFIED - подсказывает браузеру что он может использовать сохраненный кеш, при этом тело ответа пустое. Т.е. браузер использует Кеш, но все равно постоянно создает соединение между клиентом и сервером, что отнимает драгоценные ресурсы.

Я потратил очень много времени, чтобы понять в чем дело. Все оказалось очень просто, но я кажется потратил треть своих нервных клеток. А дело вот в чем:

Если вы перезагружаете веб страницу при помощи кнопки "Reload Page" (обычно это круговая стрелка рядом с адресной строкой), то такая перезагрузка воспринимается браузером как принудительная, поэтому браузер игнорирует Кеш и создает подключение к серверу, для отправки http сообщения. Это работает во всех браузерах примерно одинаково с небольшими отличиями.

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

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

На анимации ниже, я показываю, как принудительная перезагрузка в Хром игнорирует Кеш и отравляет запросы на сервер, при этом сервер отвечает 304. При этом в мы видим Request Headers в блоке информации о запросе.

Но если мы начинаем переходить по ссылке, на одну и ту же страницу, то тут же видим статус 200 и в колонке size надпись disk cached (кешировано на диске). При этом, если открыть информацию о запросе, мы не видим блока Request Headers. Ведь не было никакого запроса на сервер, мы видим блок Response Headers, благодаря этому можно сделать вывод, что кешируется не только сам контент, но и заголовки от сервера в кешируемом ресурсе, то есть контент берется из кеша и подставляются все заголовки из предыдущего запроса. Как будто запрос на сервер был, но на самом деле нет.

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

А вот в Firefox поведение немного отличается. Перезагрузка на кнопку Reload this Page так же приводит к статусу 304, если переходим по ссылкам видим ответ 200 - то есть берем данные из Кеша, вот только в отличие от Chrome в блоке информации о кешированном запросе мы видим секцию Request Headers хотя запроса не было. С одной стороны это хорошо, так как мы можем посмотреть заголовки запроса, а с другой стороны может вводить в заблуждение.

Еще одним отличием является то, что при клике в адресной строке и перезагрузки страницы при помощи клавиши Enter не воспринимается браузером Firefox как принудительный запрос, и мы видим статус 200 - данные взяты из кеша.

Поведение в Safari так же отличается. Как я сказал ранее, при принудительной перезагрузке, то есть при нажатии кнопки Reload this Page, Safari не отправляет на сервер заголовок If-Modified-Since, что не позволяет сравнить даты модификации ресурса и заставляет сервер генерировать новый контент постоянно. Перезагрузка кликом в адресной строке так же воспринимается как принудительная перезагрузка страницы. Мы видим статусы 200 в ответах, а на веб странице постоянно новые случайные числа.

Если же мы начинаем переходить по заготовленным ссылкам, кеш начинает работать. Мы видим надпись Кешировано в колонке Передано и статус 200. При этом в секции Request, в информации о запросе, видим надпись - No request, served from the memory cache.

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

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

Давайте резюмируем.

Мы хотим указать клиенту (браузеру) закешировать ресурс.

Для этого, в ответе от сервера необходимо прислать заголовок Cache-Control: max-age=30, где 30 это время в секундах, когда кеш будет работать. 

Если вы будете запрашивать ресурс без принудительного запроса (не нажимать кнопку Reload This Page или перезагружать страницу через адресную строку), то тогда данные ресурса будут браться из кеша.

Ответ будет 200, и в devtools мы явно увидим, что ресурс взят из кеша.

После того как 30 секунд выйдут и вы снова произведете запрос за ресурсом, браузер выполнит запрос на сервер, получит ответ 200, получит новый ресурс в теле ответа и заголовок Cache-Control: max-age=30 установит новый Кеш.

Тут тоже можно сэкономить. Если при установке кеша, вместе с заголовком Cache-Control: max-age=30 установить заголовок Last-Modified: Sun, 09 Apr 2023 11:52:22 GMT (дата последней модификации ресурса) то клиент сохранит эту дату вместе с кешем.

Когда кеш протухнет, браузер сделает запрос на сервер за свежим ресурсом, при этом отправит дополнительный заголовок If-Modified-Since: Sun, 09 Apr 2023 11:52:22 GMT с тем же значением даты. Таким образом сервер может сравнить, дату модификации своего файла, и дату модификации в кеше. Если они одинаковы, то нет смысла пересылать тело запроса еще раз, ведь в Кеше браузера все еще есть подходящие данные (после истечения срока жизни кеша данные не удаляются из браузера - политики хранения кеша в браузерах - отдельная тема для изучения).
В таком случае сервер меняет статус ответа на 304. При этом отправляет остальные заголовки нетронутыми, в том числе заголовок Last-Modified, что позволяет снова продлить время жизни Кеша.

Из особенностей браузеров стоит отметить, что кнопка Reload This Page игнорирует свежий Кеш и делает принудительный запрос на сервер каждый раз. В Postman запросы всегда принудительные. Так же в браузерах отличается запрос при обновлении адреса в адресной строке.

На этом пока все. Продолжим наши страдания в следующей част

Ссылки на материалы:

Репозиторий с примерами: (https://github.com/Hydrock/article-hapi-caching/blob/main/examples/client-side/index.js)

Прекрасное видео о кешировании на сервере и клиенте (https://www.youtube.com/watch?v=HiBDZgTNpXY)

Кеширование в Hapi (https://hapi.dev/tutorials/caching/?lang=en_US)

Cache-Control MDN (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control)

На этом видео показан Remix фреймворк, но тема видео связана с Кешем. (https://www.youtube.com/watch?v=3XkU_DXcgl0)

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

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

Python имеет обширную библиотеку модулей и пакетов, которые могут быть использованы для различных целей. Изучайте различные модули, которые входят в стандартную библиотеку Python, такие как os, sys, re и другие. Вы также можете изучить библиотеки, которые специализируются на конкретных областях, таких как NumPy, Pandas, Matplotlib для работы с данными и многое другое.

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

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

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

Без лишних слов. Сразу приступим к делу.

Для написания телеграм бота на Python, вам необходимо выполнить следующие шаги:

1. Создайте нового бота в Telegram, написав в Telegram боте @BotFather команду /newbot и следуя инструкциям. При создании бота вам нужно будет придумать ему имя - для примера я создам бота с именем python-telegram-bot. У вас имя будет другое. В конце создания бота - вы получите токен - сохраните его на вашем устройстве.

2. Установите библиотеку python-telegram-bot, используя команду pip install python-telegram-bot в консоли вашего компьютера.

Чтобы открыть командную строку на Windows, в поиске найдите прогрумму CMD и запустите ее.

3. Запустите редактор Visual Studio Code (либо любой другой) и создайте файл main.py

4. Импортируйте необходимые библиотеки в файл main.py:

5. Создайте переменную token и поместите в нее строку токена полученного от @BotFather

6. Создайте функцию для обработки команды hello - данная функция будет отвечать пользователю строкой Hello с именем пользователя

7. Следующей командой создаем инстанс бота с использованием токена

8. Добавляем обработчик команды /hello в вашем боте - для этого мы и готовили функцию hello выше.

9. Наконец запускаем бота

Пока программа запущена - найдите вашего бота в telegram - и отправьте вашему боту команду /hello

Поздравляю!  Вы написали своего первого бота. Попробуйте написать другие фунциии и зарегистрировать новые команды.

Итоговый код - должен выглядеть примерно так:

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

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

Autocannon — это инструмент для сравнительного анализа HTTP/1.1, написанный на NodeJS и широко используемый для измерения производительности приложения. С помощью autocannon мы можем моделировать несколько запросов в секунду для нагрузочного тестирования нашего приложения.

Кстати, cannon переводится как пушка, орудие (не путать с компанией Canon, а вот звучат слова одинаково), ну а autocannon - автопушка соответственно.

Установите autocannon глобально.

Больше опций вы можете найти здесь.

Выполните следующую команду в терминале:

Если при запуске команды вы встретите ошибку запрета на запуск отключенных в системе сценариев (только Windows), установите политику выполнения следующим образом:

Данная команда используется в PowerShell для изменения политики выполнения скриптов для текущего пользователя. Параметр -ExecutionPolicy Unrestricted указывает, что можно запускать любые скрипты, включая скрипты, скачанные из Интернета, что может представлять потенциальную угрозу безопасности, если скрипты не являются доверенными. Параметр -Scope CurrentUser означает, что изменения политики выполнения будут применяться только к текущему пользователю, не влияя на других пользователей системы или на глобальную политику выполнения скриптов в системе.

Вы должны увидеть примерно сдедущий отчет:

- autocannon: Это команда для запуска `autocannon`, начинающая тест производительности.

- -c 100: Этот параметр указывает количество одновременных подключений к серверу. В данном случае `-c 100` означает, что `autocannon` будет поддерживать 100 одновременных подключений к целевому серверу во время теста.

- -d 5: Задает длительность теста в секундах. -d 5 означает, что нагрузочный тест будет продолжаться 5 секунд.

- -p 10: Устанавливает период ожидания в миллисекундах между запросами для каждого подключения. В данном случае `-p 10` означает, что будет 10 миллисекунд паузы между запросами, сделанными одним подключением. Это помогает немного разгрузить сервер, делая тест более реалистичным по сравнению с беспрерывной отправкой запросов.

- https://google.com: Целевой URL, к которому `autocannon` будет направлять запросы. В данном случае тестируется производительность веб-сервера Google.

В совокупности, эта команда запускает нагрузочный тест, который в течение 5 секунд будет поддерживать 100 одновременных подключений к `https://google.com`, делая паузу в 10 мс между запросами каждого подключения. Это позволяет оценить, как сервер справляется с высокой нагрузкой, и измерить его производительность и способность обрабатывать множество одновременных запросов.

Autocannon, по завершению теста выводит две таблицы данных:

1. Request Latency (Задержка запроса)
2. Request Volume (Объем запроса)

Давайте рассмотрим их подробнее.

Эта таблица показывает время отклика вашего API. Здесь приводятся различные метрики, которые описывают, как быстро сервер отвечает на запросы. Обычно здесь указываются:

Min: Минимальное время отклика за время теста.
Max: Максимальное время отклика за время теста.
Median: Медианное время отклика. Это означает, что половина запросов была обработана быстрее данного времени, а другая половина - медленнее.
Average: Среднее время отклика.
Percentiles: Процентили показывают время отклика в определенном проценте запросов. Например, 95-й процентиль означает, что 95% запросов были обработаны за это время или быстрее.

Давайте разберем на конкретном примере:

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

- 2.5%: Значение задержки в 66 мс означает, что 2.5% запросов имели задержку 66 мс или меньше. Это показывает минимальную задержку, с которой сталкивалось очень маленькое число запросов.

- 50% (Медиана): Значение в 77 мс указывает, что половина всех запросов была выполнена с задержкой 77 мс или меньше. Это наиболее типичное значение задержки для вашего API.

- 97.5%: 169 мс означает, что 97.5% запросов имели задержку 169 мс или меньше. Это дает представление о верхнем пределе задержек для большинства запросов.

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

- Avg (Average / Среднее): Средняя задержка составила 110.63 мс. Это значение рассчитывается путем деления суммы всех задержек на количество запросов и дает общее представление о том, с какой задержкой обрабатываются запросы в среднем.

- Stdev (Standard deviation / Стандартное отклонение): Стандартное отклонение задержки равно 194.86 мс. Это показывает, насколько разнообразными были задержки запросов. Большое стандартное отклонение указывает на то, что время отклика API сильно варьировалось.

- Max (Максимум): Максимальная зафиксированная задержка составила 1450 мс. Это значение показывает максимальное время отклика, которое было зафиксировано во время теста.

Итак, эти данные демонстрируют, что большинство запросов обрабатывалось довольно быстро (до 169 мс для 97.5% запросов), но существовали исключения, когда время отклика значительно возрастало (до 1396 мс для 1% запросов и максимум 1450 мс). Это может указывать на потенциальные проблемы с производительностью или стабильностью для определенных типов запросов или в определенных условиях.

Таблица Request Volume показывает статистику по количеству запросов в секунду (Req/Sec) и объему переданных данных в секунду (Bytes/Sec) в ходе тестирования API. Давайте подробно разберем значения:

Давайте так же рассмотрим на примере:

1%: Минимальное количество запросов в секунду, которое система смогла обработать, составляет 10. Это означает, что даже в худших условиях производительности, 1% результатов был не ниже 10 запросов в секунду.

2.5%: Также 10 запросов в секунду, указывая на то, что хотя бы 2.5% времени система обрабатывала не менее 10 запросов в секунду.

50% (Медиана): В половине случаев система обрабатывала 30 запросов в секунду, что является наиболее типичным показателем производительности системы во время теста.

97.5%: В 97.5% случаев система обрабатывала не более 40 запросов в секунду, что указывает на верхний предел производительности системы под нагрузкой.

Avg (Среднее): В среднем, система обрабатывала 26.4 запроса в секунду.

Stdev (Стандартное отклонение): Стандартное отклонение равно 10, что говорит о вариативности количества обрабатываемых запросов в секунду во время теста.

Min (Минимум): Минимальное количество запросов в секунду в ходе всего теста составило 10.

1%: Минимальный объем данных, переданных в секунду, составляет 8.33 кБ. Это означает, что в худших 1% случаев объем переданных данных не опускался ниже этого значения.

2.5%: Такой же объем данных, как и для 1%, указывает на минимальный уровень производительности системы в плане передачи данных.

50% (Медиана): В половине случаев система передавала 25 кБ данных в секунду.

97.5%: В 97.5% случаев объем переданных данных не превышал 33.3 кБ в секунду.

Avg (Среднее): В среднем, система передавала 22.3 кБ данных в секунду.

Stdev (Стандартное отклонение): Стандартное отклонение равно 8.19 кБ, что указывает на вариативность объема переданных данных в секунду.

Min (Минимум): Минимальный объем данных, переданный в секунду во время всего теста, составил 8.32 кБ.

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

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

Завершающая часть отчета `autocannon`, которую мы видим на изображении, содержит важную информацию о результатах тестирования.

Давайте разберем отчет подробно:

- Req/Bytes counts sampled once per second: Это означает, что количество запросов и объем переданных данных измерялись один раз в секунду в течение всего теста.

- # of samples: 5: Указывает на количество измерений (или выборок), сделанных во время теста. Поскольку тест длился 5 секунд, было сделано 5 измерений. Это соответствует периодичности измерений в одну секунду.

- 0 2xx responses: Показывает количество успешных HTTP-ответов, полученных во время теста. Коды состояния 2xx означают успешную обработку запроса сервером. В данном случае успешных ответов не было.

- 132 non 2xx responses: Указывает на количество ответов, которые не относятся к категории успешных (то есть все, кроме 2xx). Это могут быть ответы с кодами 3xx (перенаправления), 4xx (ошибки клиента) и 5xx (ошибки сервера). В вашем тесте было получено 132 таких ответа.

- 232 requests in 5.04s: Общее количество выполненных запросов за время теста, которое составило 5.04 секунды, было 232. Это дает представление о нагрузке, которую тестирование создавало на сервер.

- 112 kB read: Объем данных, прочитанных в ходе теста, составил 112 килобайт. Это включает в себя данные всех полученных ответов, включая тела ответов и заголовки.

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

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

Программный запуск autocannon дает возможность динамически конфигурировать параметры тестирования, обрабатывать результаты испытаний на лету и интегрировать нагрузочное тестирование в более широкие процессы CI/CD (Continuous Integration/Continuous Deployment).

Вот базовый пример использования autocannon программно:

В этом примере мы используем `autocannon` для программного запуска нагрузочного теста, указывая URL для тестирования, количество одновременных соединений и продолжительность теста. После завершения теста результаты выводятся в консоль. Вот мой результат этого теста:

Давайте разберем этот отчет.

1. Общие параметры теста:

- Было использовано 10 одновременных соединений.

- Продолжительность теста составила около 5.04 секунды.

- Всего было сделано 5 измерений (раз в секунду).

- Тест начался в 20:04:56 и завершился в 20:05:01 по UTC 13 февраля 2024 года.

2. Результаты по HTTP-ответам:

- Все 110 полученных ответов были с кодом 3xx (перенаправления), что указывает на то, что все запросы были перенаправлены. Конкретно, все ответы были с кодом 301 (Permanent Redirect).

- Не было зафиксировано ни одного успешного ответа с кодом 2xx, что связано с тем, что google.com, вероятно, выполняет перенаправление на версию сайта с HTTPS или на локализованную версию.

- Ошибок, таймаутов, несоответствий и сбросов соединений не было.

3. Статистика задержек:

- Средняя задержка составила 426.13 мс с минимальной задержкой в 376 мс и максимальной в 604 мс. Это показывает временные рамки отклика сервера на запросы.

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

4. Статистика запросов:

- В среднем обрабатывалось 22 запроса в секунду с минимумом в 20 и максимумом в 30 запросов. Всего было выполнено 110 запросов.

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

5. Статистика пропускной способности:

- Средняя пропускная способность составила 18312 байт в секунду (приблизительно 17.9 кБ/с) с минимумом в 16640 байт и максимумом в 24960 байт. Общий объем переданных данных составил 91520 байт (приблизительно 89.4 кБ).

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

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

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

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

Пример запуска теста в 4-х потоках:

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

Распределение нагрузки: Использование воркеров позволяет autocannon распределять нагрузку между несколькими потоками, что увеличивает общее количество запросов, которое может быть отправлено и обработано за единицу времени.

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

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

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

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

Использование параметра workers в autocannon является продвинутой функцией, которая может помочь в создании более мощных и настроенных под конкретные нужды сценариев нагрузочного тестирования. Однако стоит помнить, что увеличение количества воркеров также увеличивает потребление системных ресурсов, таких как CPU и память, что может повлиять на результаты тестирования.

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

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

Вот пример кода на Node.js, который демонстрирует, как это можно сделать:

В этом примере autocannon настроен на отправку запросов к трем разным путям (/, /about, /api/data) на http://example.com. Каждый запрос может быть настроен индивидуально, включая метод HTTP, путь, тело запроса и заголовки. Это позволяет тестировать различные аспекты вашего веб-приложения или API, используя один и тот же экземпляр autocannon.

1. Создание объектов клиента для соединений: Когда вы запускаете `autocannon`, он создает объекты клиента (Client) в количестве, соответствующем указанному вами числу соединений. Каждый из этих клиентов будет выполнять запросы параллельно друг другу в течение всего времени тестирования. Это время может быть ограничено либо длительностью теста, либо общим числом запросов.

2. Циклическая обработка массива запросов: Каждый клиент последовательно перебирает массив запросов, который может содержать один или несколько запросов. Это означает, что если в массиве указано несколько запросов, клиент будет отправлять их по очереди до тех пор, пока тест не будет завершен.

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

4. Функции `onResponse` и `setupRequest`: Вы можете использовать эти функции для работы с контекстом. Функция `setupRequest` позволяет настраивать запросы перед их отправкой, используя данные из контекста, а `onResponse` — обрабатывать ответы сервера, возможно, модифицируя контекст для следующих запросов.

5. Сброс контекста: Когда клиент завершает цикл по массиву запросов и возвращается к первому запросу для повторной отправки, контекст сбрасывается. Это делается для обеспечения одинаковых условий для каждого нового цикла запросов. Контекст будет сброшен к начальному состоянию (`initialContext`), предоставленному вами, или к пустому объекту `{}`, если начальный контекст не был указан.

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

Когда вы настраиваете `autocannon` для выполнения определенного количества HTTP-запросов (`amount`), используя фиксированное количество одновременных соединений (`connections`) с ограничением на общую скорость отправки запросов (`overallRate`), `autocannon` стремится равномерно распределить эту нагрузку между всеми соединениями. Это распределение включает в себя как количество запросов, так и скорость их отправки.

Распределение общей скорости (`overallRate`)

- Если значение `overallRate` (заданное в запросах в секунду для всего теста) не делится нацело на количество соединений (`connections`), `autocannon` будет настраивать часть соединений на отправку немного большего количества запросов в секунду, а другую часть — на отправку меньшего количества. Это делается для того, чтобы в сумме достичь заданной общей скорости.

Распределение количества запросов (`amount`)

- Если общее количество запросов (`amount`) делится нацело на количество соединений, каждое соединение получит одинаковое количество запросов для выполнения.

Влияние на воспринимаемую скорость запросов

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

Пример

Допустим, у нас есть следующие параметры: `connections = 10`, `overallRate = 17`, `amount = 5000`. Это означает, что `autocannon` будет стремиться распределить общее количество запросов (5000) между 10 соединениями таким образом, чтобы общая скорость запросов не превышала 17 запросов в секунду на все соединения вместе взятые. Если деление не нацело, некоторые соединения будут работать быстрее, а некоторые — медленнее, чтобы в сумме обеспечить заданную скорость.

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

Процессорные Ресурсы

- Ограниченность процессорными ресурсами: `Autocannon`, как и любой инструмент, написанный на JavaScript и работающий в среде Node.js, активно использует процессорные ресурсы (CPU-bound). Это значит, что его производительность и способность генерировать нагрузку зависят от мощности и загрузки процессора.

Сравнение с `wrk`

- Потребление CPU: По сравнению с `wrk`, который компилируется в бинарный код и обычно использует меньше процессорного времени, `autocannon` может использовать значительно больше CPU для выполнения аналогичных задач нагрузочного тестирования. Пример с использованием 1000 соединений на 4-ядерном сервере с поддержкой Hyper-Threading демонстрирует, что `wrk` распределяет свою нагрузку более эффективно, используя несколько потоков, в то время как `autocannon` нагружает один поток на 80%.

Рекомендация использования `wrk2`

- Насыщение CPU: Если процесс `autocannon` достигает 100% использования CPU, это может повлиять на точность и надежность результатов тестирования. В таких случаях рекомендуется использовать `wrk2`, который может обеспечить более низкую и равномерную нагрузку на процессор.

Поддержка HTTP/1.1 Pipelining

- HTTP/1.1 Pipelining: Одним из преимуществ `autocannon` перед `wrk` является поддержка пайплайнинга HTTP/1.1, что позволяет `autocannon` создавать большую нагрузку на сервер за счет одновременной отправки нескольких HTTP-запросов в рамках одного соединения без ожидания ответа на каждый запрос. Это может быть особенно полезно при тестировании серверов и приложений, оптимизированных для работы с HTTP/1.1 pipelining.

`Autocannon` — мощный и гибкий инструмент, написанный на JavaScript для среды Node.js, который позволяет проводить комплексное тестирование производительности веб-приложений и API. Он предлагает широкий спектр настраиваемых параметров, включая поддержку HTTP/1.1 pipelining, возможность тестирования нескольких URL за один запуск и гибкое управление количеством запросов, соединений и продолжительностью теста.

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

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

Статью мне помогали писать:

1) Эта статья.
2) Документация autocannon.
3) ChatGPT

Git — мощная система контроля версий, которая позволяет разработчикам отслеживать изменения в коде и сотрудничать над проектами. Однако в процессе работы история коммитов может стать запутанной из-за множества мелких или неинформативных коммитов. Объединение коммитов (squash) помогает привести историю в порядок, делая её более понятной и управляемой.

• Упорядочение истории: Объединение коммитов позволяет собрать связанные изменения в один коммит, делая историю проекта более чистой и логичной.

• Удобство для ревьюеров: Меньшее количество коммитов с ясными сообщениями облегчает код-ревью и понимание изменений.

• Избежание лишних конфликтов: При объединении веток меньшее количество коммитов снижает вероятность конфликтов.

Интерактивный rebase — мощный инструмент для изменения истории коммитов. Вот пошаговая инструкция:

1. Определите диапазон коммитов: Решите, сколько последних коммитов вы хотите объединить. Например, чтобы объединить последние 3 коммита, используйте HEAD~3.

2. Запустите интерактивный rebase:

3. Выберите коммиты для объединения: В открывшемся редакторе вы увидите список коммитов:

Замените pick на squash или s для тех коммитов, которые хотите объединить с предыдущим:

4. Сохраните и закройте редактор: После этого Git предложит вам отредактировать сообщение итогового коммита.

5. Отредактируйте сообщение коммита: Вы можете объединить сообщения или написать новое.

6. Завершите rebase: Сохраните изменения, и Git применит объединение.

Объединение коммитов при слиянии веток

• Осторожность при работе с общими ветками: Изменение истории коммитов, которые уже отправлены в общий репозиторий, может привести к конфликтам с работой других разработчиков.

• Коммиты — это история проекта: Убедитесь, что объединение действительно улучшает историю, а не скрывает важные детали изменений.

• Используйте понятные сообщения коммитов: Это облегчит понимание истории даже без объединения.

• Часто обновляйте ветки: Регулярное обновление веток и разрешение конфликтов уменьшает необходимость в крупных изменениях истории.

Объединение коммитов — полезная практика для поддержания чистой и понятной истории проекта. Это особенно важно в командной работе, где ясность и упорядоченность облегчают совместную разработку и поддержку кода. Используя git rebase -i и другие инструменты Git, вы можете эффективно управлять историей коммитов и улучшать качество вашего проекта.

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

Эта статья - перевод и адаптация статьи How To Create An NPM Package от Matt Pocock

В этой статье будут использованы следующие технологии:

1) Git для контроля версий
2) TypeScript для написания кода и обеспечения его типобезопасности.
3) Prettier для форматирования кода
4) @arethetypeswrong/cli для проверки нашего экспорта
5) tsup для компиляции нашего кода TypeScript в CJS и ESM
6) Vitest для проведения наших тестов
7) GitHub Actions для запуска CI
8) Changesets для управления версиями и публикации нашего пакета

Если вы хотите увидеть готовый результат - посмотрите этот репозиторий.

В этом разделе мы создадим новый репозиторий git, настроим .gitignore, создадим первоначальный коммит, создадим новый репозиторий на GitHub и отправим наш код на GitHub.

1.1: Инициализация репозитория

Выполните следующую команду, чтобы инициализировать новый репозиторий git:

1.2: Настройка .gitignore

Создайте файл .gitignore в корне вашего проекта и добавьте следующее:

1.3: Создание первоначального коммита

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

1.4: Создание нового репозитория на GitHub.

У github есть замечательная консольная утилита gh для работы с github из консоли. Если до этого вы не пользовались cli утилитой - перейдите на сайт https://cli.github.com и установите утилиту по инструкции.

Пройдите аутентификацию вызвав команду:

Выполните следующую команду, чтобы создать новый репозиторий. Для этого примера я выбрал имя tt-package-demo:

Команда gh repo create tt-package-demo --source=. --public выполнит следующие действия:

1. Создаст новый удалённый репозиторий с именем tt-package-demo на GitHub.

2. Укажет исходную директорию (в данном случае текущую директорию, обозначенную как .) для этого репозитория.

3. Сделает репозиторий публичным (благодаря флагу --public).

4. Привяжет удалённый репозиторий к вашему локальному репозиторию, добавив GitHub-репозиторий в качестве удалённого (origin).

Таким образом, после выполнения этой команды ваш локальный репозиторий будет связан с новым удалённым репозиторием на GitHub, и вы сможете отправлять коммиты с помощью команды git push origin main или аналогичных команд для других веток.

Выполните следующую команду, чтобы отправить свой код на GitHub:

В этом разделе мы создадим файл package.json, добавим поле license, создадим файл LICENSE и добавим файл README.md.

2.1. Создание файла package.json

Создайте файл package.json со следующим содержимым:

name - это имя, под которым пользователи будут устанавливать ваш пакет. Оно должно быть уникальным в npm. Для имени пакета можете создать так называемые organization scopes (например, имя пакета @total-typescript/demo где @total-typescript - пространство организации), это поможет сделать ваш продукт уникальным.

version - это версия вашего пакета. Он должен соответствовать семантическому версионированию (semantic versioning): формат 0.0.1. Каждый раз, когда вы публикуете новую версию, вы должны увеличивать это число.

description и keywords - это краткое описание вашего пакета. Они указаны в поиске в реестре npm.

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

bugs - это URL-адрес, по которому пользователи могут сообщать о проблемах с вашим пакетом.

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

repository - это URL-адрес хранилища вашего пакета. При этом в реестре npm создается ссылка на ваш репозиторий на GitHub.

files - это массив файлов, которые должны быть включены при установке вашего пакета. В данном случае мы включаем папку dist. Файлы README.md, package.json и LICENSE включены по умолчанию.

Значение type равно module, чтобы указать, что ваш пакет использует систему модулей ECMAScript, а не модули CommonJS.

2.2: Добавление поле лицензии.

Добавьте поле license в package.json. Выберите лицензию здесь. Я выбрал MIT.

2.3: Добавление файла ЛИЦЕНЗИИ

Создайте файл с именем LICENSE (без расширения), содержащий текст вашей лицензии. Для MIT это:

Измените заполнители [год] и [полное имя] на текущий год и свое имя.

2.4: Добавление README.md

Создайте файл README.md с описанием вашего пакета. Вот пример:

Это будет показано в реестре npm, когда люди будут просматривать ваш пакет.

3: TypeScript

В этом разделе мы установим TypeScript, настроим tsconfig.json, создадим исходный файл, создадим index файл, настроим сценарий сборки (build), запустим нашу сборку, добавим dist в .gitignore, настроим сценарий ci и настроим наш tsconfig.json для DOM.

3.1: Установка TypeScript

Запустите следующую команду, чтобы установить TypeScript:

Мы добавляем к команде флаг --save-dev для установки TypeScript в качестве зависимости разработки. Это означает, что он не будет включен при установке вашего пакета у пользователя.

3.2. Настройка tsconfig.json.

Создайте файл tsconfig.json со следующим содержимым:

Эти параметры подробно описаны в шпаргалке по TSConfig.

3.3. Настройка tsconfig.json для DOM

Если ваш код выполняется в DOM (т. е. требует доступа к document, window, localStorage и т. д.), пропустите этот шаг.

Если вашему коду не требуется доступ к DOM API, добавьте в tsconfig.json следующее:

Опция `"lib": ["es2022"]` в настройках TypeScript указывает, какие встроенные библиотеки JavaScript должны быть доступны во время компиляции. В данном случае, указывая `["es2022"]`, вы говорите компилятору, что хотите использовать возможности и объекты, доступные в спецификации ECMAScript 2022.

Это позволяет вам использовать такие возможности, как методы и API, которые появились в ES2022, например, `Array.prototype.at`, улучшенные функции для работы с `WeakRefs` и другие.

Если ваш код должен поддерживать более старые версии JavaScript, можно выбрать соответствующие библиотеки, например, `"es5"` или `"es6"`.

При использовании настройки "lib": ["es2022"] поддержка типов для DOM (например, таких объектов, как document, window, HTMLElement и т. д.) не будет включена автоматически, потому что в данном случае подключается только стандартная библиотека ECMAScript 2022.

Чтобы добавить поддержку типов для DOM, нужно явно указать библиотеку DOM, добавив её в список `"lib": ["es2022", "dom"]`

Это обеспечит поддержку типов для работы с веб-API и объектами браузера, такими как элементы страницы и события.

Но в нашем случае это не требуется.

3.4: Создание исходный файл (Source File)

Создайте файл src/utils.ts со следующим содержимым:

3.5: Создание индексного файла (Index File)

Создайте файл src/index.ts со следующим содержимым:

Понимаю, расширение .js выглядит странно. Эта статья объясняет больше.

Если совсем кратко, то в статье объясняется, что при использовании настроек moduleResolution: node16 или nodenext в TypeScript требуется явное указание расширений файлов при импорте (например, ./module.js). Это сделано для соответствия спецификации Node.js, что упрощает процесс разрешения модулей. Если добавить расширение .ts, возникает ошибка, так как эта опция работает только при включенной настройке allowImportingTsExtensions. Чтобы избежать этого, рекомендуется использовать .js в импортах или изменить модульную конфигурацию.

3.6: Настройка сценария сборки

Добавьте секцию scripts в ваш package.json со следующим содержимым:

Этот скрипт скомпилирует ваш код TypeScript в JavaScript.

3.7: Запуск сборки

Запустите следующую команду, чтобы скомпилировать код TypeScript:

После выполнения команды будет создана директория dist с вашим скомпилированным кодом JavaScript.

3.8: Добавьте dist в .gitignore

Добавьте папку dist в ваш файл .gitignore файл:

Это предотвратит включение скомпилированного кода в ваш репозиторий git.

3.9: Настройка ci-скрипта

Добавьте в package.json скрипт ci со следующим содержимым:

Это даст нам быстрый доступ для выполнения всех необходимых операций в CI.

В этом разделе мы установим Prettier, настроим .prettierrc, настроим скрипт форматирования (format), запустим скрипт форматирования (format), настроим скрипт проверки формата (check-format), добавим скрипт проверки формата (check-format) в наш скрипт CI и запустим CI сценарий.

4.1: Установка Prettier

Запустите следующую команду, чтобы установить Prettier:

4.2: Настройка .prettierrc

Создайте файл .prettierrc со следующим содержимым:

Вы можете добавить в этот файл дополнительные параметры, чтобы настроить поведение Prettier. Полный список опций вы можете найти здесь.

4.3: Настройка сценария форматирования (format script)

Добавьте в package.json скрипт format со следующим содержимым:

Это приведет к форматированию всех файлов вашего проекта с помощью Prettier.

4.4: Запуск сценарий форматирования

Запустите следующую команду, чтобы отформатировать все файлы вашего проекта:

Вы можете заметить, что некоторые файлы изменились. Зафиксируйте изменения с помощью команд:

4.5: Настройка сценария проверки формата (check-format)

Добавьте в package.json скрипт check-format со следующим содержимым:

Этот скрипт проверит, правильно ли отформатированы все файлы в вашем проекте.

4.6: Добавление CI-скрипта

Добавьте скрипт check-format в скрипт ci в package.json:

Это запустит скрипт проверки формата как часть вашего процесса CI.

В этом разделе мы установим @arethetypeswrong/cli, настроим скрипт check-exports, запустим скрипт check-exports, настроим main поле, снова запустим скрипт check-exports, настроим и запустим скрипт ci.

@arethetypeswrong/cli — это инструмент, который проверяет правильность экспорта вашего пакета. Это важно, поскольку в них легко ошибиться, и это может вызвать проблемы у людей, использующих ваш пакет.

5.1: Установка @arethetypeswrong/cli

Запустите следующую команду, чтобы установить @arethetypeswrong/cli:

5.2: Настройка скрипта проверки экспорта

Добавьте в package.json скрипт check-exports со следующим содержимым:

Это проверит, все ли экспорты из вашего пакета верны.

5.3: Запуск скрипта check-exports

Запустите следующую команду, чтобы проверить правильность всех экспортов из вашего пакета:

Вы должны заметить различные ошибки:

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

Давайте это исправим

5.4: Установка main

Добавьте поле main в package.json со следующим содержимым:

Это строчка подсказывает Node, где найти точку входа вашего пакета.

5.5: Пробуем еще раз проверить экспорт

Запустите следующую команду, чтобы проверить правильность всех экспортов из вашего пакета:

Теперь, вы должны заметить только одно предупреждение:

Это говорит нам о том, что наш пакет совместим с системами, на которых работает ESM. Людям, использующим CJS (часто в устаревших системах), потребуется импортировать его с помощью динамического импорта.

5.6 Исправление предупреждения CJS

Если вы не хотите поддерживать CJS модули (что я рекомендую), измените сценарий check-exports на:

Теперь при запуске check-export все будет отображаться зеленым цветом:

Если вы предпочитаете двойную публикацию CJS и ESM, пропустите этот шаг.

5.7: Добавление в наш CI-скрипт

Добавьте скрипт check-exports в сценарий ci в package.json:

Если вы хотите опубликовать код CJS и ESM модулей, вы можете использовать tsup. Это инструмент, созданный на основе esbuild, который компилирует ваш код TypeScript в оба формата.

Моя личная рекомендация — пропустить этот шаг и отправлять только ES-модули. Это значительно упрощает настройку и позволяет избежать многих ошибок двойной публикации, таких как Dual Package Hazard.

6.1: Установите tsup

Запустите следующую команду, чтобы установить tsup:

6.2. Создайте файл tsup.config.ts

Создайте файл tsup.config.ts со следующим содержимым:

entryPoints - это массив точек входа для вашего пакета. В данном случае мы используем src/index.ts.

format - это массив форматов для вывода. Мы используем js (CommonJS) и esm (модули ECMAScript).

dts - параметр, которое указывает tsup генерировать файлы объявлений.

outDir - это выходной каталог для скомпилированного кода.

clean указывает tsup очистить выходной каталог перед сборкой.

6.3: Изменение сценария сборки

Теперь мы будем запускать tsup для компиляции нашего кода вместо tsc.

6.4: Добавьте поле exports

Добавьте поле exports экспорта в package.json со следующим содержимым:

Поле exports сообщает программам, использующим ваш пакет, как найти версии вашего пакета CJS и ESM. В этом случае мы указываем пользователям, использующим импорт, на dist/index.js, а пользователям, использующим require, — на dist/index.cjs.

Также рекомендуется добавить ./package.json в поле экспорта. Это связано с тем, что некоторым инструментам необходим легкий доступ к вашему файлу package.json.

6.5: Пробуем еще раз проверить экспорт

Запустите следующую команду, чтобы проверить правильность всех экспортов из вашего пакета:

Теперь все зеленое:

6.6: Превращаем TypeScript в линтер

Мы больше не используем tsc для компиляции нашего кода. Но tsup на самом деле не проверяет наш код на наличие ошибок — он просто превращает его в JavaScript.

Это означает, что наш сценарий ci не выдаст ошибку, если в нашем коде есть ошибки TypeScript.

Давайте это исправим.

6.6.1: Добавляем noEmit в tsconfig.json.

6.6.2. Удаляем неиспользуемые поля из tsconfig.json.

Удалите следующие поля из вашего tsconfig.json:

outDir

rootDir

sourceMap

declaration

declarationMap

Они больше не нужны в нашей новой настройке «линтинга».

6.6.3: Изменение module на «Preserve»

При желании теперь вы можете изменить module на Preserve в вашем tsconfig.json:

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

6.6.4: Добавление lint скрипта

Добавьте скрипт lint в свой package.json со следующим содержимым:

Это запустит TypeScript в качестве линтера.

6.6.5: Добавьте lint в ваш ci-скрипт

Добавьте сценарий lint в сценарий ci в package.json:

Теперь мы будем получать ошибки TypeScript как часть нашего процесса CI.

В этом разделе мы установим vitest, создадим тест, настроим скрипт test, запустим его, настроим скрипт dev и добавим test скрипт в наш CI-скрипт.

vitest — это современный инструмент для запуска тестов для ESM и TypeScript. Это как Jest, но лучше.

7.1: Установка vitest

Запустите следующую команду для установки vitest:

7.2: Создаем тест

Создайте файл src/utils.test.ts со следующим содержимым:

Это простой тест, который проверяет, возвращает ли функция hello правильное значение.

7.3: Настройка скрипта test

Добавьте скрипт test в package.json со следующим содержимым:

vitest run запускает все тесты в вашем проекте один раз, без просмотра.

7.4: Запускаем test скрипт

Выполните следующую команду, чтобы запустить тесты:

Вы должны увидеть следующий вывод: