Фронтенд делает бэкенд для фронтенда, который делает бэкенд для фронтенда... Короче, прям по кейсу пойдем - нужен бэкенд, который будет безопасно получать данные для авторизации, скроет маршруты и заменит их на свои и вот это все... В чем сама концепция: встраиваем BFF прямо в Nuxt. Фронтенд обеспечивает бэкенд сам для себя — один инструмент, фронтендер, фронтендеры вокруг и задача не только в том, что бы не разворачивать отдельный бэк - но и уменьшить расстояние в секундах до конечных данных. Зачем это нужно? - Безопасно получать данные для авторизации - Скрыть реальные API маршруты и заменить их на свои - Агрегировать данные из нескольких источников - Кэшировать и оптимизировать запросы Что даст бизнесу? 1. Повысит бизнес-метрики - Страница явно быстрее загрузится, без лишних промежуточных запросов в другой сервис/сервер. - Один прямой запрос, значит легче поддержка и меньше рук необходимо держать. - Рост конверсии за счет скорости, конечно же >100500% 2. Безопасность - Токены и ключи хранятся на сервере, не доступны из браузера, значит меньше рисков утечки данных - Валидация и доп. проверки выполняются на сервере Nuxt 3. Разработка и масштабирование - Один стек/инструмент, проще поддерживать. Меньше ставка на то, что Петя в понедельник не заболеет. - Быстрее разработка: можно скопировать прям файлами API и изменить роуты (новости/статьи и пр.) - Проще инфраструктура сервера, один условный контейнер, вместо двух и более При росте остается возможность перейти на более сложную архитектуру Для большинства наших проектов — рабочее решение. Это все таки не инструкция, а подход — используйте, если вы считаете, что вам это под задачи подходит. Зарубежная преза, по которой можно понять принцип без кода и слов, листать стрелками, ссылка тут #опыт Какое слово не понятно в тексте? BFF? Расшифруй или придумай свое :) Ну или сколько шакалов у картинки по шкале от 1 до 10?