Почему считается, что разработке на ноде быстрее разработки на том

же дотнете, хотя у последнего есть мощные фреймворки, орм, LINQ-магия, которые явно помогают быстрее писать код.

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

@murzilka17 у тебя кажется есть опыт с дотнетом?

Есть ещё отличие в типизации ж

для ноды есть тайпскрипт, типы тоже надо писать

тайпскрипт имеет слабую утиную типизацию

Да, именно так

вы спите хотя бы?😅

Проблема ноды не люди, а подавляющие большинство решаемых задач, которые не выходят за рамки элементарного crud без каких-либо затей вроде rbac. Микросервисы только подливают масло в огонь

Ты на ts пишешь дольше, чем на js, мне кажется А под .net обычно пишут на шарпе, который вроде ещё более строг Сначала тебе нужно обмазаться интерфейсами и абстрактными классами, потом всё это реализовать

Микросервисы - это удобно

разработчикам и заказчикам

Уже ответили, да В первую очередь разработчикам

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

по моему микро все дело в постоянных дополнения к продукту? Типо есл у тебя неменяющий бек ( а так не бывает) то мнолоит огонь, но если у тебя постоянно что то меняется, удобнее пользоваться микросервисами

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

Что мешает иметь маленькие модули/плагины?)

ну так это и есть архитектура. а на ноде мы в базу из контроллера лезем

из роутера*

а есть разница?

А чем они отличаются от микросервисов? Если всё в рамках одного процесса, то много чего мешает

для отладки надо локально развернуть и собрать всю систему, это тоже время, целесообразней работать с изолированным фрагментом

Отсутствием транспорта, сериализации и маршалинга

Не, не лезем И архитектура разная может быть, вон вы ночью не спали, всё обсуждали - слои, гексы, эм ви си

так если не лезть, то, наверное, и по времени это займет уже как на дотнете. тем более что придется продумывать архитектуру, а в asp.net всё уже продумано

@ShGKme сейчас шина есть почти в любом крупном монолите Как и несколько бд, как и очереди На чём вы там экономите? И всё по кругу идёт. Если взять подходящие инструменты накладных расходов почти не будет

Одно дело один раз обратиться в БД. Другое, если запрос через 10 сервисов проходит, 10 раз проходя через сериализацию и транспорт.

с инструментами надо ещё угадать, инструмент может не подходить к изменённым требованиям

Я не готов ответить на твои вопросы просто потому что на шарпе я писал прикладной/системный софт, и то же asp.net в глаза не видел Прикладной софт на шарпе писать быстро и приятно

Ну собственно вопрос в том, что такое "подходящий инструмент". Я с плюсами микросервисов согласен ровно до тех пор, пока не говорят, что их основное преимущество, это возможность делать модули

процессорное время дешевле чем время пользователей

советую посмотреть доклад на хайлоэд Бунина, он говорит что для микросервисов не нужны высококвалифицированные кадры

Вот вообще не забочусь об этом

Что это за ад?

Ну пока меня устраивает молекуляр

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

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

Пиздец как жизненно

Почему ты так думаешь?

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

Что это за суть? Она сформулирована как-то?

Это то, что отличает их от соа

Если ты ждёшь ссылку на стандарт, принятый комитетом, то нет

Ну ок Я готов не вдаваться в детали, и топить за всё скопом - микросервисы, соа, акторы 🙂