Об альтернативах Express, где и почему стоит отказаться от Express'a и небольшие замеры в переводе под катом
Express
Express – простой, хорошо документированный, отлично поддерживаемый и наиболее скачиваемый фреймворк для Node.js
Если вы попробуете загуглить как сделать простейший HTTP сервер, то вам, скорей всего, первым запросом выдаст примерно такой код:
const server = require('express')({})
server.get('/', (req, res) => {
res.send('Hello World!')
});
server.listen(3000);
REST APIs
В архитектуре приложений, которые разрабатываются компаниями, REST API и REST сервисы продолжают играть фундаментальную роль, так как HTTP до сих пор используется как основной протокол для коммуникации. Это значит, что программист, который собирается сделать новое приложение или микро-сервис, воспользуется REST API вместо, например, “очереди событий”.
С наступлением популярности использования микро-сервисов, REST API стремится к тому, что бы быть максимально маленьким и выполнять минимальное количество операций. Это влечет в себе то, что число конечных пунктов в разрабатываемом API будет возрастать прямо-пропорционально количеству микро-сервисов и для каждого простого действия будет своя конечная точка. Например, для того чтобы изменить данные пользователя в базе данных, сначала будет вызван метод /user/search для того, чтобы найти ID нужного нам пользователя, а уже затем будет вызван метод /user/update с указанием параметра возвращенного нам до этого ID, вместо того, чтобы выполнить эту операцию(Прим. Ред.).
Да, REST API должны быть быстрыми, необходимо чтобы они были быстрыми!Так же, при создании высоконагруженного приложения с использованием REST API, все чаще пользуются паттерном микро-сервисов. Такие приложения строятся на API Gateways. API Gateway – это, по сути, прокси сервер, к которому обращается пользователь, а этот прокси сервер уже обращается к наименее загруженному микро-сервису. Обычно API Gateway также решает небольшие задачи, такие как:
- Обработка SSL сертификатов
- Распределение нагрузки
- Авторизация и аутентификация
- Кэширование
- Сжатие контента запроса
- ...
Однако, Express слишком тяжелый и медленный
Express великолепен, насыщен возможностями…, но он так же тяжелый и медленный для использования в небольших целях, как например REST API в микро-сервисы
Последняя версия библиотеки(4.16.4) зависит от 30 модулей, которые в нее встроены, а в процессе разработки к этим модулем добавляется ещё около 20, что в итоге делает приложение слишком тяжелым для использования как микро-сервиса.
В сравнении с другими библиотеками, Express слишком медленный для использования в минимальных целях, когда не нужно выполнять сложные запросы. График снизу показывает сравнение выполнения простейшего запроса на получение JSON документа.
Замеры, которые показаны на последней картинке, не показывают, что Express медленный в общем, они показывают, что вам нужно удвоить производительность вашего процессора ради того, что бы выполнять простейшие операции… В следствие этого увеличиться месячный платеж за пользования AWS, Google Cloud, MS Azure или другого облачного сервиса, которым вы пользуетесь, а это перейдет в больший и зачастую необоснованный расход средств.
Заключение
В Node.js есть много различных способов реализации REST API, ниже перечислены которые подойдут для вас, в зависимости от задачи:
Комментарии (12)
SirEdvin
02.01.2019 09:52+10А вы пробовали взять реальный проект и реально померять оверхед express.js на запрос? Ну там: "вот мой проект, реальный оверхед на запрос 1% от всего времени выполнения".
Как вы уже достали со своими бенчмарками на "отдать простой json", правда. У кого-то есть хоть одного реальное приложение, которое так работает?
IvanT
02.01.2019 10:44+415 тысяч запросов в секунду это 0.06 миллисекунды на один запрос. Бизнес-логика приложения, запросы в базу, апи микросервисов и прочее работает куда дольше в типичном не оптимизированном под высокие нагрузки приложении. По сути никакой разницы 0.06 мс у Express или 0.03 мс Fastify не будет учитывая, что всё остальное будет занимать условно 20 — 500 мс. Где же тут медлительность именно фремворка?
IvanT
02.01.2019 11:02Посмотрел оригинал статьи — там автор в комментариях на такой же вопрос отвечает, что действительно на фоне бизнес-логики это не существенно. Кстати, restana это библиотека автора статьи. Потому она и выделена в тестах.
gnaeus
02.01.2019 11:03+1Мне тоже казалось, что тема микробенчмарков веб фреймворков давно закрыта techempower. И если посмотреть на тесты где хоть как-то участвует база данных, то получится, что отказ от express даст нам выигрыш в пределах 10%. Ну и стоило оно того?
rudinandrey
02.01.2019 15:26если у Вас допустим миллион пользователей, и на каждые 100 000 пользователей у Вас стоит отдельный сервер. То цена этих 10% есть стоимость отдельного сервера. Вот и подумайте, стоит ли оно того?
springimport
02.01.2019 18:16+2Как всегда, если бы. В реальности доля проектов где это становится важным вряд ли больше 1%.
И да, в 2019 легче добавить сервер чем добавлять костыли ради непонятной выгоды.kalyukdo
02.01.2019 21:57а где вы видите костыли? просто заменив одну либу другой получаем прирост в производительности, вы хотяб открыли доку, да посмотрели, а то как в той фразе: «Не смотрел, но осуждаю»
napa3um
«Конечных пунктов» -> «входных точек»
shushu
На самом деле это сложный вопрос, как перевести это. Лично я не знаю однозначного варианта, но думаю что именно здесь будет уместно «шлюз»
napa3um
Это именно входные точки (точки входа) в терминах REST — по сути, отдельные урлы. А шлюзы — это уже об сетевой инфраструктуре, а не REST. Это уже сложившаяся терминология, а перевод «пункт» вообще надмозговый получился.