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

См. https://xyproblem.info

Ок :)
Есть главная страница типа лэндинга, где вход в приложение.
И есть уже само приложение: с менюшками, профилем юзера и так далее.
Соответственно, была идея сделать это в разных layout'ах

В application.hbs засунуть все меню приложения, профили юзера и тд. А в другой layout закинуть разметку для входа в приложение, регистрацию и тд

Так закинь ландос в индекс, а зарегистрированных пользователей перенаправляй в /home

2 разных html файла?

это как 2 разных приложения тогда будет?

Не, приложение одно, просто два роута

В индексе проверяй залогинен ли пользователь

Если да, то ридайректь на home

Ну и наоборот

ну да, видимо так и сделаю) спасибо!

prohibitAuthentication

да, я ним я работал уже, знаю :) спасибо

Так лучше не делать. Само приложение для авторизованного пользователя лучше разместить на его индивидуальном роуте например /admin. В котором и проверять авторизацию. А в application.hbs хранить самую базовую разметку которая для всех страниц используется.

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

👍

Ребята, посоветуйте как лучше сделать валидацию данных что приходят с бэка. Вопрос не привязан к фреймворку. Может есть готовые библиотеки, или стандартные подходы.
Как я себе это представляю - тупо проверить тип запроса / ответа,и требуемые ключи для него. Только вот как дальше быть, если случился баг. С Бэкендщиками сразу договариваться о таком подходе, или принять как данное, что в БД всё самое правильное и актуальное, и бэкендщики никогда не косячат :)

Я бы доверял бэку. Да и что ты будешь делать на фронте, если ответ придет некорретный?
А бэкендщики пусть тестами покроют АПИ и будет всем счастье

У нас на работе была нираз такая ситуация что АПИ на бэке поменялось / доработалось, а фронтендщиков забыли предупредить