Это правильное утверждение?

А - говно

Т.е верхний вариант, действительно лучше?

Да

Только префикс users не используй

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

У тебя и так всё в папке users, незачем ещё дублировать это в название каждого файла

В этом плане да. Единственно в ide чуть путаннее будет выглядеть.

Сейчас читал предлагают делать ещё и отдельный файл services, к компоненту, куда можно вынести как понял, бизнес логику

вам не надоело плодить монолит, этож как себя не любить надо

Да это с Интеренета пример). Я ещё ничего не наплодил то). Монолит Вы имеете ввиду внизу?

Монолит это нормально

да что сверху, что снизу. вижу папку components – блюю сори

Как бы Вы посоветовали делать?

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

Действительно, 21-й век на дворе, надо быть толерантнее

Монолит для админки вполне подходит

Не спорю, монолит может быть оптимальным решением. Да чаще всего им и является Но не монолит на js, всё же

что значит "не на js, все же"

монолит внутри сервиса еще ок) главное, чтобы был maintainable

Всё, а не все Значит что я считаю что на js лучше писать микросервисы. А для монолита выбрать язык со статической типизацией (или сильной, я хз, не писал бэкэнд на питоне, может это норм)

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

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

просто пишут же монолиты на python, js, php - все без типизации, и вроде норм живут хотя может это только нам так говорят...

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

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

У питона строгая типизация, может это и спасает Монолиты на js это боль и страдания. Но люди часто не знают этого потому что кроме js ничего и не видели

Ответишь мне?

Да

Да, примерно так связываю Монолит - много кода, много сущностей в одном проекте, надо помнить о связях этих сущностей, проектировать их с учётом этих связей. Статическая типизация очень сильно упрощает дело Микросервисы - связь только через api. Достаточно соблюдать контракт на пару методов для одного микросервиса. Гарантировать его соблюдение можно тестами. Можно обойтись без статической типизации

Это до того момента пока не вспомнишь про задержку и связанность

На go лучше писать микросервисы

та наверно, там компилируемый быстрый язык + типизация, но апишку на нем я намучился писать с ихними interface{}

Нет ничего страшного в отцовстве, поэтому по поводу задержки не парься сильно А что со связностью? Микросервисы как раз дают low coupling

переиграл и уничтожил

Бууум

Микросервисы можно писать на чём угодно. Но если тебе есть чем раскрыть мысль - с удовольствием послушаю почему писать микросервисы на го лучше, чем на ноде

Скорость обработки адекватный парализм (вижу тону хейта)

Скорость обработки будет скорее всего упираться во внешние системы (бд, например). И поэтому слабо связана с выбором платформы Но если так важна скорость, если это числодробилка - ну да, стоит выбрать го/плюсы/Раст/си

"с микросервисами у вас по сети будет больше задержки чем выполнение самого кода" (с) Анонимус этого чата

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

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

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

Да, на чем угодно. Просто некоторые языки лучше подходят и, кроме того, имеют лучшую поддержку для микросервисов, чем другие.. Например: go с горутинами легко уделывает ноду и питон в плане производительности и удобству

опасно так говорить))) имхо пункт "удобство" очень спорный

Да соглашусь, субъективно насчет "удобство"...

А что там с лучшей поддержкой в го? Что именно в языке (или платформе) ты относишь к "лучшей поддержке для микросервисов"? Я пока не понимаю о чём речь Так то нет никакой разницы писать на го микросервисы, или монолит: согласно твоей логике на го и монолит будет быстрее монолита на ноде Отсюда должен следовать вывод что надо всё писать на го

Ну разница немного есть чистая архитектура полностью ложится на go

Из-за интерфейсов что ли? Ну в плюсах есть абстрактные классы, и на них код ещё быстрее работать будет (если правильно его приготовить) Срочно бросаем го и переходим на плюсы

Зачем в некоторых места го сопоставим с с++ а то и быстрее

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

Я вобще не пью. Да и бухать программистам как-то не то

это многопоточность и экосистема языка.

А, извини. Просто странные ошибки, нелопписанные слова - думал это следствие

За это могу извиниться редко на русском пишу.

Я не копался в исходниках, но несколько я понял суть метархии в том, что application слой максимально спрятан от разработчика, которому остаётся писать лишь бизнес слой. Управлять application слоем можно через контракты В итоге получается кодовая база, не привязанная к фреймворку. Писать на нём монолит или микросервисы не имеет значения (отдельный микросервис это тот же монолит). Масштабирование потокомами и микросервисная архитектура это о разном