хттп ошибками

а таймауты?

а ретраи как?

хттп с таймаутами отлично справляется

если узел недоступен вообще то будет ретрай

хттп с таймаутами отлично справляется

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

ты ж там пулишь статус по сути выполнено или нет

пулинг да, но по факту есть ограничения по времени

юзер то ждет результатов

юзер делает запрос одновременно по 5 провайдерам, у каждого из них свой цикл. и если по первому провайдеру мы покажем результат сразу через 200мс, то второй провайдер может уйти в запой на 20 секунд

поэтому там пулинг

это понятно, я пытаюсь понять какой профит тебе тут дает http....

ну то есть, не совсем так

профит понятен

не понятно в чем сложность сделать демоны)

я не вижу от них профита никакого

так стой

сервисы на котлине, оверхеда от веба там ровно 0

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

все хттп запросы к внешним сервисам неблокирующие

ну это если у тебя симфони

у меня нет этого оверхеда

но если б был, то надо было б чето выдумывать

с демонами, amphp, phppm и прочим

5-10мс терпимо, 50мс - дофига

ну честно у меня в продакшене симфони давала оверхэд порядка 10 милисекунд в среднем. И это я уверен что не все сделал что бы было лучше (особенно уверен в том что неадекватно сделал листенеры)

но все же...

продолжим теортизировать) есть 2 сервиса, или больше - не суть. Ты хочешь вызвать метод и подождать. Простой RPC. так?

для этого тебе удобно использовать http так как мы явно будем получать ответ

да

ну честно у меня в продакшене симфони давала оверхэд порядка 10 милисекунд в среднем. И это я уверен что не все сделал что бы было лучше (особенно уверен в том что неадекватно сделал листенеры)

было 10мс, а станет 5мс. отлично ведь

было 10мс, а станет 5мс. отлично ведь

смотря сколько чего занимает, если эти 5ms составляют больше 10% от времени обработки запроса - то да, имеет смысл париться.

но как бы готовых вариантов для php предостаточно в целом - это и php-pm, и возможность замутить конвертацию http в rpc для демона...

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

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

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

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

хотя конечно http проще

а зачем?)

кролику и так достается нагрузки

единственное что в эту всю цепочку добавится реактивности

и с application/stream+json будет повеселее как-то

@fes0r как тебе идея со счетчиком?)

@fes0r как тебе идея со счетчиком?)

каким счетчиком?)

каким счетчиком?)

Ну типа в группе счетчик сообщений, и у всех пользователей чата тоже счетчик который считает сколько сообщений они получили.

Ну типа в группе счетчик сообщений, и у всех пользователей чата тоже счетчик который считает сколько сообщений они получили.

тепло но не решает задачу - тебе надо определить какие сообщения ты уже прочитал а какие еще нет. Как ты будешь это со счетчиком делать?

вдруг я тебя не так понял и это решает задачу

тепло но не решает задачу - тебе надо определить какие сообщения ты уже прочитал а какие еще нет. Как ты будешь это со счетчиком делать?

Не прочитал я те которые по дате позже последнего полученного сообщения

Не прочитал я те которые по дате позже последнего полученного сообщения

так может просто дату хранить?)

так может просто дату хранить?)

Да)

ну вот и славно)

ну вот и славно)

А вот как это в коде реализовать...)

А вот как это в коде реализовать...)

думай)

ну и пробуй конечно

Можно как-то изменить тип маппинга доктрины? Сейчас используется Annotation mapping, a мне нужно для теста использовать yml mapping.

Можно как-то изменить тип маппинга доктрины? Сейчас используется Annotation mapping, a мне нужно для теста использовать yml mapping.

это какой такой тест такого требует

я сделал свою аннотатацию и мне нужно протестировать как она работает на разных типах маппинга

я сделал свою аннотатацию и мне нужно протестировать как она работает на разных типах маппинга

мм.... и причем тут yaml?)

например я точно знаю что елси писать маппинг через аннотации то все работает

а что если придется писать маппинг через yml

мне нужно проверить будет ли работать в таком случае мой код или нет

Сложно

В документаций нашел вот такое https://symfony.com/doc/3.3/reference/configuration/doctrine.html#type

только вот чет не работает)

а что если придется писать маппинг через yml

то не будет работать)))

если ты кастомную аннотацию для мэппинга доктрины сделал

если не будет, то мне нужно сделать тест который будет выдавать ошибку

логично ж что если у тебя мэппинг из yaml берется то он будет только оттуда браться

ERROR: S client not available

если не будет, то мне нужно сделать тест который будет выдавать ошибку

в этом тесте нет смысла. У тебя либо весь мэппинг одной сущности берется из аннотаций или нет. Это контролирует секция mapping в конфигурации бандла доктрины

ты там явно задаешь что юзать

рандом по обычному массиву rand(0, N). при удалении я беру элемент с массива, свапаю с последним с обрезаю массив. точнее давай ArrayList. не массив

В php-ds структура set, если не ошибаюсь

В php-ds структура set, если не ошибаюсь

ну на собеседовании у тебя такого нет)

рандома там нет

add, remove, contains это просто асоц массив в пхп

рандома там нет

Рандома да, но постоянно сдвигаются элементы, что поддерживает простые индексы.

И уникальные значения

ну на собеседовании у тебя такого нет)

Просто помню реализацию

Посоветуйте какая либа зороша для CommandBus? Смотрел simple-bus/symfony-bridge но мне не нравится что они мидлваре используют вместо декораторов

Рандома да, но постоянно сдвигаются элементы, что поддерживает простые индексы.

сдвиг индексов это O(N)

Согласен, не подходит

Lifecycle callbacks не желательно юзать для бизнес логики, а что тогда? Entity listener?

Посоветуйте какая либа зороша для CommandBus? Смотрел simple-bus/symfony-bridge но мне не нравится что они мидлваре используют вместо декораторов

Есть ещё tactician, но там тоже мидлвари. Есть prooph esb, там через плагины вместо мидлвар.

после каждого апдейта title надо перегееривать урл.

Посоветуйте какая либа зороша для CommandBus? Смотрел simple-bus/symfony-bridge но мне не нравится что они мидлваре используют вместо декораторов

Но по сути мидлвар это и есть декоратор для commandbus. Или что ты имел ввиду под декоратором вместо мидлвари?

tactician няшка но да, там мидлвари

Но по сути мидлвар это и есть декоратор для commandbus. Или что ты имел ввиду под декоратором вместо мидлвари?

Да я понимаю Мне просто почему то не нравится идея мидлварей, они себе просто навешиваются и все, и например я не могу сказать тут я использую командную шину с логером а там без логера

в tactician с симфони можешь сделать несколько шин с разными настройками

и мидлварами, соответственно

в tactician с симфони можешь сделать несколько шин с разными настройками

да то что надо

а за счёт того, что плагины ставятся на шину - их тоже можно настраивать отдельно

найс жаль только там handle а не __invoke

Это настраивается

да, их там 5 видов

Это настраивается

thx

Спасибо я сделал свой выбор

в симфони есть что то типа middleware?

в симфони есть что то типа middleware?

В каком месте нужно?

если некоторый роут равен определенному условию, то делать редирект