А что мешает сделать внешнюю ссылку в других фреймворках?

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

Это никак не связано с экспрессом

> @NordLuf Я обьяснял как может быть меньше одного байта утечки на один запрос и это не как не объясняет <1 байта

<1 байта можно объяснять только логикой, которая выполняет действия реже чем 1 раз на запрос, причем сильно реже

в экспрессе нет такой логики

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

Да ну роутер написать дело получаса.

> @klond90 Да ну роутер написать дело получаса в общем то его можно и не писать, а просто юзать регэкспы

<1 байта можно объяснять только логикой, которая выполняет действия реже чем 1 раз на запрос, причем сильно реже

Либо, что какая-то структура заполняется и опустощается чанками, и на 1000, например, запросов остается повисшим указатель на 10 байт, остальные части структуры удаляются

да, но в экспрессе ничего такого нет

ОК

Да скорее всего проблема либо в самой ноде была (в одной из версий реально помню что то вытекало сразу на том же коде) либо в логике.

Свет вырубили в доме, видимо имеет смысл спать...

да, но в экспрессе ничего такого нет

И в прошлых версиях, из которых еще не повыдергивали модули, тоже не было? Речь то про несколько лет назад

нет

ОК

Погуглил бенчмарки, у всех коа слегка обгоняет экспресс таки

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

В экспрессе нельзя сделать конвейерную обработку запросов потому что express отбрасывает значения middleware-функции и вот такое без патча экспресса сделать не получится //log requests middlewares.push(async(next, req, res) => { console.log('request start:', req.method, req.url); var response = await next(); console.log('request send:', response); res.end(JSON.stringify(response)); console.log('request end:', req.method, req.url); }); //catch errors middlewares.push(async(req, res, next) => { try { return await next(); } catch (e) { console.log('error:', e); res.status(400); return {error: e.message}; } }); middlerawe.push(staticServer) //connect to database middlewares.push(async(next, req, res) => { req.db = await new DB(schema); req.data = {}; try { return await next(); } catch (err) { await req.db.disconnect(); throw err; } }); middlerawe.push(cookieParser) middlewares.push(getCurrentUserOrCreateGuest) middlerawe.push(bodyParser) //map request info to crud operation middlewares.push(async(next, req, res) => { var [table, id] = req.url.split('/').slice(1); var dbActions = { "GET": 'get', "POST": 'add', "PUT": 'update', "DELETE": 'delete' }; req.data.action = dbActions[req.method]; req.data.table = table; req.data.id = id; return await next(); }); //process request in database middlewares.push(async(next, req, res) => { var {table, id, action} = req.data; if(!table) throw new Error('no table'); var index = req.query.index; var body = req.body; if (action == 'get') { return await req.db.get(table, id, {index}) } if (action == 'add') { return await req.db.add(table, body) } if (action == 'update') { return await req.db.update(table, id, body) } if (action == 'delete') { return await req.db.delete(table, id) } });

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

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

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

Через req же можно вроде

Кладешь в req промис и ловишь его после next

чет пиздец ты там написал в коде

В поле req точнее, как в контекст

довольно странная трабла

Ну, именно. Все middleware в express работают над заполнением req/res. Обработка ошибок чуть отдельно. Всё.

делай поиск по пустому селектору в монге, где 0 записей - все норм стоит к курсору, который возвращает поиск, применить сортировку, и он мне выдает следующее

А stack ошибки где?

Кладешь в req промис и ловишь его после next

с асинками такое не пройдет потому что они как раз возвращают промис который отбрасывается экспрессом

А stack ошибки где?

что-то я давно не ловил трейсы у промисов

ща продебажу

с асинками такое не пройдет потому что они как раз возвращают промис который отбрасывается экспрессом

Пишется некоторый враппер над контроллерами. То же самое, как обмазывать express промисами.

ща продебажу

Промисы нативные или bluebird, например?

Я как-то спрашивал про инструмент для отслеживания используемых версий пакетов и смотреть Change Log по мере того, как будут новые релизы. Сейчас нашёл такой инструмент: https://david-dm.org/expressjs/express

Промисы нативные или bluebird, например?

нативные

ща апдейтну ноду

с асинками такое не пройдет потому что они как раз возвращают промис который отбрасывается экспрессом

Разве нельзя сделать в вызвваемом мидлваре req.res = new Promise... А в ввзывающем req.res.then?

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

Почему же трешак? Идет обработка запроса в отдельных миддлварах каждый из которых отвечает за свою область. Один логирует, второй обрабатывает ошибки, третий парсит боди, чертвертый будет валидировать данные и потом уже запрос попадает в базу данных после которого еще одна миддлварка будет фильтровать данные для отдачи юзеру. В чем же треш? Я просто объеденил их для наглядности в одном файле

Почему же трешак? Идет обработка запроса в отдельных миддлварах каждый из которых отвечает за свою область. Один логирует, второй обрабатывает ошибки, третий парсит боди, чертвертый будет валидировать данные и потом уже запрос попадает в базу данных после которого еще одна миддлварка будет фильтровать данные для отдачи юзеру. В чем же треш? Я просто объеденил их для наглядности в одном файле

Как раз в этом объединении и проблема. static и DB в одной цепочке - зачем? Туда же куки и остальное.

мидлвари не для этого

они строго для работы с http

Промисы нативные или bluebird, например?

юзаю, если что, node-mongodb-native

Разве нельзя сделать в вызвваемом мидлваре req.res = new Promise... А в ввзывающем req.res.then?

через чистые промисы да, все можно а вот если через async-await то app.use(async (req,res,next)=>{ console.log('start'); await next() console.log('end') })не получится потому что async возращает промис который отбрасывается экспрессом

А при чем тут асинк? мы же про экспресс говорим или там асинки поддерживать стали?

юзаю, если что, node-mongodb-native

Такого не трогал. В общем, нужен stack trace и тогда будет проще понять, что и где. Подпиши process на unhandledRejection, там можно будет найти.

Такого не трогал. В общем, нужен stack trace и тогда будет проще понять, что и где. Подпиши process на unhandledRejection, там можно будет найти.

подписан

не ловит

Я как-то спрашивал про инструмент для отслеживания используемых версий пакетов и смотреть Change Log по мере того, как будут новые релизы. Сейчас нашёл такой инструмент: https://david-dm.org/expressjs/express

Ну ты быстрый

Как раз в этом объединении и проблема. static и DB в одной цепочке - зачем? Туда же куки и остальное.

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

через чистые промисы да, все можно а вот если через async-await то app.use(async (req,res,next)=>{ console.log('start'); await next() console.log('end') })не получится потому что async возращает промис который отбрасывается экспрессом

Чистые промисы тоже не получится сразу. Поэтому я и сказал про враппер. Но без патчинга самого express. async не пробовал ещё прикрутить, ради интереса потом напишу.

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

Фильтровать надо на уровне роутов, а не вызывая кучу бесполезных (для данного uri) мидлварей.

А при чем тут асинк? мы же про экспресс говорим или там асинки поддерживать стали?

поддержка асинков как раз и заключается в том чтобы не отбрасывать значения миддлваров, вот в моем пуллреквесте я исправил эту проблему экспресса и он волшебным образом стал поддерживать асинки https://github.com/expressjs/express/pull/3138 но только его не приняли(

Фильтровать надо на уровне роутов, а не вызывая кучу бесполезных (для данного uri) мидлварей.

так они и не вызываются, запрос просто сразу обрабатывается и не проходит дальше по конвееру

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

По сути, идеальная схема роутинга - это конфиг с перечислением отношений роут - список middleware. Где-то куки нужны, где-то raw-body, где-то passport, например. Где-то пучок всего. Но это не на каждый проект годится, естественно.

короче забил на ошибку, заюзал сортировку по массиву

А я про такой код говорил: const express = require('express') const app = express() app.use((req, res, next) => { next() req.pr.then(x => console.log(x)) }) app.get('/', (req, res) => { req.pr = Promise.resolve(1) res.send('Hello World!') }) app.listen(3000)

так они и не вызываются, запрос просто сразу обрабатывается и не проходит дальше по конвееру

Каждый раз дёргается staticServer, файла нет - идём в БД. Так что ли? Кстати, зачем там каждый раз connect и disconnect? Что за хранилище, пула нет?

Каждый раз дёргается staticServer, файла нет - идём в БД. Так что ли? Кстати, зачем там каждый раз connect и disconnect? Что за хранилище, пула нет?

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

А я про такой код говорил: const express = require('express') const app = express() app.use((req, res, next) => { next() req.pr.then(x => console.log(x)) }) app.get('/', (req, res) => { req.pr = Promise.resolve(1) res.send('Hello World!') }) app.listen(3000)

req.pr.then(x => console.log(x)) В это строчке начинается "толстота". Есдиный output для всех роутов. Это клёво, если всегда json, например. Но надо ещё и про catch не забыть и прочее.

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

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

Я про обратный пример спрашивал - на каждый запрос к БД идёт обработка через static-server. И это был риторический вопрос) В том плане, что плохо так делать. Имхо, конечно же)

Я про обратный пример спрашивал - на каждый запрос к БД идёт обработка через static-server. И это был риторический вопрос) В том плане, что плохо так делать. Имхо, конечно же)

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

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

Что подразумевается под фильтром запросов? По мне так это роутингом решается. /api/ - динамика, /public/ - статика, и т.д.

ERROR: S client not available

Сам профит от такого конвеерного подхода заключаетя в наглядности схемы обаботки любого запроса. Не нужна куча роутов (кроме некоторых исключений) не нужно на каждую таблицу делать отдельные контроллеры, если придерживаемся стандартной rest-схемы - GET | POST | PUT | DELETE /api/{table}/{id} то достаточно всего одной миддлварки чтобы обработать абсолютно все crud запросы в базе данных (правда не нужно забывать про валидацию в миддлварке перед ней) без создания кучи болерплейта

А, ну я так и написал. crud можно описать одним контроллером по /api/*, если так хочется. Остальное - отдельные хендлеры со своими мидлварами.

Т.е. показанная в примере вертикаль - в целом клёво, но не для сетапа всего express-приложения.

У коа нагляднее код

Что подразумевается под фильтром запросов? По мне так это роутингом решается. /api/ - динамика, /public/ - статика, и т.д.

зависит от приложения, у меня например еще происходит фильтрация для spa через переопределения роутов на index.html но в целом миддлварка примерно такая async function staticServer(req, res, next){ if (req.url.slice(1, 4) !== 'api' && (req.method == 'HEAD' || req.method == 'GET')) { if(req.headers && typeof req.headers.accept === 'string' && req.headers.accept.indexOf('application/json') !== 0 && (req.headers.accept.indexOf('text/html') !== -1 || req.headers.accept.indexOf('*!/!*') !== -1) && urlUtil.parse(req.url).pathname.indexOf('.') === -1)){ console.log('override path to'); req.url = '/'; } // отдача файла .... } else { await next() } }

зависит от приложения, у меня например еще происходит фильтрация для spa через переопределения роутов на index.html но в целом миддлварка примерно такая async function staticServer(req, res, next){ if (req.url.slice(1, 4) !== 'api' && (req.method == 'HEAD' || req.method == 'GET')) { if(req.headers && typeof req.headers.accept === 'string' && req.headers.accept.indexOf('application/json') !== 0 && (req.headers.accept.indexOf('text/html') !== -1 || req.headers.accept.indexOf('*!/!*') !== -1) && urlUtil.parse(req.url).pathname.indexOf('.') === -1)){ console.log('override path to'); req.url = '/'; } // отдача файла .... } else { await next() } }

Ну да, есть такая штука. У меня чуть иначе написано. Но только для dev подключается такой middleware. В production этим nginx занимается.

Ну да, есть такая штука. У меня чуть иначе написано. Но только для dev подключается такой middleware. В production этим nginx занимается.

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

А нода http2 уже нормально поддерживает?

А нода http2 уже нормально поддерживает?

А зачем?

Для снижения нагрузки например, коннект то один на сессию

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

Нода сильно медленнее на статике. Особенно, жирной статике

Для снижения нагрузки например, коннект то один на сессию

Нагрузки на что?

А ну да, nginx то к ноде все равно будет несколько коннектов делать...

А ну да, nginx то к ноде все равно будет несколько коннектов делать...

Нет, зачем http2?

Ну и nginx удобно использовать если у тебя десяток серверов кластер и надо запросы раскидать

Нет, зачем http2?

Например гуглобот вроде как предпочитает http2 обычному в раздаче рейтингов.

Ну и nginx удобно использовать если у тебя десяток серверов кластер и надо запросы раскидать

Лучше балансер поставить нормальный

Лучше балансер поставить нормальный

Возможно, но nginx как балансер с возможностью логгирования всех запросов неплохо работает

И статистику удобно в stub выдает

Возможно, но nginx как балансер с возможностью логгирования всех запросов неплохо работает

На проде никто не включает аксесс логи

На проде никто не включает аксесс логи

У нас включены, по ним метрики в графите строятся через collectd tail

Оох

Нужно знать скольлко было 200 ответов, сколько 499, сколько 5xx

После этого логи можно удалять.

Хотя часто приходится в них лезть и искать конкретный запрос в пределах пары часов.

Нужно знать скольлко было 200 ответов, сколько 499, сколько 5xx

Для этого логи не нужны

В целях каких нибудь проверок логики.

Собственно логи хранятся только за 6 часов вроде, это как раз около 100Гб.

А или не, это сутки 100Гб были, потом укоротили.

https://github.com/dominictarr/JSONStream крутая штука)

А в одном проекте логи из nginx вообще клиентам выгружались.