Cheslav
в вебпаке пути настроить с определенной папки
Cheslav
алиасы
сomorsiс
кстати, а в джс/тс есть package-private модули?
Таймураз
есть какие-нибудь солюшены хорошие чтобы избежать импортов ../../../../?
process.env.NODE_PATH = __dirname; require('module').Module._initPaths();
Таймураз
есть какие-нибудь солюшены хорошие чтобы избежать импортов ../../../../?
В начале каждого родительского модуля
Alexander
Привет ребят! немного не в тему вопрос. Хочу купить стикеры на ноутбук на IT тематику (лого компаний, языков программирования, технологий) везде берут за наклейку по 1.5$ и выше, хотя на али можно 50 шт за такие деньги взять, но на али не нашёл таких. Мб кто видел либо покупал?
Anonymous
Когда этого самого выбора у тебя нет, например.
Т.е. если к тебе придёт энтерпрайз - ты напишешь на Java, если нужно будет MVP солюшн- напишешь на nodejs ? (Если нужна будет асинхронность)
Таймураз
Т.е. если к тебе придёт энтерпрайз - ты напишешь на Java, если нужно будет MVP солюшн- напишешь на nodejs ? (Если нужна будет асинхронность)
Заебешься с асинхронностью на джаве. Локать треды и тд
Алексей
Привет, в одном из чатов недавно был задан вопрос: “чем nodejs лучше Java?” Я привёл следующий аргумент:
«Java - много запросов = много потоков
Nodejs - много запросов = один поток»
На что получил возражение:
«— кто же мешает делать пулинг ._.»
После чего возник ряд вопросов:
1) Пулинг всмысле пулинг потоков ? Для чего ? Каждый поток ведь - дополнительная оперативная память (ну и плюс переключение контекстов)
2) А разве не смысл node.js в том что асинхронное программирование на нём проще ? Чем делать пулы, заниматься thread менеджментом и т.д. ?
Помогите пожалуйста разобраться с этими вопросами?
Если очень много запросов, то им придётся ждать освобождения потока из пулла и они просто могут начать отваливаться по таймауту.
Рубикон
есть какие-нибудь солюшены хорошие чтобы избежать импортов ../../../../?
Можно настроить babeljs
arts
Т.е. если к тебе придёт энтерпрайз - ты напишешь на Java, если нужно будет MVP солюшн- напишешь на nodejs ? (Если нужна будет асинхронность)
Если ко мне придёт энтерпрайз, я десять раз подумаю, стоит ли с ним связываться.
Igor
бабел, думаю, более опимальный путь
Энлов Свичблейд
где-то в интернетах есть гист на эту тему
есть Бабель плагин который определяет рут проекта через ~
Алексей
на джаве тоже можно писать асинхронно
Можно, но не удобно из-за отсутствия async/await. Да и api подавляющего числа библиотек синхронно.
Igor
https://github.com/entwicklerstube/babel-plugin-root-import
Alexander
Если очень много запросов, то им придётся ждать освобождения потока из пулла и они просто могут начать отваливаться по таймауту.
ЕМНИП, в ноде асинхронность тоже отчасти зависит от потоков, только у user-space кода нет доступа к ним, они только на стороне ноды. соответственно, там так же могут начать отваливаться запросы по таймауту
Alexander
но огромный плюс ноды тут в том, что не нужно об этих потоках думать, это удел самой ноды, а не моего кода)
Dmitrii
игрался кто нибудь с этим? https://moleculer.services
Алексей
ЕМНИП, в ноде асинхронность тоже отчасти зависит от потоков, только у user-space кода нет доступа к ним, они только на стороне ноды. соответственно, там так же могут начать отваливаться запросы по таймауту
По моему нет. У ОС (и Windows, и Linux) есть асинхронное апи для работы с сокетами, что уже в принципе даёт true асинхронность при работе с сетью по крайней мере.
Alexander
По моему нет. У ОС (и Windows, и Linux) есть асинхронное апи для работы с сокетами, что уже в принципе даёт true асинхронность при работе с сетью по крайней мере.
это да, для многих действий есть родная асинхронность, но в доках ноды было сказано, что нода может запускать отдельные потоки, если у либы, с которой работаешь, нет асинхронного апи
Дима
libuv нодовский многопоточен, если мне не изменяет память
Алексей
это да, для многих действий есть родная асинхронность, но в доках ноды было сказано, что нода может запускать отдельные потоки, если у либы, с которой работаешь, нет асинхронного апи
Ну для некоторых задач наверное да, но именно сетевой стек критичен, так как на него идёт основная нагрузка при большом количестве подключений.
Alexander
но в целом, для подавляющего числа задач ноды асинхронное апи таки есть)
Дима
По крайнней мере IO
Alexander
Ну для некоторых задач наверное да, но именно сетевой стек критичен, так как на него идёт основная нагрузка при большом количестве подключений.
не всегда сетевой стек оказывается бутылочным горлышком. им может оказаться какое-то тяжелое вычисление, например
Алексей
не всегда сетевой стек оказывается бутылочным горлышком. им может оказаться какое-то тяжелое вычисление, например
тяжёлые вычисления - это не для ноды, на ноде они не удобны, так как лучше их в отдельный процесс
Alexander
тяжёлые вычисления - это не для ноды, на ноде они не удобны, так как лучше их в отдельный процесс
либо в нативный плагин, который наружу выставит асинхронное апи)
Алексей
libuv нодовский многопоточен, если мне не изменяет память
Вопрос не в многопоточности, а в асинхронности. Например можно сетевые подключения несколькими потоками обрабатывать, но с использованием асинхронного апи ОС. Тогда количество одновременных подключений может сильно превышать число потоков, так как всякие ожидания прихода записи не будут блокировать потоки.
Алексей
И скорее всего в ноде сетевой стек так и реализован, иначе бы просто вся нода была бы просто бесполезной.
Alexander
просто асинхронность для сетевого стека можно и на пхп сделать, и делают на основе stream_select, у ноды же несколько больше возможностей для этого, т.к. она для этого и разрабатывалась
Алексей
просто асинхронность для сетевого стека можно и на пхп сделать, и делают на основе stream_select, у ноды же несколько больше возможностей для этого, т.к. она для этого и разрабатывалась
можно хоть на чистом Си, только это всё неудобно
Alexander
можно хоть на чистом Си, только это всё неудобно
почему-то мне кажется, что реализация на си окажется удобнее, чем на пхп. ну и как минимум производительнее
Алексей
почему-то мне кажется, что реализация на си окажется удобнее, чем на пхп. ну и как минимум производительнее
удобнее - нет, так как на Си даже замыканий нет, производительней - да
Anonymous
можно хоть на чистом Си, только это всё неудобно
Вот, т.е. вопрос исключительно в удобстве или требованиях ?
Alexander
Вот, т.е. вопрос исключительно в удобстве или требованиях ?
как по мне, одно происходит из другого
Alexander
удобство -> более быстрая разработка -> бизнес доволен, его требования соблюдены
Alexander
уперлись в производительность? масштабируйтесь
Алексей
Вот, т.е. вопрос исключительно в удобстве или требованиях ?
Ну как в удобстве. Просто например на Си реализация любой нетривиальной асинхронной логики превращается просто в ад. Не говоря уже о количестве потенциальных багов.
Alexander
уперлись в возможности масштабирования? переписывайте
Николаич
Есть коллекция tags, Есть коллекция posts, в которой есть поле tags, содержащее массив закрепленных тегов.
При запросе /DELETE /api/tags/:id удаляю запись из коллекции.
Как у всех posts удалить переданный :id из массива?
Алексей
На C++11 уже чуть удобнее будет, так как там уже есть какие-никакие лямбды. Но вот нода удобнее всех на мой взгляд, так как есть замыкания, промисы, async/await и всё апи асинхронно.
Алексей
Даже стандартное (хотя есть и синхронные аналоги)
Алексей
Просто во многих языка стандартная библиотека синхронна и есть большой соблазн, например прочитать файл синхронно в асинхронном обработчике со всеми вытекающими последствиями в виде блокировки потока-воркера.
Alexander
Ну мне вот наоборот асинхронная порода ноды увеличивает время разработки, потому я берусь реализовывать на ноде только то, что без асинхронности делать плохо
Alexander
Это очень индивидуально, и я уверен, что кто-то может делать те же задачи, которые я делаю на пхп с такой же скоростью, только на ноде. Кто-то, но не я)
Алексей
Ну мне вот наоборот асинхронная порода ноды увеличивает время разработки, потому я берусь реализовывать на ноде только то, что без асинхронности делать плохо
Если коллбэками всё делать, тогда да. Это вообще родовая травма ноды, что она без промисов появилась. Если бы изначально всё стандартное апи ноды основывалось на промисах, то и сторонние либы изначально тоже скорее всего бы писались на промисах. А с появлением async/await асинхронный код почти ничем бы не отличался от синхронного. Хотя конечно сейчас уже появилось много либ на промисах. И util.promisify в стандартной библиотеки ноды, но всё же есть места, которые на старых добрых коллбэках и с трудом промисифицируются (привет EventEmitter, потоки и так далее)
Alexander
ну опять же, я как выходец из пхп, привык всё по умолчанию считать синхронным, и на каждой третьей строчке кода я обнаруживаю, что у меня в переменной данных нет и метод работает не так, как я ожидал.
проблема привычки и нежелания в RTFM
Alexander
в итоге я после каждой третьей строчки останавливаю софтину и пишу async/await
Алексей
Просто привыкнуть надо
Alexander
а привык то я к тому, что накатал портянку кода, прогнал тесты и запушил в прод)
Алексей
на ноде в принципе также можно
Алексей
если писать на async/await и не забывать этот самый await где нужно ставить
сomorsiс
прикручиваем типы и не забываем
Алексей
прикручиваем типы и не забываем
Во во. Про Flow сказать ничего не могу, но TypeScript - няшка.
Alexander
ну вот я и говорю, что всё индивидуально: дать одинаковую задачу мне и тебе и разрешить использовать любимые инструменты, мы примерно в одну минуту задачу сдадим, а добавить условие "юзать только ноду", так тут я сдам на неделю позже, потому что после каждой третьей строчки буду гуглить, как побороть асинхронность)
Joseph
Как можно пересылать json по сокету tcp сервера
Alexander
я например два часа убил на борьбу с асинхронностью чтобы вывести данные из api в формочку на vue. у меня от этого горело.
Alexander
потом пришло просветление, когда выяснилось что я делаю не так)
Alexander
но факт остается фактом: полностью асинхронный апи не всем и не всегда удобен. я вот про это говорю
Alexander
иногда мне наоборот не хватает асинхронности, такое тоже есть. есть масса задач, которые асинхронно решаются проще
Алексей
но факт остается фактом: полностью асинхронный апи не всем и не всегда удобен. я вот про это говорю
Нет. В том то и дело, что синхронный апи в асинхронной среде не нужен и даже вреден. Так как вызов синхронного апи в асинхронной функции приведёт к неприятным последствиям. А если полностью освоить async/await (и не только), то от асинхронности не будет страданий.
Alexander
Нет. В том то и дело, что синхронный апи в асинхронной среде не нужен и даже вреден. Так как вызов синхронного апи в асинхронной функции приведёт к неприятным последствиям. А если полностью освоить async/await (и не только), то от асинхронности не будет страданий.
а если мне нужно полностью всё синхронно сделать? другой язык брать?
Дима
Нужно чтобы что?
Алексей
а если мне нужно полностью всё синхронно сделать? другой язык брать?
Зачем нужно делать полностью всё синхронно, когда есть async/await? Я этого вообще не понимаю.
Alexander
у меня такой кейс был:
приходит запрос от пользователя, нужно достать объект этого пользователя из коллекции, если его там нет, то получить по api, положить в коллекцию и отдать оттуда. async/await в то время еще не было. промисы только появились. в итоге пришлось заставлять метод UserCollection.get(id) возвращать промис, хотя можно было бы просто выполнить синхронно. сейчас да, есть async/await, и такие задачи решаются точно так же как синхронно, бесшовно
Алексей
у меня такой кейс был:
приходит запрос от пользователя, нужно достать объект этого пользователя из коллекции, если его там нет, то получить по api, положить в коллекцию и отдать оттуда. async/await в то время еще не было. промисы только появились. в итоге пришлось заставлять метод UserCollection.get(id) возвращать промис, хотя можно было бы просто выполнить синхронно. сейчас да, есть async/await, и такие задачи решаются точно так же как синхронно, бесшовно
Вообще был и есть babel и typescript, которые добавляли async/await туда, где его не было или нет.
Алексей
Для других языков транспиляция в более старую версию языка не очень распространено, но для JS - это норма.
Alexander
с TS я только год назад познакомился, он мне очень понравился, а вот про babel и сам факт существования async/await только пару месяцев назад, так что не очень это работало тогда. тогда лучше всего мне подходил вариант с синхронностью
Alexander
опять же дело привычки и предпочтений. мне например было бы удобнее, чтобы по умолчанию было всё синхронно и только при явном указании async вызов становился бы асинхронным. вкусовщина в общем
Алексей
Ну тогда да. Вообще на самом деле плохо, что нода родилась без таких удобных штук, хорошо хоть сейчас они появились.
Alexander
Ну тогда да. Вообще на самом деле плохо, что нода родилась без таких удобных штук, хорошо хоть сейчас они появились.
сейчас да, когда я узнал про работу с async/await, я пришел в восторг, осталось только приучиться не забывать их ставить
Алексей
опять же дело привычки и предпочтений. мне например было бы удобнее, чтобы по умолчанию было всё синхронно и только при явном указании async вызов становился бы асинхронным. вкусовщина в общем
Советую тогда вкатиться в С# или Python. Это как раз изначально синхронные многопоточные языки, но с поддержкой async/await.
Алексей
А если не хочется ставить повсюду await, тогда в Go.
Alexander
на питона я уже давно смотрю, всё никак не попробую
Alexander
а шарп... сломается мой привычный воркфлоу: поправил строчку, F6 нажал)
Alexander
питон еще и непривычный слегка. по скобочкам скучать начинаю 😁😁😁
Alexander
потому вот для себя выработал такой вариант: всякие stateful штуки писать на ноде, а всё остальное на пыхе. для меня самый быстрый вариант получается
Alexander
главное не перепутать, потому что тогда получается хлам)
сomorsiс
ты перепутал
сomorsiс
нода для stateless