Подскажите, пожалуйста, а EventEmitter'ами нодовскими в реальной разработке еще пользуются? А то я как-то потерялся за всем этим засильем библиотек и в гугле тоже внятных ответов не нашел

Да.

Ок, спасибо. Значит буду применять со спокойной совестью )

Вообще была идея использовать ивенты для вызова контроллеров в самописном сервере. Роутер находит нужный ивент, выбрасывает его, нужный контроллер подхватывает ивент, ну и т.д.
Опять же, роутер сможет выбрасывать несколько ивентов, контроллеры тоже могут перебрасываться событиями для обработки доп.данных и так далее.

Как по вашему, имеет ли такая идея право на жизнь и, возможно, кто-нибудь подскажет, что почитать по теме.

Нiт

почему?

я правда был бы благодарен за немного более развернутый ответ, хотя бы ссылки на статьи, где объясняются эти принципы.
мне гугл выдает ответы в стиле "используйте экспресс" или очень базовые туториалы.

Я думаю мейнова причина в тому що він не для цього призначений. Ти можеш в контролерах емітити івенти для сторонніх ефектів.

Плюс хай мене поправить @tshemsedinov, але коли в тебе на сервер приходить реквест навколо нього створюється свій наскрізний контекст, який буде втрачено якщо ти будеш користуватись івент емітером

судя по всему я совсем нуб в ноде )
просто мне казалось, что выбросить ивент вроде "запусти процесс получения профиля" это вполне логичный подход

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

@ManulTheCat посмотрите по ивентэмиттерам тут https://youtu.be/LK2jveAnRNg и по тому, как сделать маршрутизацию тут https://youtu.be/7Ufxj0oTaUo

В первом приближении я как раз и хотел делать все на событиях. Прочитаю обязательно, спасибо )

але емітер односторонній, куди має повернутись твій "отриманий профіль"?
можна викинути івент що профіль отримано, але вот не задача, хто ж має його прийняти?)
як ти розрізниш до якого реквеста він прийде?
можна створювати унікальні ідентифікатори для кожної конструкції реквест-емітер, але знов задача, як ти зрозумієш що всі твою івенти повернутись і тобі потрібно віддати респонс для юзера?

Ничего страшного, можно сделать, например, class Client { request, response, socket, session, cookies, data и т.д. } и передавать его в ('EventName', clientInstance) это и будет контекстом, в который вернется ответ, но построить стройную и понятную структуру приложения на событиях значительно сложнее, чем на коллекциях маршрутов или на вызовах.

можно бросать ивент о том что обработка завершена. Это, кмк, самый правильный подход. Можно "по простому" сделать в классе, унаследованном от эмиттера, метод ответственный за прием результата. Мне этот подход не очень нравится, но теоретически может сработать.

Естественно, роутер должен знать сколько и чего он вызвал и трекать, все ли ивенты отработали

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

різниці в перформенсі респонсів не буде? порівняно з звичайний підходом?

Производительность будет даже лучше, но будет много проблем от событиев, практически не имеющих нормального решения:
- отсутствие стектрейсов
- перемешивание последовательности событий
- как это все отлаживать

Это меня тоже беспокоит.
А еще то, что скорее всего придется организовывать цепочки по типу "пока не вернулся ответ от модуля аутентификации, грузить ответственные части страницы не нужно"