Трек времени добавить думаю.
Насчет неймспейсов пока не уверен. Если они вам нужны и нравится как оно работает в debug, то почему бы не использовать debug в качестве логгера более никого уровня вместе с class-logger?
// logger.service.ts
import debug from 'debug'
export const loggerNamespaceA = debug('NamespaceA')
export const loggerNamespaceB = debug('NamespaceB')
...
// cats.service.ts
import { LogClass } from 'class-logger'
import { loggerNamespaceA } from './logger.service'
@LogClass({
log: loggerNamespaceA,
logError: loggerNamespaceA
})
class CatsService {}
Сериализованная ошибка включает в себя следующие свойства:
— Имя класса (функции), которая была использована для создания ошибки (error.constructor.name).
— Код (error.code).
— Сообщение (error.message).
— Имя (error.name).
— Стек трейс (error.stack).
reflect-metadata здесь peer зависимость. По идее можно использовать предложенную вами альтернативу при желании. АПИ у них вроде совместимый.
Из плюсов reflect-metadata — он уже включён в angular. На стороне же NodeJS размер модуля вообще значения не имеет.
Не очень понятно как это будет работать для того же речь сервера на NodeJS.
Зачастую просто трейса не хватает. Видно, что пришел undefined, но чтобы понять почему пришел undefined, а не ожидаемый объект, зачастую, надо знать как данные менялись в ключевых моментах обработки запроса.
С помощью декоратора Log мы явно помечаем какие именно методы должны быть залоггированы. Никто не обязывает логгировать все, как вы подметили это имеет мало смысла.
Как вы будете использовать отладчик с продакшне? Для того, чтобы понять, что поломалась и при каких условиях, надо какие-то основные моменты жизни того же хттп запроса залоггировать. Эта библиотека призвана сделать именно это. Только вместо того, чтобы писать каждый раз ручками само сообщение, позаботившись о правильном форматировании и сериализации, вы можете делегировать это class-logger
2. Все наемные работники имеют потолок. Большой плюс IT в том, потенциально, ваше рабочее место — весь земной шарик.
5. Прошу прощения, но как у вас уживаются 1С и английский? Это вещи параллельные. Почему многие не любят 1С? потому что это искуственно созданная платформа одной компании, к которой вы болтами привязываетесь. Я не говорю, что аргумент в пользу того, что вы во время работы с 1С прокачиваете свои знания бизнес-процессов, не валиден, но надо понимать, что это имеет большую цену: вы полностью теряете мобильность и ораничиваете себя только той страной, где распространена 1С.
Идея здоровская. Хотелось как раз отделить новости и основных статей. А можно сделать то же самое с email рассылками? В идеале, я бы хотел иметь две разные рассылки: публикации и новости, и настраивать их частоту независимо.
Позвольте немного поворчать: чем больше данных, тем, обычно, больше их дисперсия, так что далеко не факт, что эти 18мб будут расти линейно.
А в целом, интересная штука. Надо потыкать :)
Нам видимо либо разные соотрудники попадались, либо вы летаете намного чаще. Я летаю раза 3-4 в год туда-обратно по России и заграницу. Опыт примерно такой же как и у balexa.
1. На бенчмарки можно тут посмотреть github.com/nodejs/benchmarking/issues/181 и решить для себя насколько оно критично. Как по мне иметь возможность адекватной трассировки важнее.
2. Зависит от того, что у вас за прод. Меня, как любителя смузи и всего модного-стильного-молодежного, это не смутило и поюзать уже успел, но и компания была вполне себе хипстерская, а не кровавый энтерпрайз.
При вашем подходе экшны более не сериализуемы. Т.е. вам более не смогут прислать пачку экшнов с продавцом, вы у себя сделаете риплей и восстановите стейт.
Второй момент: мне не очень понятно как с таким подходом вы разбиваете стейт на более маленькие кусочки. Учитывая, что вы предлагаете выкинуть combineReducers, получается каждый экшн должен обрабатывать весь стейт целиком?
Да, вы правы. Плюсанул. unionize лучше выбора по ключу как минимум в плане типизации.
В случае классов с декораторами мы можем добиться не худшей типизации если на один экшн приходится один редьюсер и мы используем классы для экшнов. В статье я не стал описывать этот функционал, дабы не ее совсем не раздуло, но в библиотеке он есть.
Посмотрите на пример. В частности, на метод addEnergy. Экшн по которому выолнится редьюсер заинферится из типа.
Трек времени добавить думаю.
Насчет неймспейсов пока не уверен. Если они вам нужны и нравится как оно работает в debug, то почему бы не использовать debug в качестве логгера более никого уровня вместе с class-logger?
github.com/keenondrums/class-logger#formatting
Логгрование ошибок есть.
Дык особо ничего и не поменяется. Просто будем свои навелосепедированные символы в property descriptor добавлять :)
reflect-metadata здесь peer зависимость. По идее можно использовать предложенную вами альтернативу при желании. АПИ у них вроде совместимый.
Из плюсов reflect-metadata — он уже включён в angular. На стороне же NodeJS размер модуля вообще значения не имеет.
Не очень понятно как это будет работать для того же речь сервера на NodeJS.
Зачастую просто трейса не хватает. Видно, что пришел undefined, но чтобы понять почему пришел undefined, а не ожидаемый объект, зачастую, надо знать как данные менялись в ключевых моментах обработки запроса.
С помощью декоратора Log мы явно помечаем какие именно методы должны быть залоггированы. Никто не обязывает логгировать все, как вы подметили это имеет мало смысла.
Как вы будете использовать отладчик с продакшне? Для того, чтобы понять, что поломалась и при каких условиях, надо какие-то основные моменты жизни того же хттп запроса залоггировать. Эта библиотека призвана сделать именно это. Только вместо того, чтобы писать каждый раз ручками само сообщение, позаботившись о правильном форматировании и сериализации, вы можете делегировать это class-logger
5. Прошу прощения, но как у вас уживаются 1С и английский? Это вещи параллельные. Почему многие не любят 1С? потому что это искуственно созданная платформа одной компании, к которой вы болтами привязываетесь. Я не говорю, что аргумент в пользу того, что вы во время работы с 1С прокачиваете свои знания бизнес-процессов, не валиден, но надо понимать, что это имеет большую цену: вы полностью теряете мобильность и ораничиваете себя только той страной, где распространена 1С.
Позвольте немного поворчать: чем больше данных, тем, обычно, больше их дисперсия, так что далеко не факт, что эти 18мб будут расти линейно.
А в целом, интересная штука. Надо потыкать :)
А где вас по 10-30 минут мурыжат-то? Пройти через рамку — пару минут, поставить печати — вообще секундное дело. Все остальное время сжирают очереди.
2. Зависит от того, что у вас за прод. Меня, как любителя смузи и всего модного-стильного-молодежного, это не смутило и поюзать уже успел, но и компания была вполне себе хипстерская, а не кровавый энтерпрайз.
Я обеими руками за opentracing, но не очень вижу как оно решает проблему создания trace ID автоматом.
Все это для того, чтобы заменить Thread-local storage.
Рекомендую взглянуть на его развитие https://github.com/alexnm/re-ducks
При вашем подходе экшны более не сериализуемы. Т.е. вам более не смогут прислать пачку экшнов с продавцом, вы у себя сделаете риплей и восстановите стейт.
Второй момент: мне не очень понятно как с таким подходом вы разбиваете стейт на более маленькие кусочки. Учитывая, что вы предлагаете выкинуть combineReducers, получается каждый экшн должен обрабатывать весь стейт целиком?
Да, вы правы. Плюсанул. unionize лучше выбора по ключу как минимум в плане типизации.
В случае классов с декораторами мы можем добиться не худшей типизации если на один экшн приходится один редьюсер и мы используем классы для экшнов. В статье я не стал описывать этот функционал, дабы не ее совсем не раздуло, но в библиотеке он есть.
Посмотрите на пример. В частности, на метод
addEnergy. Экшн по которому выолнится редьюсер заинферится из типа.