Если использовать SignedURL для загрузки файлов, то как нам быть уверенными, что клиент залил нужный формат/размер/...?
В случае классической архитектуры, пользователь, загружает файл сперва на клиент, далее клиент отправляет запрос с файлом в body на сервер, и только после это сервер отправляет тот же файл в облако."
В "классической архитектуре" используются стримы и сервера не сохраняют файл у себя, при этом остаётся возможность выцепить из стрима мета данные этого файла.
В статье описано применение RPC, но что насчёт обычных REST запросов? То есть каждый микросервис имеет свои эндпоинты и другие микросервисы шлют на него запрос как на какой-нибудь удаленный сервис, не зная, что они находятся в "одной экосистеме". Большая ли разница в производительности, и может есть еще какие-нибудь подводные камни?
Был бы намного познавательнее формат «делай вот так, потому что в этом есть вот такие плюсы», как немного в пункте про классовые и функциональные компоненты. Сейчас это выглядит как информация, взятая с потолка, т.е. без объяснения причин.
P.S. Если что я не имею в виду, что все эти советы ненужные) Спасибо за перевод!)
Как у вас реализовано общение цепочки сервисов api-gateway -> api-composition -> microservice, чтобы клиент получил запрашиваемый результат? Кто-то говорит, что REST-запросов достаточно, а другие - "если у вас хай-лоад, то REST загибается и нужно использовать только брокеры сообщений (rabbit, kafka и тд)". Интересно узнать какие практики используются именно на популярном проекте)
Если использовать SignedURL для загрузки файлов, то как нам быть уверенными, что клиент залил нужный формат/размер/...?
В "классической архитектуре" используются стримы и сервера не сохраняют файл у себя, при этом остаётся возможность выцепить из стрима мета данные этого файла.
В статье описано применение RPC, но что насчёт обычных REST запросов? То есть каждый микросервис имеет свои эндпоинты и другие микросервисы шлют на него запрос как на какой-нибудь удаленный сервис, не зная, что они находятся в "одной экосистеме". Большая ли разница в производительности, и может есть еще какие-нибудь подводные камни?
Был бы намного познавательнее формат «делай вот так, потому что в этом есть вот такие плюсы», как немного в пункте про классовые и функциональные компоненты. Сейчас это выглядит как информация, взятая с потолка, т.е. без объяснения причин.
P.S. Если что я не имею в виду, что все эти советы ненужные) Спасибо за перевод!)
Как у вас реализовано общение цепочки сервисов api-gateway -> api-composition -> microservice, чтобы клиент получил запрашиваемый результат? Кто-то говорит, что REST-запросов достаточно, а другие - "если у вас хай-лоад, то REST загибается и нужно использовать только брокеры сообщений (rabbit, kafka и тд)".
Интересно узнать какие практики используются именно на популярном проекте)