Soap

grpc

DCOM, CORBA, Remoting, SOAP, UDP, OTP, JSTP, Metacom, да их не перечислить

Смотрите RFC на ietf.org

Смотрю сейчас в сторону gRPC и IDL. Идея в том, чтобы создавать сервисы, которые могут находить друг друга и коммуницировать между собой через заданные интерфейсы (схемы, как в GraphQL).
Например:
Сервис А предоставляет интерфейс
getUsers() {
 id: Number;
 name: String;
}

сервис В предоставляет похожий интерфейс
getUsers() {
 id: Number;
 name: String;
 email: String;
}

И есть еще третий сервис С, который делает запрос
getUsers() {
 id
 email
}
и система сама должна найти, что запрашиваемую схему можно получить только от сервиса В и соответственно сделать к нему запрос

Или, если запрос выглядит так:
getUsers() {
 id
 name
}
то предоставить возможность выбора на момент выполнения запроса (этот вариант приемлем, подобно как при открытии какого-то приложения в Intent на Android он предлагает сделать выбор, если таких совпадений несколько)

Есть какие-то живые технологии, которые решают такую задачу (которые дружат с нодой)?

Да, гуглить по ключевым словам service discovery

как раз гуглю, пока не нашел

Consul тот же

по большей части отдает какие-то статьи, чисто теорию

Но логику выбора по схеме вам придется пилить самому

Они все agnostic, ничего не знают о grpc и так далее

Вас надо напилить отдельный микросервис который будет заниматься сбором схем с остальных нод обнаруженных в консуле и принимать решения куда редиректить запрос

В какой сервис, и потом этот сервис опять же ищется в консуле

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

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

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

Одно из ключевых слов для джуна - инициатива. Пойти на курс - это инициатива, написать что-то свое тоже инциатива. Но выбирая между двумя резюме, сначала позовут того кто писал что-то свое. Эта инициатива инициативнее ) Все hr уже давно знают все проекты с курсов чуть ли не по названию файликов. К сожалению в большинстве случаев даже просьба объяснить код из курсового проекта заканчивается неудачно (

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

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

Ну так строго тоже не стоит ) Разные бывают проекты на курсах. Не реклама, но всё выполненное на базовом JS курса Ильи уже даст лютую фору перед остальными соискателями. Ну и по разному выполняют.

Сложнее всего пройти стадию "позовут / не позовут по резюме". Дальше уже фигня )