Информация об изменениях

Сообщение Re[4]: Микросервисы от 03.05.2023 11:45

Изменено 03.05.2023 12:14 RushDevion

Re[4]: Микросервисы
S>А почему ты решил, что под конкретную платформу?
Ну вот у меня есть сервис на NodeJS, еще один на Rust и третий на Go.
И все они хотят общаться с твоим сервисом на .NET (Core) в который воткнули этот самописный маршалинг.
Как их подружить? Имхо, либо никак, либо нужно рожать поддержку такого же самописного маршалинга под каждую платформу.
Поэтому "под конкретную платформу".

S>Там под .Net Core. Что касается REST, WebSockets, JSON-RPC, GRPC, Thrift и т.п. — для синхронного request-response общения.

S>То это протоколы поверх TCp/Ip. Их также можешь применять, вместо Tcp/IP
Тут не понял. "Проколы поверх TCP/IP, применять вместо TCP/IP". Как это?
Но в любом случае мой посыл был в том, что это стандартные протоколы.
И если я, например, говорю, что мой микросервис предоставляет REST API поверх HTTP.
То таким API без проблем смогут воспользоваться и Rust, и NodeJS, и Go-разработчики в своих микросервисах.
Re[4]: Микросервисы
S>А почему ты решил, что под конкретную платформу?
Ну вот у меня есть сервис на NodeJS, еще один на Rust и третий на Go.
И все они хотят общаться с твоим сервисом на .NET (Core) в который воткнули этот самописный маршалинг.
Как их подружить? Имхо, либо никак, либо нужно рожать поддержку такого же самописного маршалинга под каждую платформу.
Поэтому "под конкретную платформу".

S>Там под .Net Core. Что касается REST, WebSockets, JSON-RPC, GRPC, Thrift и т.п. — для синхронного request-response общения.

S>То это протоколы поверх TCp/Ip. Их также можешь применять, вместо Tcp/IP
Тут не понял. "Проколы поверх TCP/IP, применять вместо TCP/IP". Как это?
Но в любом случае мой посыл был в том, что это стандартные протоколы.
И если я, например, говорю, что мой микросервис предоставляет REST API поверх HTTP.
То таким API без проблем смогут воспользоваться и Rust, и NodeJS, и Go-разработчики в своих микросервисах.

S>Суть микросервисов как раз в работе в разных процессах и обменом сообщений.

Нет. Это подразумевается из соображений отказоустойчивости и масшатабируемости.
Но суть — в единоличном владении данными/процессами некоторой предметной области и предоставлении доступа к этому только через декларированное публичное API.

А углубляться в детали конкретных протоколов и тем паче, делать свою кастомную имплементацию протокола...
Ну это как если бы человек попросил рассказать в общих чертах про ООП, а ты ему начал объяснять, как работает ассемблер.