ни у кого нету туториала по google auth

I am trying to configure the dkim on a mailing script who can help me

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

Если оркестровка в контроллере, то значит и бизнес логика в контроллере

Оркестровка это тоже бизнес логика

вне котекста и кейса нет смысла говорить что плохая практика а что нет

слои вообще не так важны. Они сами возникнут если проектировать по SRP, нет смысла их искуственно создавать и тем более начинать с этого

нет смысла думать от том, что в какую папочку запихнуть.

Вопрос по связке node.js (koa.js)  + react.js
Имею роут  на ноде и на реакте (пример /test): нода по нему отдаёт json, реакт — делает запрос и по полученному json отрисовывает компоненту.
На девелоперском реакте всё работает хорошо. После сборки реакта в статику ноды наблюдаю косяк: пока клика ссылки реакт работает хорошо, но если зайдя на /test (с нормально отрисованной рекактом компонентой) и обновлю страницу (F5), то браузер просто показывает возвращаемый нодой json.
В какую сторону копать, чтоб настроить правильное поведение, чтоб при обновлении и отрабатывал реакт (как на девелоперском режиме)?

не используй api роуты для рендеринга

Есть конечно. Написать код каждый может, а вот продумать нет. Обычно новички рассуждают о том, что эти не важно и лепят всю логику вместе с роутами и контрлллерами в одном файле. Типа это Node.js стайл

А на самом деле опыта не хватает

заведи отдельный путь для api, например site.ru/api/test и по нему отдавай json. а для рендера используй уже другой урл site.ru/test

Я просто перешел с php фреймворков на ноду. И такое деление диктовалось архиктектурой тк
Если вы вынесете БЛ в модель и эта модель будет использоваться в разных местах проекта то это не гуд, у вас появляеться огромные модели, которые знают про другие модели, как вы их тестировать собираетесь?
Если писать БЛ там же где оркестируете сущностями тот же вопрос, как это тестировать нормально?

Смысл в том, что слои должны самы возникать если правильно разделять. По SRP можно писать хоть все в апи гейтвейах, хоть этих слоев мб 10, зависит от кейса.
Я считаю плохой практикой распихивание кода по заготовленным шаблонам папочек, в этом мало смысла.

Спасибо!

Или передавай что-нибудь в запросе как маркер того, что это API-запрос. Например, устанавливай хедер. Но лучше просто разделяй эти два роута.

@thefallenphoenix, спасибо!

Эта проблема решается декомпозицией, а не вынесением бизнес логики в контроллеры.

Так то если вынести бизнес логику(т. е. оркестровку) в контполлеры, то тоже проблемы с тестированием получаются

Нам не нужно тестировать то что находиться в контроллерах и моделях. Зачем нам тестировать методы которые написаны фреймворком и орм, их тесты уже написаны их создателями, нужно тестировтаь только БЛ проекта.

Я не против что слои нужны по необходимости.
Но дело в том, что у всех web приложений есть слой бизнес логики, слой презентации и слой бд.

Ну например если не планируется подключить другие типы гейтвеев(котроллеров), то можно все в них и писать, это не будет нарушением SRP, ведь они не будут менятся по разным причинам. + меньше кода писать и соотвественно поддерживать