За последние 24 часа нас посетили 9023 программиста и 449 роботов. Сейчас ищут 126 программистов ...

Запросы к внешнему API из бэкэнда

Тема в разделе "Laravel", создана пользователем EldarS, 12 ноя 2019.

Метки:
  1. EldarS

    EldarS Новичок

    С нами с:
    12 ноя 2019
    Сообщения:
    2
    Симпатии:
    0
    Добрый день.
    Я больше по фронтенду, поэтому сильно не пинайте)
    Задача: Нужно отдавать фронтэнду JSON ответ на запрос вида GET /search/{query}. JSON должен формироваться из ответов полученных от REST API внешних партнеров (количество <= 9).

    Задача выполнена частично (3 сервиса) и, наверное, криво. Получился большой контроллер в котором идет обращение к каждому партнеру по очереди через Guzzle. Потом ответы должны разбираться и выводиться в едином виде, ведь у каждого внешнего API свой формат вывода. На этом этапе исполнитель отказался сославшись на недостаток опыта и времени.

    В итоге решили переадресовать задачу какому нибудь фрилансеру, но, чтобы не повторять ошибок, максимально углубиться в задачу. И тут появились вопросы:
    1. Как правильно реализовать задачу с точки зрения архитектуры Laravel 5? Маловероятно что это должен быть гигантский контроллер с пошаговым выполнением.
    2. Можно ли сделать механизм обращения к партнерам гибко настраиваемым? Например какая нибудь таблица соответствий вида поле ответа партнера = поле ответа фронтенду.
    3. Нужны ли здесь для работы этого приложения какие нибудь модели? Своего ведь ничего нет, все возвращается из внешнего мира. В то же время полученные ответы наверное надо будет кэшировать.
     
  2. Roman __construct

    [ БАН ]

    С нами с:
    27 апр 2019
    Сообщения:
    1.273
    Симпатии:
    113
    Ну, я просто выскажу свое мнение, бо понятие "правильно" оно здесь такое себе - относительное ))

    Логично :) Я бы сделал так:

    1. На бэке - по контроллеру на каждый внешний API
    2. А распараллелил бы - на фронте. К каждому контроллеру - асинхронный запрос, ну и по факту получения данных они там как-нить собирались бы, выводились, в зависимости от бизнес-логики.

    Ниасилил :) Лучше опишите что планируется получить в итоге? Какую задачу хотите решить этим? Но, предварительный ответ - да, можно :)

    Да можно и не кэшировать :)

    Можете очереди использовать: https://laravel.ru/docs/v5/queues в вашем случае.

    Но можно и кэшировать)) какой-нить Redis использовать, или типа того )) можно и с моделями ЖВ

    ###########

    По мне - так вы слишком заморочились изначально на архитектуру ))

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

    Типа того )
    --- Добавлено ---
    и да:

    это он лукавит )))

    Скорее всего он по ходу разработки понял, что размер премии не соответствует трудозатратам - это самая частая причина отказа по ходу проекта.

    В стране кризис)) фрилансам - недоплачивают, а они - недоделывают :D Это обычная ситуация на этом рынке.
     
  3. acho

    acho Активный пользователь

    С нами с:
    28 дек 2016
    Сообщения:
    854
    Симпатии:
    208
    Адрес:
    Санкт-Петербург
    Один контроллер, который принимает запрос от фронта и вызывает сервисный слой. Для каждого партнёра свой отдельный класс (собственно это и будет сервисный слой), ибо скорее всего они достаточно разные. В итоге всего один контроллер из 10 строчек, у каждого апи свой отдельный класс, в котором происходит вся работа с апи, никакой мешанины в коде. Причём я бы ещё унаследовал эти классы от другого класса, в котором бы описал метод возвращения ответа, чтоб все классы апи следовали единому стандарту.
    Можно. Но в случае апи я бы назвал это излишеством. Такими вещами обычно только разработчики занимаются. А когда апи меняется - часто оно меняется архитектурно. Крч в случае чего проще разработчику тупо в коде допилить.
    Если надо будет кэшировать - пилите модели. Не надо будет - не пилите.

    Это если нужен бэк и не важно время исполнения (ибо все запросы ко всем апи будут последовательными).

    Если время важно - на фронте делать несколько запросов к разным контроллерам (ну или одному суперконтроллеру, которому передавать нужный апи).

    Вариант с фронтом, даже если время не важно, всё равно предпочтительней.
     
  4. mkramer

    mkramer Суперстар
    Команда форума Модератор

    С нами с:
    20 июн 2012
    Сообщения:
    7.847
    Симпатии:
    1.543
    Да, идеальное решение. А если сторонние сервисы отдают правильные CORS-заголовки, то можно вообще исключить необходимость бэка.
     
    Roman __construct нравится это.
  5. mkramer

    mkramer Суперстар
    Команда форума Модератор

    С нами с:
    20 июн 2012
    Сообщения:
    7.847
    Симпатии:
    1.543
    Или заранее делать базу из всего, @Roman __construct прав, слать запрос на бэк и ждать, пока он 9 запросов последовательно выполнит - не очень интересно.
     
    Roman __construct нравится это.
  6. Roman __construct

    [ БАН ]

    С нами с:
    27 апр 2019
    Сообщения:
    1.273
    Симпатии:
    113
    Ну, судя по постановке задачи, такое ощущение что они бэк чисто ради CORS и ваяют)) Тоже обычное дело. Потому что как-то странно - ни слова про Auth и т.п. - а ведь когда речь идет об архитектуре - хорошо бы изначально знать что там еще из функционала нужно учесть. Хотя бы примерно.
     
  7. EldarS

    EldarS Новичок

    С нами с:
    12 ноя 2019
    Сообщения:
    2
    Симпатии:
    0
    Благодарю за ответы! Картина проясняется

    Вот так и поступим. Гениально и просто

    Почитал про CORS, не наш случай. Все в бэк!

    База получится громадной и быстро потеряет свою актуальность. Насчет "не интересно" согласен, запрос к 3 сервисам в среднем занимает 1.6-1.8 сек. С 9ю сервисами, один из которых точно будет тормозом, ситуация будет совсем не радужная)

    Судя по мудрым изречениям выше, наш бюджет разработчиков не устраивает)

    Иногда изъясняюсь как Йода) Причем только в Интернетах)