flowtyped - грабилка dts из ts

причем довольно глупая

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

Я думаю, что описание интерфейса либы, которую ты используешь, дело не такое уж и затратное

Хотя хз конечно

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

Бывает. Иногда даже приходится несколько дней потратить на мучения.

Тем более, что это скорее всего редкий кейс

имхо, с TS нужно будет заморочиться в начале, зато потом сплошной профит

в целом флоу отлавливает больше ошибок и требует меньше исправлений кода

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

Ну дарт это все же другой язык совсем

да но результат на выходе один, это js. как и у TS в общем то)

ну если такими критериям мерять, то куча альтернатив

scala.js, elm, purescript

gwt

emscripten

Typescript имеет свои рантайм-конструкции, но спроектирован чтобы мапиться на js

Флоу добавляет только синтаксис типов

Dart - это отдельный язык, но изначально спроектирован под компиляцию в js в том числе

Алсо, кто пишет сервак на TS - такой вопрос: хочу потрогать руками тайпскрипт в последнее время, есть у ts что-то похожее на babel-node? Гугл намекает на https://github.com/TypeStrong/ts-node - это норм вариант? Или лучше прикурутить что-то типа вебпака с вотчером, что бы он мне все каждый раз при изменениях пересобирал и скалдывал в папочку build, и перезапускал потом?

лучше вотчер я думаю

я обычно запускаю tsc -w и просто работаю как с обычным js

я обычно запускаю tsc -w и просто работаю как с обычным js

типа tsc -w nodemon ./build/app.js ?

tsc -w, остальное не нужно (ну и supervisor/nodemon и т.п.)

типа того

Окс, спасибо, попробую

Что использовать для запуска node на продакшне?

мы юзаем https://github.com/foreverjs/forever

В смысле для демонизации на продакшне.

мы юзаем https://github.com/foreverjs/forever

Многие с умным видом говорят, что nodemon и forever для продакшна — некошерно.

и правы

Я отчасти догадываюсь, почему, но хотелось бы услышать осмысленные аргументы.

Ибо сам только начал разбираться в вопросе.

и правы

Почему?

много мелочей

например, нет graceful restart по умолчанию

pm2/инит скрипты

docker

Ну внутри докера что-то же должно запускать процесс, правильно?

Ну внутри докера что-то же должно запускать процесс, правильно?

+

нет

Ну внутри докера что-то же должно запускать процесс, правильно?

shebang

или sh + su-exec

супервайзер не нужен

как вариант чтобы права убить

и заменить процесс под pid

но да, в докере процесс под pid 1 пока живой - жив контейнер

@bigslycat Не надо forever в продакшне.

как вариант чтобы права убить

Планируется использование докера. Так что, с правами всё ок.

Планируется использование докера. Так что, с правами всё ок.

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

да ну, внутри докера то че

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

Какие могут быть дыры в данной ситуации? Докер не видит хост-систему, и этого достаточно. Если сам процесс будет скопрометирован, страшно не то, что он может записать что-то в том, а то, что у него есть доступ к БД. А это правами не предотвратишь.

Если вы запихаете ваше приложение в forever — что будет, когда упадёт forever?

Какие могут быть дыры в данной ситуации? Докер не видит хост-систему, и этого достаточно. Если сам процесс будет скопрометирован, страшно не то, что он может записать что-то в том, а то, что у него есть доступ к БД. А это правами не предотвратишь.

volume, 0-day уязвимости в докере

Ну так то любой супервизор может упасть

Аналогично с pm2 — сам по себе он задачу перезапуска не решает, насколько я знаю.

Здесь докер и берёт на себя сложность по части безопасности в контексте системы. Отчасти для этого он и создан.

Там куча issue висит у него.

@vkurchatkin Упасть-то да. Но по-хорошему они должны быть построены вверх до ядра и аппаратного таймера.

Там куча issue висит у него.

РЕчь о докере или о pm2?

О pm2

https://github.com/Unitech/pm2/issues?q=is%3Aissue+is%3Aopen+crash

Ну баги есть везде

ERROR: S client not available

Что ж теперь

@vkurchatkin Эта проблема решается цепочкой, которая восходит до аппаратного таймера.

То бишь, хотите сказать, что самый надёжный способ — демонизация средствами гостевой системы?

А так — да, баги есть везде.

Ммм, ну вот кто перезапустить штатный супервизор?

upstart какой нибудь

Если upstart умрёт?

ну да

Система перегрузиться должна.

Не знаю, хотя, как с конкретно с апстартом.

Он слегка умер, впрочем.

http://0pointer.de/blog/projects/watchdog.html — вот это советую прочитать. Аналогичное должно быть в других системах.

Там, кстати, рассмотрено, что происходит когда дохнет init или ядро.

Да и это довольно маловероятно, а вот oom и померший пользовательский вачдог, за которым никто не следит — лично наблюдал.

само собой

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

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

Это да. Да и внешний мониторинг покажет, если что-то померло.

По поводу upstart — даже в Ubuntu Server LTS уже systemd.

да вот буквально сегодня. упало все 8 инстансов приложения. крутились через pm2

pm2 вел себя вооьще не адекватно

постоянно делал spawn себя

думаю перейти на systemd или че там модно после upstart

Может проблема была в приложении?)

/stat@comstatbot

.

А кто-нибудь использует в наше время json-rpc?

Да

@abc а почему не используете кластеризацию nodejs ?

потому что она упирается в то что утилизируется одно ядро и очень грустно становится работать. 1 ядро > 4 и дальше по-моему не растет особо.

да нет, сколько ядер, столько и растет