Задача выглядела просто на первый взгляд: парсить бинарные данные из 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 стало

Чтобы понять, сколько кода действительно было лишним, посмотрим на цифры:

Знаю, выглядит как реклама, но это реальные цифры. 70% кода валидатора оказались абсолютно бесполезны.

О чём не говорят авторы библиотек

Большинство npm-пакетов для работы с бинарными данными или парсинга URL делают одно и то же - но каждый по-своему. Это значит, что в памяти создаются дублирующие структуры данных, а CPU решает одну задачу несколько раз. Разработчики часто не задумываются об этом, пока проект не начнёт гудеть на серверах.

Ещё один момент - зависимость от чужого кода. Если автор библиотеки забыл про обновление, нашлась баг или просто потеряется интерес - вы останетесь с проблемой в production. А если это критичная функция - то с серьёзной проблемой. Встроенные API Node.js и браузера развиваются десятилетиями и покрыты тестами в тысячи раз лучше.

Практическое применение:

• Перед подключением библиотеки спросите себя: может ли это сделать встроенный API?
• Если может - напишите вспомогательную функцию, не тягите целый пакет
• Если нужна библиотека - выбирайте одну, которая не дублирует функционал других
• Регулярно смотрите, какие пакеты действительно используются, какие “завис” в старом коде

Что остаётся позади

После чистки кода появляется ощущение, что что-то забыл - настолько привыкли к громоздкости. Но нет, ничего не забыли. Работает, валидирует, парсит, потребляет в 5 раз меньше памяти.

Остаётся только привыкнуть к тому, что хороший код - это часто просто меньше кода. Не нужны трюки, не нужны extra-функции на будущее, не нужны либы “а вдруг пригодится”. DataView, Fetch API, встроенный URL - этого хватает. Остальное - это шум, который засоряет проект и замедляет его.