Да, оба способа доступны для обращения. gRPC лучшее по выше перечисленным критериям. Но если язык клиента не поддерживает gRPC, то он может использовать более привычный протокол http
У grpc-gateway менее быстрая скорость по http, в сравнении с другими серверами на GO. Потому что у нас сначала идет вызов по http, потом происходит маршелинг, потом вызов gRPC, и потом все тоже самое, но уже в обратную сторону
Например, в нашей компании мы при обновлении API на 2ю версию, сразу завезли туда gRPC и все SDK перевели, конечно же, на него. А REST остался, тк он более привычен простым пользователям, особенно не разработчикам.
А по-поводу того что у вас. Я согласен, что использовать этот подход, не имея ввиду дальнейшее внедрение и переключение всех сервисов на gRPC, это не самое разумное использование ресурсов системы.
Если нет возможности аргументировать это Вашим менеджерам, я бы тогда все же предложил посмотреть в сторону того, как тогда использовать этот подход на все 100%.
Да, оба способа доступны для обращения. gRPC лучшее по выше перечисленным критериям. Но если язык клиента не поддерживает gRPC, то он может использовать более привычный протокол http
У нас блокчейн, так что с ним взаимодействуют сторонние проекты которые вокруг него. Ну и наши собственные приложения, кошельки и сервисы.
Скорее всего)
А по-поводу того что у вас. Я согласен, что использовать этот подход, не имея ввиду дальнейшее внедрение и переключение всех сервисов на gRPC, это не самое разумное использование ресурсов системы.
Если нет возможности аргументировать это Вашим менеджерам, я бы тогда все же предложил посмотреть в сторону того, как тогда использовать этот подход на все 100%.
Минусы
2-3
3-2
4-3
5-4
6-4
7-3
8-3