(да я в курсе .valueOf)

не включать strictNullChecks )) зачем тогда типы вообще.

да я согласен со всем выше сказанным)
просто в том же дефолтном проекте на NestJS и на ангуляре по дефолту strict отключен.

И многие люди берут фреймворк, CLI-ой создали его, и просто педалят бизнес логику, а злой волк скрывается в нюансах, как всегда)

а потом приходим мы.. группа экстренного реагирования типа “Валера спасай” и начинаем лопатой это все откапывать 😄

Почему? Можно же в буфер загнать, потом опустошить, коминтнуть, продолжить и т.д.

Потому что у тебя может быть  node.js cluster то есть несколько child процессов будут писать в один файл и соответственно будут проблемы, когда они одновременно будут коммитать разные данные

Семафоры? как вариант

Семафоры могут дать сбой при достаточно интенсивном лоаде. Проще и надежнее отдать это на откуп БД, да и чтение с выборкой проще тогда будет. А если это еще у тебя, как у меня ранается в контейнере, то при его падении ты теряешь свои файлики. Тут все равно надо какое-то внешнее хранилище подключать.

возможно!

Вообще у тебя могут быть проблемы с файлом, даже в рамках одного node процесса, например при вызове Promise.all на записи/чтении. Потому что на уровне OS есть ограничения на количество открытых файловых дескрипторов. Соответственно те потоки из node.js threadpool , которые не шмогли 😄 , получат ошибку OS filesystem, напр. ENOENT, и соответственно часть данных будет утеряна. Спасут ли тут Семафоры? Не думаю 😄 Не все можно решить только программно, иногда инфраструктурные решения лучше.

@tshemsedinov Тимур, добрый день!
Спасибо, вам большое за видео "Байки про JavaScript и Node.js с Тимуром Шемсединовым".
Для меня особенно ценно сравнение Node.js с другими серверными технологиями.
В данном видео вы частично коснулись данного вопроса.
В виду того что в "интернете" практически нет конкретных примеров и разборов конкретных ситуаций, ваш опыт поэтому поводу звучит бесценным.
Было бы здорово если бы на своем канале или еще где разобрали и привели примеры конкретных сценариев где нода луче или хуже других технологий.
Я думаю это сильно поможет новичкам в Node.js, они будут больше ее "уважать". Возможно это также поможет архитекторам, при выборе лучшего решения для бизнеса.
Я задавался данным вопросом 2 года назад. Прочитал кучу статей, и ничего конкретного не нашел.
Раньше я думал, что преимущество Node.js в том, что на фронте и на бэке один язык, но изучив архитектуру бекендов, прочитав Фаулера "шаблоны корпоративных приложений" я пришел к выводу, что фронт и бек настолько разные, что преимущество единого языка сходит на нет.
Сейчас у меня предвзятое отношение к Node.js, я считаю его костыльным, хотя делаю бэкенд на нем.
Так, например, в ноде нет встроенного механизма DI, нужно пользоваться костылем в виду Inversify хотя, глядя на Spring у меня глаза радуются насколько он там классно сделан.
Я конечно не профессионал, опыт ноды у меня 1 год +.
Но после того как в видео я услышал конкретный кейс с "Поддержанием 2 млн соединений за счет libuv", у меня появилось больше интереса и уважения к ноде.
Было бы здорово услышать от вас или комьюнити, вот такие конкретные кейсы с примерами где нода лучше, хуже и почему.
Например, насколько я знаю, в Java есть асинхронность, чем она луче, хуже Node.js (libuv)?
Java сможет на том же сервере поддерживать 2 млн соединений?
Я слышал от джавистов что асинхронность сложно дебажить , поэтому они выбирают синхронность, интересно узнать ваше мнение по этому поводу.
Я понимаю что нужно разделать фреймворки, языки, подходы.
Но тем не мене интересно ваш анализ Node.js vs ...
Спасибо!

@tshemsedinov Здравствуйте, посоветовали дубль сюда.

Вероятно здесь нужно каждую задачу в отдельности рассматривать. Что касается падения контейнеров, в данном и в других подобных случаях вероятно нужно рассматривать почему он падает и это частично касается задачи доставки. В общем в данном случае можно решить это точкой восстановления с пред. разрыва. А если данных много, их необходимо передавать порционно.
От сбоев вообще никто не застрахован, что нодовскими методами что какими-то другими.

Я не хочу никому ничего доказывать. Через почти все эти кейсы я уже прошел, набил шишек и сразу предложил уже финальное наиболее оптимальное решение основанные на опыте и преодоленных трудностях. Если у тебя есть желание создать собственное  решение и набить свои шишки, а не доверять готовому, милости прошу 😜

Ну не совсем так, я поэтому и спрашиваю. Если есть где подробней об этом почитать, дайте пожалуйста ссылочку :)
Вы, кстати, не пишете в блог о своих решениях?

Отвечу в течении нескольких дней

Спасибо, я ответа не жду) . Просто хотел спасибо, и было бы здорово услышать примеры в каких задачах node.js хорош.

Сорян, все решения в основном project specific, потому под NDA. Но могу посоветовать вот что! Если ты пишешь back-end, то на задачу часто нужно смотреть шире, выйти не просто за рамки js, но даже за рамки программирования. И например посмотреть на свой проект глазами DevOps/SRE/SecOps специалистов. Это реально расширяет кругозор и проект и подходы сразу начинаеют выглядеть иначе. Еще используй готовые cloud SaaS решения вместо велосипедов, там столько всего есть, если разобраться, что готовые решения прикроют минимум 75% того, что думал сам делать с нуля.

Пример.
Взгляд дева - Я пишу идеальный код, который никогда не крашится (многие в этом чате думают о себе именно так 😂), пакую его в контейнер и запускаю.

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

👍 Эх, эти NDA... Линус Торвальдс вас осуждает где-то в глубинах души )) Мда, сам сейчас под NDA, но как-то не оч. комфортно себя в этой пижаме чувствую. Может еще не привык.

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

Все очень сложно