напиши на ноде)

есть основная система на пыхе, она принимает поисковые запросы от юзера, причёсывает их и шлёт поисковые запросы к фасаду эластика на люмене

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

Я в этом случае просто не буду брать пых

а так у тебя по описанию 2 приложения на пыхе (что уже не оч оптимально) и потом еще эластика.

словом amqp тут как "а твой пых может не умирать между запросами?"

вот я вчера пишу расширение для твига и мне нужен контекст, чтоб получить реквест
я просто ставлю брекпоинт и нахожу, где реквест

что я должен был делать без отладчика?

а так ты между системами третью добавляешь что накладные расходы может даже увеличить

подумать например

ну я подумал и пришёл к выводу, что отладчиком быстрее всего

ну то есть у тебя даже мысли небыло что если возникают такие вопросы то что-то не то?

может в принципе, если речь про фасад

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

p.s. большинство не разбираются что делают и с дебагером и без

я должен наизусть помнить, что $request = $context['app']->getRequest();

ты должен знать что инджектить в сервис который твой фильтр реализует а не пытаться вот эти кастыли юзать

а вот это зачем? почему не сразу в эластик?

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

ну эластик это такой же стейтлесс сервис.. ну с фасадом чутка побольше тупит... это большая проблема?

сильно тупит?

стэйтлесс?