Насколько медленнее будет веб-приложение на PHP, модули которого реализованы через API over HTTP по сравнению с «обычным» веб-приложением?

Question

[Роми]

Допустим я буду получать юзера не через какой-нибудь:

$user = User::find(123);

а через что-то вроде:

$user = Http::get('user/123');

и, допустим, у меня значительная часть приложения будет функционировать подобным образом.

При том, что все эндпойнты для API будут находиться на одном домене-сервере - насколько велики будут потери во времени на такие HTTP-запросы?

Какие еще возможны подводные камни в данном случае?

В принципе, существуют проекты, где туча функционала опирается на внешние модули через API (почту слать и пр.), но если реализовать таким образом традиционно внутренние сервисы, вроде юзер-менеджмента и других - будет ли такой проект работоспособен в принципе?

Спасибо.

P.S. Тут вопрос вот какой (суть): будут ли тормоза настолько большими, что помешают нормальной работе приложения? Грубо, говоря, если такая перестройка архитектуры даст +2 секунды к загрузке страницы, то, как по мне, это вполне терпимо. Кароч, я так понял, надо тесты писать, экспериментировать :-)

Answer 1

[Константин Б.]

Многие немонолиты так и работают. Кончено же есть минусы, это задержка получения данных через HTTP плюс дебаг ошибок более сложный

Comments

[Роми]

ну это понятно что если фронт на vue а бэк на ларке то они между собой так и будут)) но я имел в виду обмен данными внутри бэка

[Константин Б.]

Роми, я не имел ввиду только лишь SPA, бывает так что допустим делят что-то на микросервисы внутри приложения. Для вас допустим на примере Laravel, был сайт мнолоит. Появился еще один какой-то раздел, его решили не впиливать в монолит, а сделать отдельно, но допусти авторизация на стороне первого осталась, и новый раздел получается auth user не из своей базы, а тянет с первого по HTTP. Или же допустим микросервис какой-нибудь аналитики. Непонятно чего хотите вы. Да обращение локально будет быстрее чем внутри сети, но медленнее чем прямой запрос к базе, которая опять же локально, а может быть онаже и тоже на другом хосте. Тут нет впроса что медленно, а что быстро. Тут есть вопрос ЗАЧЕМ это делать. Вот когда на него есть ответ значит и имеет место реализация

[Роми]

Для вас допустим на примере Laravel, был сайт мнолоит. Появился еще один какой-то раздел, его решили не впиливать в монолит, а сделать отдельно, но допусти авторизация на стороне первого осталась, и новый раздел получается auth user не из своей базы, а тянет с первого по HTTP.

Да, я именно об этом.

Смысл: пресловутый "декоуплинг" :)

Answer 2

[Adamos]

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

А главное, подозреваю - вы забыли ответить на вопрос "зачем". Подробно, с обоснованием и критикой этого обоснования.

Comments

[Роми]

Нет, у меня есть вполне адекватная мотивация :)

Если общими словами: нужно максимально уменьшить связность внутри приложения.

[Adamos]

Роми, вот как раз если из абстрактной идеи выводить задачу общими словами, легко получается сделать через жопу. Именно поэтому я и написал "подробно...". Потому что при подробном разборе получится, что вы без всякой на то необходимости пускаете на ветер ресурсы, а связность уменьшается просто грамотным использованием СПО, как во всех современных фреймворках.