Комментарии 3
Взяли сильно большую тему и не до конца углубились в каждую задачу.
У меня в практике сложился следующий подход к выбору технологий:
Если это публичный сервис, то делаем REST-api + openapi (swagger) + валидация входных данных (а на тестовых средах и валидация выходных).
Если это внутреннее синхронное нагруженное взаимодействие, то gRPC
SOAP только если это legacy или просто такие требования (федералы любят)
Для отправки асинхронной задачи (и если ее не страшно потерять), если сервисы подключены к общему кешу Redis, то pub/sub через Redis
Для отправки асинхронных уведомлений (задач) множеству подписчиков - Kafka
Нельзя просто взять и сказать, что при подходе N нужна технология M. Каждую ситуацию нужно рассматривать по отдельности и не сгребать под один подход все приложения. Не просто так существует несколько типов брокеров сообщений (Kafka, Rabbit, IBM MQ) или несколько реализаций RPC. Каждый имеет где-то выйгрыш, где-то проигрыш
Ох, как все грустно.
Синхронное взаимодействие путается с синхронной обработкой на клиенте. REST перестал быть стилем для создания гипермедиа-приложений и стал архититектурой. RPC почему-то не может быть сделан через тот же HTTP (хотя обычно именно так RPC и реализуется).
Ну и так далее, на всю статью нет, кажется, ни одной корректной формулировки и ни одного верного утверждения.
Интересно, какое впечатление от Альфа-банка будет достигнуто такими статьями?
Классифицируем клиент-серверное взаимодействие от А до Kafka