Легковесный модуль для HTTP запросов

[Altox]

Спасибо, поправил :)

[BuriK666]

Об ошибках нужно писать в личку… т.к. после исправления статьи, ваш комментарий становится неактуальным.

[ShpuntiK]

Каждую неделю на протяжении лет 4-5 вижу одну и ту же ситуацию: кто-то пишет в комментарии об опечатке в статье, ему ставят минусы, он начинает писать что-то типа «Ой-ой, за что минусы то? Вот беда то...». Новые сообщения только ещё минусов наберут. Просто не пишите в следующий раз в личку и всё.

[ssbb]

А чем стандартный http не устроил, если так важна производительность?

[corvette]

Если код на гитхабе посмотреть, то всем устроил. Автор немножко припудрил сахаром http и https, как по мне, так довольно мило получилось.

[Altox]

Громоздкостью использования.

[northicewind]

Так как же теперь с потреблением памяти? Без заключительного абзаца неясно стоила ли овчинка выделки. Желательно с цифрами. Спасибо.

[Altox]

Потребление памяти уменьшилось ( еще сильнее оно уменьшилось при использовании ручной сборки мусора )

Сейчас провел маленький тест — 300 запросов на habrahabr.ru
Вот числа:

Request — { rss: 71733248, heapTotal: 57203968, heapUsed: 25940592 }
tiny_request — { rss: 46379008, heapTotal: 47928576, heapUsed: 11682480 }

[MaxFactor]

#Нихренасе# потребление 47-57 метров 300 запросов?

[keksmen]

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

[aparamonov]

Посмотрите в сторону functional programming (например rxjs), чтобы избавиться от бойлерплейта 'if (!err && response.statusCode == 200) {'
Я бы предпочел видеть API в таком виде:

req
  .post(...)
  .onOk((body, response) -> console.log(body))
  .onStatus(404, () -> ...)

[Kinday]

Знаете про superagent?

[aparamonov]

Нет, я больше по Scala-стеку. :)

[AndyGrom]

А кто-то предпочёл бы увидеть следующее:
req.post(...).then(...)

[VasilioRuzanni]

А кто-то и подавно

let response = await req.post(...);

if (response.statusCode === 404) {
  ...
}

console.log(response.body);

...

:)

[inook]

co + promises

[VasilioRuzanni]

Именно их и использовал долгое время, но они все равно создают лишний шум в коде, так что теперь babel «es7.asyncFunctions» + promises — наше все.

[hell0w0rd]

bluebird.coroutine быстрее ;)

[Yavanosta]

А чем не понравился, например, got?

[Altox]

> Dependencies (13)

Слишком много всего для такого функционала, я думаю.

[b1rdex]

Зачем писать в 2015 без Promise API? Возьмите node-fetch.

[MaxFactor]

А вы думаете, что будущее за Promise API? Мое мнение, что нет и даже не за асинхронной архитектурой. Недавно было интересно тестануть nodejs на потребление памяти при постоянной нагрузки, и честно говоря классическая связка php/nginx — выигрывает в разы по производительности и по потреблению памяти. Nodejs использую только как commit-server не более того.

PS: было бы хорошо если бы кто-нибуть написал статью со статистикой потребления памяти при нагрузках с использованием разных сервисов (http,https,ssh и т.д.)

[b1rdex]

Если php+nginx выигрывает в разы, то вы что-то делаете не так. Априори, пересоздаваемое окружение на каждый запрос вместе с блокировкой ввода-вывода будет медленнее, чем горячая точка входа и неблокирующее I/O. Ну а асинхронная архитектура имеет и плюсы, и минусы. Например, в том же сравнении php+nginx и node.js (если использовать везде 1 процесс) node.js будет быстрее, так как не будет блокировки из-за I/O.

[b1rdex]

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

[MarcusAurelius]

1. Делать err третьим параметром в callback, мягко говоря, не принято. Лучше ставить параметры в порядке убывания их важности и частоты использования: callback(err, response, body). Тут даже response важнее body, потому, что к response.statusCode точно обратятся, а к body только условно. Но это уже не так критично, главное err поставьте первым.
2. Тип ответа JSON можно не задавать, а определять по Content-Type: application/json или application/javascript (если поддерживать JSONP). А функции для парса данных разных типов можно примешивать к response. Например, так выглядит компактнее:

req.get('http://test.com/json, function(err, res) {
  if (!err && res.statusCode === 200) {
    // можем брать res.asJSON()
    // можем брать res.asBuffer() или res.asString()
  }
});

3. Иметь параметры для всего именованные параметры хорошо, но альтернативно задавать все в URL намного компактнее:
Вместо: req.get({ url: 'http://test.com', query: { test: 'test' }, port: 8080}, callback);
Делать: req.get('http://test.com:8080?test=test', callback);
Да и часто все это у нас уже есть в виде одной строки URL, а тут ее парсить и потом Вы ее опять склеите же.