@romicohen
WebDev

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

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

$user = User::find(123);

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

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

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

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

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

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

Спасибо.

P.S. Тут вопрос вот какой (суть): будут ли тормоза настолько большими, что помешают нормальной работе приложения? Грубо, говоря, если такая перестройка архитектуры даст +2 секунды к загрузке страницы, то, как по мне, это вполне терпимо. Кароч, я так понял, надо тесты писать, экспериментировать :-)
  • Вопрос задан
  • 117 просмотров
Пригласить эксперта
Ответы на вопрос 4
@Kostik_1993
Web Developer
Многие немонолиты так и работают. Кончено же есть минусы, это задержка получения данных через HTTP плюс дебаг ошибок более сложный
Ответ написан
@TheAndrey7
Медленее конечно конечно будет, чем прямое получение из БД. Лишние накладные расходы на HTTP и вторичный backend.
Ответ написан
Adamos
@Adamos
Имхо, вы так сами себе делаете мультипликацию трафика на ровном месте.
У вас веб-сервер вместо одного запроса будет вынужден обрабатывать десять, пусть и на локалхосте. Умножив это дело на количество посетителей, можно получить весьма конкретное бутылочное горлышко.

А главное, подозреваю - вы забыли ответить на вопрос "зачем". Подробно, с обоснованием и критикой этого обоснования.
Ответ написан
gzhegow
@gzhegow
aka "ОбнимиБизнесмена"
Отвечая на ваш вопрос - "не медленее". Потому что ваш скрипт по-хорошему не стучиться на вашу авторизацию от имени сервера. Клиентское приложение (яваскриптовое) стучиться на ваше апи, делает это в асинхронном варианте, то есть несколько запросов одновременно, где возможно. И ваш сервер с приложением, где раньше была синхронная авторизация от того, что часть нагрузки ушла на другой сервер только вздохнет с облегчением.

Поэтому желание сначала "всё сделать так", а потом "всё сделать наоборот" - неверное.

Верно сделать монолит, а потом те части которые постоянно в деле - вынести на другую машину с этим самым апи. Авторизацию, социальный модуль (это тот который друзья друзей друзей друзей по графу постоянно рассчитывает), можно платежку тоже отдельно, чтобы ожидания меньше были. Не надо делать ВСЁ отдельно, чтобы оптимизировать.

Сначала всё пишется в "синхронном коде", по мере того как появляется код который должен быть выполнен строго после того как бизнеслогика отработала, т.к. несет за собой последствия, которые потом надо откатывать - появляется "асинхронный код", который представляет собой обыкновенный while (true) в конце когда и кучу \Closure в виде цепочек (то есть они выполняются не в глубь, а в ширину 10 очередей - 10 функций одна за другой, шаг while (true), осталось 5 очередей (5 завершилось) - теперь 5 функций одна за другой, которые ставятся в очередь, используя promise (да, в пхп тоже так можно, причем если вы используете \React\Promise библиотеку, то вы получите обход вглубь, но это неверно, и ведет к нарушению порядка выполнения действий, нужно сначала десять первых уровней, потом десять вторых, тогда как промиз сделает для вас 1-2-3-4-5, следующий 1-2-3-4-5, смысл в том, что третий из первого может хотеть второй из второго например).

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

Потом это где-нибудь падает в стиле "всё работает, но результат неверный" и вам нужно отслеживать, кто что сделал, и тогда появляется уже некая система "кто что когда запустил и когда об этом отчитался". То есть ваш заказ из прошлого абзаца это была новая задача "обработать заказ", которая появилась в результате той задачи что вы ставили "добавить заказ". И вот только когда первая выполнилась, поставив вторую, потом выполнилась вторая - тот второй сервер шлет первому уведомление, что задача готова, или ничего не шлет (если база данных общая - и после перезагрузки страницы изменения будут видны)

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

Худшее, что вас ждет - это создание диспетчера фоновых воркеров. Это такая хрень, которая очень напоминает пхпшную функцию debug_backtrace() только вы реализуете её сами из тех задач которые делаются по апи. То есть вы не делаете запрос "http GET", вы ставите задачу "http POST" (запись в лог, событие), через какое-то время задача стартанула (запись в лог, событие), задача выполнена (запись в лог, событие), задача провалилась (запись в лог, событие), и так для каждой задачи, а задачи по сути ещё одна другую могут запускать.

То есть это не обязательно стоит делать для авторизации, которая должна быстро отрабатывать, но когда начинают играться с "много серверов" творят именно такую чернуху.

В принципе есть написанные штуки вроде даже приемлемого качества типа Temporal (хотя они предлагают организацию именно фоновых запусков приложений, а не фоновых приказов десятку машин), написанный командой Spiral. У Spiral не лучший код в мире, но качество уровня симфони они дать могут.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы