во время обсуждения доклада "Node.js Middleware – никогда больше!" ты говорил про "огромные проекты написанные только на эвент эмиттерах", считая такое анти-паттерном.

а в чем проблема такого подхода? сложно понять где куда что кому передается?

Невозможно проследить связи модулей и управлять зацеплением кода. Все превращается в большой ком грязи (это антипаттерн так называется)

спасибо

Я думал вы автор этого канала. Сори

А кто-то может подсказать или скинуть пример простого конфига для вебпак, чтобы свою библиотеку собрать под ноду? Чтобы зависимости не тянуло.

В релизе будут схемы и таски?

Да, таски будут, а вот схемы буду в составе metasql, я не успею перенести их последнюю реализацию в metaschema. Это не совсем верное место для схем. Сейчас они используются для генерации бд, но не для валидации и не для описания контрактов. Я по универсальным схемам собрался все делать: работу с бд, структурами данных в памяти и протоколом, описание контрактов внутри кода и внешних интерфейсов, генерацию .d.ts и документации, валидацию и проверку структуры конфигов, тестирование, чтоб можно было включать проверку для отладки и отключать местами в продакшенее.

А для чого вам вебпак для ноди

Ой лучше не спрашивайте ) Мне надо код в один протектор запихать, короче руками все пока собрал. Потому придумаю, что-нибудь.

)))

господа, такой вот нубский вопрос. Для записи логов в базу данных, что лучше использовать в качестве уникального ключа? какой-нибудь циферный id, или uuid? uuid вроде практичнее... Но я не знаю, вдруг числовой айдишник где-то будет полезнее? (хотя в голову такая ситуация не приходит. По-идее искать необходимо будет по дате и пользователю, который совершил действие)

а в какую базу вы логи пишете? реляционная или нет?

в реляционную. postgres

ой мне кажется плохо ему будет от большого количества логов ) вот насобираете вы логи за год, и на втором году все будет тормозить уже. минус числа в том что если вы возьмете тип integer то сможете записать только 2147483647 записей, bigint - получше, 9223372036854775807

ну вот по идее uuid избавит от этой проблемы с числами. А так они не будут там храниться слишком долго

по крайней мере больше года так точно. Там актуальость информации будет быстро теряться...

Проблема с числами при таком подходе - явно не та, о которой следует задуматься в первую очередь. Скорее всего все упадет гораздо раньше, чем счетчик дойдет до 2147483647

Если логи только писать - то лучше уж в файл какой-то да и всё. Если еще вы их планируете читать и делать какие-то запросы, то чтобы оно работало понадобятся индексы. Индексы на большие таблицы - дело затратное как по памяти, так и по остальным ресурсам. Просядет перформанс на запись, постгресовский вакум тоже будет кушать больше ресурсов чем надо. Ну и плюс сами запросы на получение логов будут хотеть кушать.
Будь то логи только каких-то критических ошибок, то ладно. Но я подозреваю там будут всякие дебаг логи тоже по типу "Здесь был Вася".
Поэтому лучше все это дело:
а) Писать в стдаут
б) Натравливать на стдаут какой-нибудь процессор логов, который их будет переправлять дальше в базу
в) базу нужно явно отдельную от основной приложухи и желательно либо time-series, либо колоночную (можно на отдельный постгрес timescaledb наинсталить)

Ну и опицонально:
г) логи, старше 1 недели удалять из базы предварительно задампив их в файлик и закинув куда-то далеко в облака, например в с3 или ему подобное.

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