ну вот есть две приложухи ларавел

отдельные

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

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

одно из них?

ага

И как оно будет обрабатывать. Там одинаковые классы Job?

можно и так

бля, чет треш какой то

мне как-то не нравится это изначально. что-то не то

вот есть у меня memory storage, я че, не могу из одного приложения пихнуть данные и из другого получить?

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

Ну там, роут дернуть, или консольную команду запустить на худой конец

хуево

вот есть у меня memory storage, я че, не могу из одного приложения пихнуть данные и из другого получить?

можешь. там сериализированные данные

Почему бы просто данные в очередь не класть, а поиложение само решит как их обработать?

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

как вообще по правильному передавать данные между сервисами?

можно через rpc

как вообще по правильному передавать данные между сервисами?

ну можно через REST в json, можно через очередь

сервисы у тебя это отдельные приложения?

да

ну проще всего, конечно по ресту

и как закрыть доступ извне?

какое-нибудь асинхронное шифрование?

вариант

но мне вариант с очередью нравится больше

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

но для очереди нужен эвент луп

без лишних телодвижений

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

что как то костыльно

пхп для чтения из очереди плохо подходит, только для записи

именно

именно

А если команду сделать в том приложении, что главное (обрабаывает очереди)?

и кроном дергать?

И второе прилоежние просто в его папке запустит типа php artisan senddata blabl blabla blabla ?

ну команда, ресурс

разницы особо нет

А уж эта команада сама создат задание в очереди своей

делай через rpc, если предвидется один сервис

ну чобы ресурс дернуть тебе надо через веб стукнуться

будет дохуя воркеров в будущем

но пока один

тогда меняй язык

а что воркеры делают? что это такое вообще?

пока не поздно

ну в твоем случае

тогда меняй язык

нельзя

я только пых норм знаю

nodejs

а что воркеры делают? что это такое вообще?

сервисы небольшие

бля, не нужен мне другой язык

для пыхера ничего будет сложного

это просто так, на будущее)

если что, я голанг возьму

лучше уж срауз на go чтобы не засорять мозг

но основная приложуха на пыхе

и от этого не уйти

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

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

я как раз делал приложение на php, через redis к двум сервисам на go команды посылало

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

а внедрить этот воркер внутрь твоего монолита?

и получится каша

нет, на этот воркер может идти большая нагрузка

и получится каша

да монолиты в принципе на определенном этапе обрастают кашей

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

понял, понял)

ну вот i am сказал про rpc

может тебе подойдет

не подойдет

rpc от обычного rest мало отличается

как вообще авторизацию воркеров организовать, блин...

вот если у меня рпц или рест, как мне чекать, что от воркера пришло сообщение, а не от васи пупкина

ну логично, что токен генерить

@folleah у soa есть паттерн Asynchronous Queuing Может лучше его ? rabbitmb будет выступать в роле главного обмена сообщениями в soa архитектуре.

на пыхе это будет работать то?

да. но не оверхедно тебе ли это будет ?

или все же лучше в MSA