Добрый день. Я больше по фронтенду, поэтому сильно не пинайте) Задача: Нужно отдавать фронтэнду JSON ответ на запрос вида GET /search/{query}. JSON должен формироваться из ответов полученных от REST API внешних партнеров (количество <= 9). Задача выполнена частично (3 сервиса) и, наверное, криво. Получился большой контроллер в котором идет обращение к каждому партнеру по очереди через Guzzle. Потом ответы должны разбираться и выводиться в едином виде, ведь у каждого внешнего API свой формат вывода. На этом этапе исполнитель отказался сославшись на недостаток опыта и времени. В итоге решили переадресовать задачу какому нибудь фрилансеру, но, чтобы не повторять ошибок, максимально углубиться в задачу. И тут появились вопросы: Как правильно реализовать задачу с точки зрения архитектуры Laravel 5? Маловероятно что это должен быть гигантский контроллер с пошаговым выполнением. Можно ли сделать механизм обращения к партнерам гибко настраиваемым? Например какая нибудь таблица соответствий вида поле ответа партнера = поле ответа фронтенду. Нужны ли здесь для работы этого приложения какие нибудь модели? Своего ведь ничего нет, все возвращается из внешнего мира. В то же время полученные ответы наверное надо будет кэшировать.
Ну, я просто выскажу свое мнение, бо понятие "правильно" оно здесь такое себе - относительное )) Логично Я бы сделал так: 1. На бэке - по контроллеру на каждый внешний API 2. А распараллелил бы - на фронте. К каждому контроллеру - асинхронный запрос, ну и по факту получения данных они там как-нить собирались бы, выводились, в зависимости от бизнес-логики. Ниасилил Лучше опишите что планируется получить в итоге? Какую задачу хотите решить этим? Но, предварительный ответ - да, можно Да можно и не кэшировать Можете очереди использовать: https://laravel.ru/docs/v5/queues в вашем случае. Но можно и кэшировать)) какой-нить Redis использовать, или типа того )) можно и с моделями ЖВ ########### По мне - так вы слишком заморочились изначально на архитектуру )) Я бы сделал сначала MVP (без кэша, моделей и барышень))) - посмотрел как оно себя ведет под реальной нагрузкой - довинтить-то всегда можно уже по ходу. Типа того ) --- Добавлено --- и да: это он лукавит ))) Скорее всего он по ходу разработки понял, что размер премии не соответствует трудозатратам - это самая частая причина отказа по ходу проекта. В стране кризис)) фрилансам - недоплачивают, а они - недоделывают Это обычная ситуация на этом рынке.
Один контроллер, который принимает запрос от фронта и вызывает сервисный слой. Для каждого партнёра свой отдельный класс (собственно это и будет сервисный слой), ибо скорее всего они достаточно разные. В итоге всего один контроллер из 10 строчек, у каждого апи свой отдельный класс, в котором происходит вся работа с апи, никакой мешанины в коде. Причём я бы ещё унаследовал эти классы от другого класса, в котором бы описал метод возвращения ответа, чтоб все классы апи следовали единому стандарту. Можно. Но в случае апи я бы назвал это излишеством. Такими вещами обычно только разработчики занимаются. А когда апи меняется - часто оно меняется архитектурно. Крч в случае чего проще разработчику тупо в коде допилить. Если надо будет кэшировать - пилите модели. Не надо будет - не пилите. Это если нужен бэк и не важно время исполнения (ибо все запросы ко всем апи будут последовательными). Если время важно - на фронте делать несколько запросов к разным контроллерам (ну или одному суперконтроллеру, которому передавать нужный апи). Вариант с фронтом, даже если время не важно, всё равно предпочтительней.
Да, идеальное решение. А если сторонние сервисы отдают правильные CORS-заголовки, то можно вообще исключить необходимость бэка.
Или заранее делать базу из всего, @Roman __construct прав, слать запрос на бэк и ждать, пока он 9 запросов последовательно выполнит - не очень интересно.
Ну, судя по постановке задачи, такое ощущение что они бэк чисто ради CORS и ваяют)) Тоже обычное дело. Потому что как-то странно - ни слова про Auth и т.п. - а ведь когда речь идет об архитектуре - хорошо бы изначально знать что там еще из функционала нужно учесть. Хотя бы примерно.
Благодарю за ответы! Картина проясняется Вот так и поступим. Гениально и просто Почитал про CORS, не наш случай. Все в бэк! База получится громадной и быстро потеряет свою актуальность. Насчет "не интересно" согласен, запрос к 3 сервисам в среднем занимает 1.6-1.8 сек. С 9ю сервисами, один из которых точно будет тормозом, ситуация будет совсем не радужная) Судя по мудрым изречениям выше, наш бюджет разработчиков не устраивает) Иногда изъясняюсь как Йода) Причем только в Интернетах)