Что тебе мешает импортировать класс, который за тебя инициирует логер?

Импорт происходит только один раз

В рамках одного пакета, пстественно

Так мне надо контекст таскать не в зависимости от того, где он импортируется, а в зависимости от запроса

let debug = require('debug')('main'); debug('blah blah') - будет иметь префикс main в логах

где надо подключаешь и пользуешься

let debug = require('debug')('main'); debug('blah blah') - будет иметь префикс main в логах

Хм, возьму на вооружение

с ватсоном тоже самое можно сделать

/stat@combot

мне просто эта субьективно удобней

айди запроса можно генерить в начале всего через мидлвер и потом его всегда использовать

https://solidgeargroup.com/express-logging-global-unique-request-identificator-nodejs

нечто такое нужно?

combot.org/chat/-1001041204341

combot.org/chat/-1001041204341

/stat@combot

combot.org/chat/-1001041204341

Да ну ёлки, не то же ? Если на пальцах, то хочется вот так: function setIdMW(req, res, next) { req.__id = randomId(); next(); } router.post('/users', (req, res, next) => { const {__id} = req; logger.debug(`${__id}: calling /users with arguments: ...`); // (1) const newUser = UserModel.createUser(req.body); // (2) res.json(newUser); next(); }); Комменты: Специально использую тупой прямой подход с логгером и формированием строчки вручную, чтобы всё прямо в примере было. 1 - типа что-то мы здесь логгируем. Важно, что в экспрессе - тут всегда есть где взять контекст - req, res на выбор 2 - a вот сюда я тоже хочу прокинуть логгер, потому что процесс создания пользователя может быть дофига сложным и я там тоже что-то хочу логгировать понимая, в каком именно запросе, с какими параметрами, всё это произошло. Самый прямой путь решить 2 - это const newUser = UserModel.createUser(req.body, __id);

Вот

Посмотри в сторону CLS https://www.npmjs.com/package/continuation-local-storage Но если используются промисы с a/a - оно работать не будет. В этом случае стоит посмотреть на форк https://www.npmjs.com/package/cls-hooked, который базируется на экспериментальном (!) api ноды async_hooks

Ко второму пакету написан хороший дисклеймер, стоит почитать и проникнуться. Или нет)

Посмотри в сторону CLS https://www.npmjs.com/package/continuation-local-storage Но если используются промисы с a/a - оно работать не будет. В этом случае стоит посмотреть на форк https://www.npmjs.com/package/cls-hooked, который базируется на экспериментальном (!) api ноды async_hooks

Забористая штука. В прод я её конечно не потащу, но спасибо ?

блэт а курсы с itvdn можно как нить сохранить? или сливы есть у кого нибудь?

до 11 числа врядли успею

блэт а курсы с itvdn можно как нить сохранить? или сливы есть у кого нибудь?

да

там до 14 вроде

у меня до 11

Там реализацию JWT от циски сломали, видели?

Там реализацию JWT от циски сломали, видели?

Неа, а можно линку?

https://www.npmjs.com/package/node-jose

Бага в том, что оно слепо доверяет самоподписанным JWT (это если коротко).

0.11.0 пофикшен, новая версия обратно несовместима со старой, так что сама обновлением не прилетит.

(я уже говорил, что JWT — кусок говна?)

Самоподписанные — не в смысле none, а те, у которых публичный ключ в хедере.

Линка: https://twitter.com/FiloSottile/status/949237064998047744

jwt не нужен

причем в обеих расшифровках аббривиатуры

есть же https://github.com/paragonie/past

paragonie кстати молодец, посмотрю-ка что там.

правда я его еще не использовал

причем в обеих расшифровках аббривиатуры

А какая вторая?

и вроде имплементация только для пхп есть

есть же https://github.com/paragonie/past

Я первый раз вижу, за ссылку спасибо.

paragonie кстати молодец, посмотрю-ка что там.

Но он там по пхп больше, если что.

Емнип он в пхп рнг починил.

и вроде имплементация только для пхп есть

> PAST: Platform-Agnostic Security Tokens

што

А какая вторая?

java web toolkit

Хех, ну тут очевидно

Посмотрел на PAST. Там нету адских говен как в JWT, но нужности это ему не прибавляет, кмк.

Кстати

https://twitter.com/WayneVaughan/status/949116358356172800

> PAST: Platform-Agnostic Security Tokens

И как тебе?

Оттуда же: https://twitter.com/dshaw/status/949117187670724608

И как тебе?

я не понимаю как они платформ-агностик с реализацией только на похапе. как-то так

дальше не читал

у них же есть документ с описанием работы протокола

https://github.com/paragonie/past/tree/master/docs

Оттуда же: https://twitter.com/dshaw/status/949117187670724608

а сам толк есть?

ERROR: S client not available

а, это ж прямо сейчас

а, это ж прямо сейчас

Есть прошлогодняя версия слайдов только: https://speakerdeck.com/rdegges/jwts-suck-and-are-stupid

Добрый вечер

Кто подскажет чат с верстальщиками?

@css_ru

Спасибо большое

всем привет, кто может помочь с js проектом ? помогу криптой

чо делать-то?

есть на visio js плагин один который надо допилить под мою нужду, чтобы не спамить в личку

кто пишет тесты к микросервисам ?

допустим мне нужно протестировать два микросервиса. Первый спрашивает что-то у второго. Вы бы заводили отдельный нпм пакет с тестами, который их запускает?

или в таком случае, это "папочка" с интеграционными тестами внутри первого пакета

если нужно проверить io микросервиса - куда бы вы разместили сами тесты

допустим мне нужно протестировать два микросервиса. Первый спрашивает что-то у второго. Вы бы заводили отдельный нпм пакет с тестами, который их запускает?

Хм, а это идея

если нужно проверить io микросервиса - куда бы вы разместили сами тесты

Тесты — определенно рядом с самими модулями сервисов, в ./TESTS/*.test.js

Это для юнит-тестов Более глобальные тесты можно выносить отдельно, если требуется

смотри, сервис Б запрашивает А, Если я хочу протестировать что сервис Б правильно запросил А и записал что-то в лог. Такой тест в отдельном пакете ?

который честно запускает их как node.js процессы

тогда сложность - придётся придумать коммуникацию между модулем Б, что бы заставить его сделать запрос по внешим причинам и модулем интеграционного тестирования

в обратном случает, если тесты Б разместить в Б/тесты/ - мне нужны тайпинги и параметра инициализации сервиса А - что повлечёт зависимость сервиса Б на уровне нпм пакетов от сервиса А

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

ну не кучу, ладно - пару файлов

просто - так мозг запутается, чё-где

Интересный вопрос

вот уже, что бы проверить гет/пост запросы к веб-серверу, мне приходится выность логику формирования запросов из фронтенда в отдельный пакет - для шаринга между пакетами "веб-сервер/тест" и "фронтенд"

В принципе интеграция микросервисов вместе — это тоже микросервис, в предельном случае один общий условный our_platform в качестве ещё одного пакета и тестирование интеграции можно класть там же

хм.. тогда надо всё io выносить в пакеты

вебсокеты так же