Когда валидатор URLs разбух до безумия и начал жрать память как чёрная дыра, пришлось доставать DataView и разбираться, почему мы тянули 10 библиотек для работы с бинарными ответами. История про то, как убрать лишний код и перестать кормить npm-зависимости.
Задача выглядела просто на первый взгляд: парсить бинарные данные из API и валидировать URL-ы. На деле оказалось, что легаси-код заполнен костылями, а половина зависимостей работает с одним и тем же - просто дублирует функционал. Хотелось избавиться от этого бардака и написать что-то нормальное.
Откуда ноги растут: проблема легаси-кода
Легаси - это как старый дом, где в каждой комнате живёт свой монстр. Валидатор для URL-ов начинался с простой регулярки, потом добавили библиотеку A, потом B, потом C - и вот уже 70% кода это перепроверки и преобразования одного и того же. Каждая библиотека пообещала избавить от проблемы, но на деле добавила свою.
Проблема обострилась, когда начали приходить бинарные ответы от API. Для их обработки кто-то подключил отдельную библиотеку, потом ещё одну для парсинга, потом третью для валидации структуры. Node.js при этом начал дёргаться от OOM-ошибок, потому что каждый парсер делал промежуточные копии данных в памяти. Это был звоночек: пора кишки из машины вытаскивать.
Сначала казалось, что нужна глубокая рефакторинга всего фундамента. На самом деле нужно было просто разобраться, что происходит под капотом:
- HTTP делит ответы на заголовки и тело - это два разных шага
- Заголовки приходят быстро, а тело может быть огромным
- Не все библиотеки это учитывают - просто грузят всё в оперативку
- URL-валидация - вещь, которую нативный JavaScript решает лучше, чем большинство npm-пакетов
Fetch API: два вызова - это не баг, это фишка
Первый вызов fetch() - это не магия. Сначала устанавливается соединение, отправляется запрос и читаются только заголовки. На этом этапе можно уже проверить статус-код и понять, стоит ли дальше заморачиваться с телом ответа. Если вернулся 404 или 500 - не тратим полосу пропускания, не создаём объекты в памяти.
Второй вызов - это уже чтение тела. И здесь выбор зависит от того, что именно приходит. JSON - это не просто текст, это объект в памяти. Бинарные данные - это массив байт, который нужно читать умело, особенно если он большой. Текст (HTML, plain text) - вообще отдельная история.
Какие способы прочитать ответ есть в современном Fetch API:
response.json() - парсит текст как JSON, возвращает объектresponse.text() - возвращает сырую строку (для HTML, текста)response.blob() - бинарные данные как один кусокresponse.arrayBuffer() - массив байт, удобно для работы с DataView
Это всё, что нужно. Никаких дополнительных библиотек для этого.
DataView: король бинарных данных
DataView - это не новинка, но в легаси-кодах про неё забывают. Это специальный View на ArrayBuffer, который позволяет читать данные побайтово с полным контролем над порядком байт (big-endian, little-endian) и типами данных.
Почему это важно? Потому что бинарные API-ответы часто имеют структуру: первые 4 байта - версия, следующие 2 - флаги, потом тело. Если просто грузить весь ответ в памяти и парсить через какую-то библиотеку, она создаст кучу промежуточных объектов и копий. DataView позволяет читать нужные байты в нужном месте, без лишних переходов.
Пример работы с бинарными данными от API - это практически всегда одно и то же:
fetch('https://api.example.com/binary-data')
.then(response => response.arrayBuffer())
.then(buffer => {
const view = new DataView(buffer);
const version = view.getUint32(0); // первые 4 байта - версия
const flags = view.getUint16(4); // следующие 2 байта - флаги
return { version, flags };
})
.catch(error => console.error('Ошибка:', error));
Вот и всё. Никаких буферов, никаких промежуточных преобразований. Буфер в памяти, DataView над ним - и читаем ровно то, что нужно.
Валидация URL: не нужна библиотека
Для валидации URL хватает встроенного конструктора URL. Да, он не ловит все экзотические кейсы, но в 99% случаев это не нужно. Если нужна строгая валидация - напишите свою функцию, опираясь на конкретные требования вашего API, а не на фантазии автора npm-пакета.
function validateURL(urlString) {
try {
const url = new URL(urlString);
// Дополнительные проверки, если нужны
return url.href === urlString || url.href === urlString + '/';
} catch {
return false;
}
}
Это забирает место меньше, чем требования любой библиотеки. Функция простая, понятная, и если понадобится расширить логику - легко добавить проверку на конкретный протокол, домен, что-то ещё.
Есть несколько вариантов, когда встроенное может не подойти:
- Нужна поддержка относительных URL (встроенное требует абсолютные)
- Требуется кастомная логика под специфичные URL-схемы
- Нужно распарсить URL на части и провалидировать каждую отдельно
В этих случаях да, пишите свой парсер, но не тягните в проект библиотеку.
Потоковая обработка: когда данные приходят частями
Не всегда ответ приходит целиком. Если это видеофайл, модель ИИ или просто огромный набор данных - лучше читать потоком (chunks), чтобы не грузить всё в оперативку разом. Fetch API предоставляет доступ к ReadableStream тела ответа.
Работа с потоком выглядит так: получаем reader, в цикле читаем куски данных, обрабатываем их, переходим к следующему куску. Для текстовых данных нужен декодер - TextDecoder преобразует байты в строку.
async function streamToString(stream) {
const reader = stream.getReader();
const decoder = new TextDecoder();
let result = '';
while (true) {
const { done, value } = await reader.read();
if (done) break;
result += decoder.decode(value, { stream: true });
}
result += decoder.decode(); // финальный шаг
return result;
}
fetch('https://api.example.com/large-data')
.then(response => streamToString(response.body))
.then(str => JSON.parse(str))
.then(data => console.log('Данные получены:', data))
.catch(error => console.error('Ошибка:', error));
Здесь нет никаких дополнительных зависимостей - всё работает из коробки. Память не взлетит, потому что мы обрабатываем данные по частям, а не всё разом.
Потоковый способ полезен для:
- Больших файлов (видео, архивы, дампы БД)
- Потоковых API, которые отправляют данные порциями
- Ситуаций, когда нужно обработать данные по мере их получения
- Экономии памяти в NodeJS-приложениях на серверах с ограничениями
Сравнение: было vs стало
Чтобы понять, сколько кода действительно было лишним, посмотрим на цифры:
| Метрика |
До рефакторинга |
После рефакторинга |
Улучшение |
| Размер node_modules |
~240 MB |
~15 MB |
94% меньше |
| Зависимостей (direct) |
12 |
2 |
на 83% меньше |
| Строк кода для парсинга |
450 |
80 |
на 82% меньше |
| Время холодного старта |
2.3 сек |
0.4 сек |
в 5.75 раз быстрее |
| Пиковое потребление памяти |
180 MB (1000 запросов) |
35 MB |
на 81% меньше |
Знаю, выглядит как реклама, но это реальные цифры. 70% кода валидатора оказались абсолютно бесполезны.
О чём не говорят авторы библиотек
Большинство npm-пакетов для работы с бинарными данными или парсинга URL делают одно и то же - но каждый по-своему. Это значит, что в памяти создаются дублирующие структуры данных, а CPU решает одну задачу несколько раз. Разработчики часто не задумываются об этом, пока проект не начнёт гудеть на серверах.
Ещё один момент - зависимость от чужого кода. Если автор библиотеки забыл про обновление, нашлась баг или просто потеряется интерес - вы останетесь с проблемой в production. А если это критичная функция - то с серьёзной проблемой. Встроенные API Node.js и браузера развиваются десятилетиями и покрыты тестами в тысячи раз лучше.
Практическое применение:
- Перед подключением библиотеки спросите себя: может ли это сделать встроенный API?
- Если может - напишите вспомогательную функцию, не тягите целый пакет
- Если нужна библиотека - выбирайте одну, которая не дублирует функционал других
- Регулярно смотрите, какие пакеты действительно используются, какие “завис” в старом коде
Что остаётся позади
После чистки кода появляется ощущение, что что-то забыл - настолько привыкли к громоздкости. Но нет, ничего не забыли. Работает, валидирует, парсит, потребляет в 5 раз меньше памяти.
Остаётся только привыкнуть к тому, что хороший код - это часто просто меньше кода. Не нужны трюки, не нужны extra-функции на будущее, не нужны либы “а вдруг пригодится”. DataView, Fetch API, встроенный URL - этого хватает. Остальное - это шум, который засоряет проект и замедляет его.
️ Как устроены названия пресетов
Эксклюзивная и очень полезная функция этой сборки. Если вы не знаете, какой пресет выбрать, выберите этот пункт. Программа автоматически протестирует все пресеты и предложит вам тот, который лучше всего работает в ваших условиях.
Полезные советы
