NG
хотя может взрослую многопоточность завезли
Size: a a a
2021 February 03
NG
NG
ща доку посмотрю
NG
Варианта использования я могу назвать только 2. В силу того, что DI не может происходить между тредами, использовать получается в следующих случаях:
- Методу какого-нибудь сервиса нужно выполнить тяжёлую операцию и её можно вынести в tread, чтобы не нагружать основной поток. Все необходимые процессу зависимости нужное передавать туда напрямую.
- Процесс всего приложения можно запустить в нескольких потоках. Так как это потоки, входящие сообщения будут распределяться на все созданные потоки. То есть фактически будет запущено N копий приложений на N процессорах. Проблема что в реальных условиях это не эффективно. Обычно микросервисы запускаются в изолированных контейнерах (docker, pod) и толку от многопоточности не много, так как проще в управлении запустить несколько контейнеров и нагрузку будет уже регулировать nginx, ingress или другой балансировщик.
- Методу какого-нибудь сервиса нужно выполнить тяжёлую операцию и её можно вынести в tread, чтобы не нагружать основной поток. Все необходимые процессу зависимости нужное передавать туда напрямую.
- Процесс всего приложения можно запустить в нескольких потоках. Так как это потоки, входящие сообщения будут распределяться на все созданные потоки. То есть фактически будет запущено N копий приложений на N процессорах. Проблема что в реальных условиях это не эффективно. Обычно микросервисы запускаются в изолированных контейнерах (docker, pod) и толку от многопоточности не много, так как проще в управлении запустить несколько контейнеров и нагрузку будет уже регулировать nginx, ingress или другой балансировщик.
мне скорее интересно - кто-нибудь всякие threadpool и другие модели реализовывал ли на ноде
NG
не сколько для практики - сколько хотел бы на числа посмотреть
KB
Всем привет, кто подскажет с точки зрения архитектуры приложения на микросервисах с grpc, на сколько правильнее их разбивать? На более мелкие типа сервис поиска/комментариев/постов и тд или же лучше объединить в более крупные сервисы?
DB
Столкнулся с интересной особенностью. Есть вот такая DTO, которая предполагает что поля - опциональные для ввода, но у них есть дефолтное значение.
При этом у меня включен самый строгий режим в TypeScript. И когда я передаю
Как решить эту проблему?
При этом у меня включен самый строгий режим в TypeScript. И когда я передаю
username в функцию, которая ожидает строку, TS ругается, что там может быть ещё и undefined.Как решить эту проблему?
DB
Konstantin Belkin
Всем привет, кто подскажет с точки зрения архитектуры приложения на микросервисах с grpc, на сколько правильнее их разбивать? На более мелкие типа сервис поиска/комментариев/постов и тд или же лучше объединить в более крупные сервисы?
Микросервисы - как очки, вы почувствуете, когда они вам станут нужны. Судя по вашему вопросу, вы этого не чувствуете. Поэтому пока что лучше объединить все ваши микросервисы в один крупный сервис. Серьёзно.
🏡К
мне кажеться, или String(undefined) === “undefined”?
VA
Микросервисы - как очки, вы почувствуете, когда они вам станут нужны. Судя по вашему вопросу, вы этого не чувствуете. Поэтому пока что лучше объединить все ваши микросервисы в один крупный сервис. Серьёзно.
+++
DB
мне кажеться, или String(undefined) === “undefined”?
Тем не менее, это string. У меня вопрос немного в другом
🏡К
Столкнулся с интересной особенностью. Есть вот такая DTO, которая предполагает что поля - опциональные для ввода, но у них есть дефолтное значение.
При этом у меня включен самый строгий режим в TypeScript. И когда я передаю
Как решить эту проблему?
При этом у меня включен самый строгий режим в TypeScript. И когда я передаю
username в функцию, которая ожидает строку, TS ругается, что там может быть ещё и undefined.Как решить эту проблему?
сделать if (name !== undefined) {func(name)}
DB
сделать if (name !== undefined) {func(name)}
Но эта проверка излишняя по своей природе. И засоряет код, ведь это не единичный случай
KB
Микросервисы - как очки, вы почувствуете, когда они вам станут нужны. Судя по вашему вопросу, вы этого не чувствуете. Поэтому пока что лучше объединить все ваши микросервисы в один крупный сервис. Серьёзно.
Начал изначально с такой архитектуры, так как есть некие планы на будущее где будет работа с большим количеством данных, и множеством не связанных с собой бизнес логикой приложениями
D
Konstantin Belkin
Начал изначально с такой архитектуры, так как есть некие планы на будущее где будет работа с большим количеством данных, и множеством не связанных с собой бизнес логикой приложениями
Ну так и дели постепенно, когда будет необходимость
D
Преждевременная оптимизация - корень всех зол
DB
Konstantin Belkin
Начал изначально с такой архитектуры, так как есть некие планы на будущее где будет работа с большим количеством данных, и множеством не связанных с собой бизнес логикой приложениями
Да, и это самая типичная ошибка. Начинать разработку с микросервисов из-за планов на будущее. В итоге захлебнётесь в архитектуре раньше, чем успеете вырасти. Проверено на опыте неоднократно.
S
Macos new version
DB
Konstantin Belkin
Начал изначально с такой архитектуры, так как есть некие планы на будущее где будет работа с большим количеством данных, и множеством не связанных с собой бизнес логикой приложениями
Изучите подход monorepo
KB
Изучите подход monorepo
У меня микросервисы на этом подходе написаны)