а в деве проще было 1 дев-сервер поднимать

а 2 babel-core/register не уживаются вместе

уже просто babel-register

а еще плюс, кстати

можно не тащить dev-dependencies с собой

точнее не делать дев зависимости продакшн-зависимостями

А как вы докерами пользуетесь? Поднимаете свой hub/registry, как он там называется?

я просто попытался себе поднять на выходных как раз, там вообще веб-интрфейса нет? Чтобы хоть посмотреть, что ты напушил себе

Heroku нетащит

?

можно не тащить dev-dependencies с собой

Heroku не тащит. Он устанавливает только dependencies

NODE_ENV=produciton npm i вроде тоже?

это понятно. Но если у тебя есть require-hook у тебя продакшн-зависимостью становится babel

npm i —production. Хотя все варианты пойдут)

С чего вдругпродакшн ? :)

а с чего вдруг нет?

babel-register зависимость?

А как вы его используете?

Использовали раньше для анализа потребления памяти. Потом перешли на pm2 и необходимость в heapdump отпала. В коде он реквайрился. Выяснили, что он работает под шестеркой после переустановки и убрали его )

Интересно, как в Docker его прикрутить?

я же писал, запускать не как демон

Но зачем?

Коллеги, чем нынче можно логи писать? winston/bunyan или другое?

console.log

Этого хватает всегда?

я юзаю modern-syslog

я юзаю modern-syslog

Посмотрю.

А вот еще вопрос. Что логируете?

Используете разные уровни в разном окружении?

ошибки, действия иногда запросы к db

Bunyan

Я выше скидывал фрагменты изоморфного кода)

Во, Денис плохого наверное не посоветует) А почему не Winston?

JSON

Мне изоморфик для логирования пока не нужен.

Кстати, да.

Понадобится :)

ELK можно прикрутить или аналог

Любое

У нас елка :) но можно хоть opbeat

Ты, кстати, помнится писал по этому поводу. Что в итоге выбрал?

ELK

Ну я только влез в это.

Ок

Больше кейсов)

Меньше риски

До того хватало направленного вывода debug/console.log в файлы.

Больше кейсов)

Сделали бота?

Ждем пока ты научишься

И поможешь

И прославишься?

@DenisIzmaylov а для чего конкретно вы бота хотите написать?

https://github.com/StartupMakers/telegram-reactjs-bot

@DenisIzmaylov а для чего конкретно вы бота хотите написать?

Вот для этого всего: Welcome message and brief for new users Silent-mode to avoid "flood" Reposts from React.js and Relay blogs Retweets 3 times per days - last tweets from Dan Abramov and React.js Team 1 times per day - short React.js digest? Watch for MoscowJS meetups Statistic and metrics for admins Highlight code as Inline Bot Digest from related Gitter rooms (chat-ua/reactjs, chat-rooms/reactjs, etc)

3 твита от дэна))

вот это мощно))

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

Давай, молодцом

Мне кажется ты мощно сделаешь

Парни, как лучше подписи запросов реализовать в высоконагруженной системе - Redis или криптография (aes-256)?

jwt?

посути jwt не формат токенов, а формат подписи. Там в payload, вроде, неограниченное кол-во данных можно положить

а как относятся редис и симметричная криптография к подписи (ассиметричная криптография)?

https://mrajacse.files.wordpress.com/2012/01/applied-cryptography-2nd-ed-b-schneier.pdf

вот нормальная копия: https://skydrive.live.com/view.aspx?resid=FACF17652686C5B3!157&cid=facf17652686c5b3&app=WordPdf&wdo=2

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

а как относятся редис и симметричная криптография к подписи (ассиметричная криптография)?

Валидность

Валидность чего? :)

Вообще можешь положить данные прямо в локалсторадж и подписать их

Подделать без компрометации ключа не выйдет

Только локалсторадж на клиенте похерить

ключи нельзя хранить в базе, только хеши, если что

Ключ = хэш

в смысле ты должен хэши сранивать, а не сами данные

чтобы если редиску скопроментируют, тебе ключ не смогли подсунуть

Вряд ли, он да - можно и такой слой добавить)

в смысле врядли? еще пароли plain-text храни))

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

Аллё, какие хэши, тут про подпись

Изучите теорию

Подписи запросов :)

был тут блог интересный на эту тему

http://appsandsecurity.blogspot.com/2011/04/rest-and-stateless-session-ids.html

Подписи запросов :)

для чего подписи то конкретно нужны?

Если на более высоком уровне задача такая - защитить данные поисковой выдачи от crawling насколько это возможно. Вижу решение такое - с результатами на первой странице, подставляем в пагинатор подпись (например &token=FoMPCRErjGnQNVmZ615JIuTcQ55FQZAD6A5dYdRFePqBypItDrUtu0) для следующего запроса, в ответ на который прийдут данные с новым ключом. В пагинаторе обновляем ключ на полученный. Таким образом, мы можем контролировать RPS цепочки.

ну это не подпись

это csrf crumb

для этих наверное в редисе проще всего хранить и выдавать

убивать когда реквест с crumb пришел, или после экспайра

CSRF немного про другое, но близко, да)

можно заморочится наверное и модные алгоритмы с хешированием таймстемпа замутить :)

Задача не от CS, а в целом от краулинга

Хорошая идея на самом деле :)

https://github.com/koajs/stateless-csrf

Это в кластере :)

будет