джава - гостовая криптография, го - всякая поебень асунковая, а пхп гордо сверху на мелком подсосе)

или просто взять котлин)

там корутины мощнее чем на го

или просто взять котлин)

ты ведь мальчик не глупый) сам должен понимать, что просто взять ничего не получится)

почему не получится?

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

два чаю этому товарищу

и я того же мнения :D а Maksim пытается меня переубедить :D но я не отрицаю того, что, возможно, просто не умею готовить демонов на пхп

Можно вполне успешно молотком саморезы закручивать, и шуруповертом гвозди забивать. Но зачем?

Можно вполне успешно молотком саморезы закручивать, и шуруповертом гвозди забивать. Но зачем?

ну просто есть люди, кому лень переучиваться ИЛИ кто хочет делать все на одном стеке для получения лычки "гуру" я за этой лычкой в рамках одного стека не гонюсь

если тебе нужен while(true) и внутри блокирубщий код, который будет чето делать - пхп норм

если нужна асинхронность - забудь за пхп

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

там ещё джава такой версии, что старше меня)

да и хер с ним) если что, часть можно на го запилить (собсна, так и сделали)

вопрос к тем кто часть кода пишет на го

как вы шарите логику между пхп и го кодом?

как вы шарите логику между пхп и го кодом?

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

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

фронт аще отдельной жизнью от всей этой срани живёт. каждый из кусков выполняет свою конкретную задачу. Никаких общих мест у них нет

язык, на котором задача выполняется, вторичен

так не бывает

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

звучит заманчиво...

как скажешь)

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

т.е у вас просто на пхп нет никакой логики

скорее, наоборот. Сага - это и есть процесс, это и есть логика прохождения процесса. А вот все прочие тупые работники

можешь какой-нибудь конкретный пример описать?

без абстрактных "координация процесса" и тд

скорее, наоборот. Сага - это и есть процесс, это и есть логика прохождения процесса. А вот все прочие тупые работники

вы как-то решаете проблему остановки саги? Если процесс пошёл, но тут возникает какой-либо break от юзера

скорее, наоборот. Сага - это и есть процесс, это и есть логика прохождения процесса. А вот все прочие тупые работники

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

вы как-то решаете проблему остановки саги? Если процесс пошёл, но тут возникает какой-либо break от юзера

cancel и сага закрывается

без rollback?

по обстоятельствам

не для всех саг он нужен в принципе

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

а этот порядок - это не твоя логика?)

а этот порядок - это не твоя логика?)

"логика" слишком широкое понятие. Саги - это оркестрация. А "тупые воркеры" хранят в себе как раз таки логику обработки каждого конкретного действия.

сага не должна быть сильно умной....

она должна знать к кому в какой ситуации обращаться

без абстрактных "координация процесса" и тд

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

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

Просто немного разного уровня логика, не ?

Просто немного разного уровня логика, не ?

ась?

ась?

Сага выше, остальные ниже

Я тебя так понял

Сага выше, остальные ниже

ну, да

она должна знать к кому в какой ситуации обращаться

вот она и знает как сделать хорошо себе и как разрозенные части заставить делать 1 общую задачу :)

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

вот у меня больше вопрос в плане организации кода... вот есть у тебя сага которой надо в несколько контекстов в рамках одного процесса сходить, как ты все это организуешь?

two phase commit не решаете?)

вот у меня больше вопрос в плане организации кода... вот есть у тебя сага которой надо в несколько контекстов в рамках одного процесса сходить, как ты все это организуешь?

в плане шаринга данных?

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

я так понимаю у вас своей базы особо и нет?

в плане шаринга данных?

в плане кому принадлежит сага

two phase commit не решаете?)

что делать если "транзакция" длится в среднем 20-30 минут?

вот у меня больше вопрос в плане организации кода... вот есть у тебя сага которой надо в несколько контекстов в рамках одного процесса сходить, как ты все это организуешь?

Сага вполне себе может обращаться к любому контексту. При этом, она в целом не знает кто и как ей ответит. я всё ещё не понял суть твоего вопроса

что делать если "транзакция" длится в среднем 20-30 минут?

из варианта "в лоб" - временное хранилище до глобального коммита

я так понимаю у вас своей базы особо и нет?

отчего же) есть и вполне себе

отчего же) есть и вполне себе

и она принадлежит только одному "воркеру"?

который ни с кем не шарит эти данные?

и она принадлежит только одному "воркеру"?

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

вот, го вообще прям никак не работает с данными базы пхп?

неа

даже не в курсе что она есть

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

доп данные не запрашивает? ну там коллекции какие-то

да

запрашивает, но уже у контрагентов (всякая бюрократия по флоу проведения)

все задачи максимально атомарны. На 1 документ там пролетает сотни событий/команд. Нет вундерзадачи "сделать пиздато"

ясно

ясно

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

ERROR: S client not available

У меня тут сущность пользователя большая получается (4К строк), есть что на части поделить. Может в трейты часть выделить?

зачем?

У меня тут сущность пользователя большая получается (4К строк), есть что на части поделить. Может в трейты часть выделить?

просто раздели одну сущность на несколько маленьких

когда ты выносишь код в трейты - ты заметаешь мусор под ковер. Этот код все еще в юзере просто теперь проблемы не видно.

когда ты выносишь код в трейты - ты заметаешь мусор под ковер. Этот код все еще в юзере просто теперь проблемы не видно.

+

Понимаю.. Но столько уже привязано на сеттеры.. Я задолбаюсь всё переписывать

Сейчас не читабельно очень

Понимаю.. Но столько уже привязано на сеттеры.. Я задолбаюсь всё переписывать

4K строк геттеров и сеттеров?

Хотя бы так

Не

В целом кода + php doc

делай что хочешь

а как тебе поможет вынос в трейты?

ты их реюзать собираешься? сомневаюсь

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

В юзере оставлю только то что к нему реально относится- телефон, почта и прочее

Что можно в сущности отдельные вытащить - в трейты

когда ты выносишь код в трейты - ты заметаешь мусор под ковер. Этот код все еще в юзере просто теперь проблемы не видно.

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

телефон, почта и прочее относятся к контактным данным, а не к юзеру

Что можно в сущности отдельные вытащить - в трейты

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

Первым этапом - вытащить в трейты

если сущности - делай полноценные отдельные сущности с тем же primary key

Потом из них уже в сущности отдельные

зачем лишний промежуточный этап?

Потому что пока есть задачи более важные

тебе все равно придется исправить клиентский код после выноса отдельных сущностей

Угу

телефон, почта и прочее относятся к контактным данным, а не к юзеру

почему? что мне в юзере оставить - username и id?)

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

почему? что мне в юзере оставить - username и id?)

почему нет?

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

у меня есть сущность, у которой есть только связи