Взаимодействие приложений на разных стэках?

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

У меня знания джуна в веб разработке, могу написать бэк, клиент на современных фреймворках для js, php, обычные CRUD приложения. Сейчас изучаю курс по docker, ansible, чтобы автоматизировать сборку и деплой приложения. Микросервисы и брокеры сообщений следующая тему с которой хотелось ознакомиться. Ещё когда то прошел курс по cisco по сетям, что мне кажется полезно для джунов. Пробелы у меня есть по архитектуре эвм, операционных систем и различные низкоуровневые вещи. Мобильные, десктопные приложения не писал, разве что по с++ книгу прочел когда то, но там дальше консольных задач не было глав - то были просто основы языка. И общие навыки конфигурации nginx, apache.

#Но заранее хотелось узнать о том, как работают между друг другом сервисы?
Я так догадываюсь, что брокеры сообщения в этом помогают сконнетить все части между собой.
И через rest api общаться между приложениям со всем издержками http протокола.

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

Если у меня приложение написано на другом стэке, к примеру не питоне, а с++ для какого то анализа. То как происходит общение с бэком. Если это питон, то всё строится на каком то легковесном веб-фреймворке, чтобы через рест запросы коммуницифровать или если это с++, то можно какой то отдельной библиотекой, котороая отлавливает сетевые запросы общаться?

Допустим что оно все крутится на одном сервере и всё разворачивается через докер.

#И от вас возможно получить тз для тестового процесса, чтобы со всем этим ознакомиться
Буду Вам багодарен, если придумаете простое тз, котороя меня познакомит с такой разработкой. на разных стэках и взаимодействие между ними Какое то более нестадартное задание, которое будет заниматься какой то обработкой аудио, видео данных. С кратким описанием стэка и схемы комуницирования.

P.S Понимаю, что и в самом фронте можно глубоко копать и оттачиваться определенные навыки. Но помимо текущих задач, интересно видеть картину чуть шире, чем оно пока есть для меня.

Дополнительно:

для транспорта есть:

• брокеры сообщений
• http (REST как вариант или GRPS)
• файловая система
• базы данных
• CGI
• websocket
• любой самописный протокол, который реализуете на тех языках, на которых собираетесь общаться
• вызов скриптов на др языке как команды в операционной системе

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

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

А потом приходит начальник, и говорит. - эээ, мы вообще планировали распараллеливать эту нейронку, у нас будет от 10 до 10500 инстансов в в облаке. Данные давайте сложим вот в монго-кластер, задачи по обработке сбрасываем в очередь в celery, если очередь вырастает больше чем на N, то кубер автоматически поднимает еще несколько инстансов... и так далее, насколько у него фантазия разгуляется.

И когда у тебя сервисы крутятся не на одном компе, то всякая производительная экзотика, типа общей памяти - отпадает. Остается сеть, очередь, REST. И ты выбираешь не то что популярно на хабре в этом году, а сравниваешь что вообще умеют те сервисы, которые ты хочешь получить. Возможно делаешь несколько вариантов и сравниваешь по той-же производиительности. Возможно добавляешь какие-то дополнительные прослойки-обертки-посредники конвертирующие запросы, уменьшая при этом производительность, ага. :)

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

А кроме производительности бывают вопросы типа "сервис упал во время работы, что случилось с задачей которую он обрабатывал? Нужно ли его рестартнуть? Нужно ли перебросить эту задачу на другой инстанс? Если все таски работают нормально, а эта уже в пятый раз упала, то может она кривая какая-то?" И тут понеслось новым слоем - система мониторинга, оповещения, автоматический или полуавтоматический "кризис менеджмент".

В общем тема большая, и большие коммпании решают ее по разному - структура сервисов фейсбука и алиэкспресса может сильно отличаться, и каждый будет уверен что его подход хорош. Ну или не очень хорош, но менять архитектуру для сотени или тысяч сервисов - дорого. И комания binance основанная 5 лет назад может архитектурно оказаться гораздо современнее и технологичнее какого-нибудь paypal'а основанного в прошлом тысячелетии. И не потому что paypal не шарит, а потому что переделывать большую систему очень дорого.

А в майкрософте, основанном 50 лет назад, можно вообще очень странные и неэффективные штуки найти, я уверен.

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

• Всё правильно и разумно в вашем ответе. Я конечно тоже понимаю, что чем больше знаний, тем большеу тебя свободы и можно хоть указатели на память передавать, файлами и т.д Сама база данных - это же тоже прсосто файлы, в которых можно через энкодер какой то тоже поизучать где там, что и как ссылается.
  Можно как то всё же подвести это к моему начальному опыту разработки и какое то простенькое тз придумать? Чтобы я использовал один из вариантов коммуникации между приложениями и на одном из них какую то задачу выполнил, для которой её на этом языке с сопуствующими библиотеками и выполнял.
• ksikrii, мой последний хобийный проект:
  в докере php, nginx, mysql
  vosk-transcriber (оффлайн распознование голоса).

  В браузере простенька страничка, куда можно загрузить аудио или видео.
  ffmpeg конвертирует в mp3, vosk делает субтитры, они пишутся в БД и отображаются на страничке.
  Там еще немножко js на фронте (подсветка плохо распознанных участков и возможность редактировать руками).

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

  Проект чисто для "поиграться", whisper от openai стоит копейки и распознает гораздо лучше.

Ответы:

Ничего нового не выдумали

* шареная память
* пайпы
* сокеты
* надстройки над сокетами (TCP)
* файлы

Всё довольно просто и даже тупо. Взаимодействие происходит виртуально по протоколам, реально по API. Подробнее см. модель OSI.

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