Grpc решает проблемы, возникающие из-за того, что Микросвервисы написаны на разных языках, но ведь Микросвервисы общаются между собой по http, какая разница на каком языке написан Микросвервис? 3:00
@@MrOldschoolrocknroll Поговаривают, есть такая штука, как OpenAPI и на основе схем можно геренить клиенты и серверы для разных языков. Что принципиально нового в этом отношении предлагает RPC?
Имеете в виду, чем отличается запрос REST от запроса RPC, например? REST оперирует ресурсами (то, над чем нам нужно произвести действие), а RPC оперирует конкретными действиями, т. е. функциями, которые дадут нам нужный результат. REST использует параметры пути URL для идентификации конкретных ресурсов (например, GET /persons/1), а RPC использует параметры запроса для ввода функций (например, GET /readPerson?personid=1).
@@MrSatan662 Да. Только в соответствии с другим стандартом. И тут и там хттп только в случае с рестом нужно проектировать и создавать решения, а в случае с рпс есть либы и стандарты которые у прощают взаимодействие. Например рпс может вообще не иметь заголовков в запросе но проще понять что им проще пользоваться как библиотекой когда рест это взаимодействие на стандарте хттп.
Ага. Единственно что серверу нельзя было отвечать на следующий запрос не обработав предыдущего. В видосе неточность. Который раз убеждаюсь, что просмотр видосов - опасен, лучше RFC читать.
Статья ужасная, только запутывает. Возьмем утверждение о том, что grpc не использует обычный http вызов, а использует вызов функции. Вопрос: почему не объяснить сразу что за волшебный "вызов функции"? Почему не рассказать сразу что данные также идут через HTTP/2 и пояснить разницу (тип передаваемых данных, способ коннекта, валидации и т.п.). Вода водой. Сути нет, нет нюансов, которые человеку, не сталкивавшимся с grpc так нужны.
в какой то момент перестал понимаю какого объясняется http/2 мультиплекс, когда речь о gRPC. Автор делай паузы не для точки, а для восприятия... ставь смысловое ударение и больше сравнения. Метаданные и заголовки... ну и какая разница? автор просто тупо прочёл, что такое есть... напоминает помощь от Micrisoft. Капитан очевидность, пожалуйста удели вниманию разнице, что было и что стало и почему вдруг это лучше
очень хорошо, что всё сказанное есть в тексте. На слух воспринимать труднее. Я слушаю, ставлю на паузу, читаю, и потом окончательно понимаю))
Не хватает примеров, слишком абстрактно ...
Он статью зачитал, а не разобрался и рассказал ;)
В плане теории круто, но да пример бы в конце реальной реализации
Ты очень круто читаешь!
Спасибо)
Ничего не понял, но очень интересно ! открыл для себя gRPC. Пойду ознакомлюсь подробнее.
Спасибо большое мил человек, ваша работа превосходна. Как раз искал краткий и ёмкий контент.
Спасибо! Рад, что понравилось.
Молодец! Очень сжато и без воды. Так держать
В бинарном формате же
Спасибо большое за видео!
Вот прям огонь! Молодчики!
Конечно ставлю лайк! И я давно подписан))
Спасибо за работу!
Спасибо, что заглянули, ждём ещё :)
Спасибо, крайне полезная информация и хорошая дикция! Лучше, чем у моего внутреннего голоса ))
Герои по голове ударили. Спасибо за видео ))
Grpc решает проблемы, возникающие из-за того, что Микросвервисы написаны на разных языках, но ведь Микросвервисы общаются между собой по http, какая разница на каком языке написан Микросвервис? 3:00
Да он не понимает тему до конца. Просто зачитал википедию.
Решает, потому что описав контракт один раз, можно сгенерировать клиенты и серверы под разные языки.
@@MrOldschoolrocknroll Поговаривают, есть такая штука, как OpenAPI и на основе схем можно геренить клиенты и серверы для разных языков. Что принципиально нового в этом отношении предлагает RPC?
Спасибо, емко и интересно
Огонь! 🔥
Спасибо за работу!
Расскажи про следующие вещи:
- прокси-сервер;
- очередь сообщений;
- nginx;
- отличие web-приложения от сайта.
Понял, возьмём в очередь по статьям 👌
А вот и статья про прокси, как обещали - th-cam.com/video/oeOuaqyYzSY/w-d-xo.html
Ничего непонятно, но очень интересно...
Нихрена не понял, но очень интересно)
спасибо автору
Очень хорошее видео, за 10 минут самые основы.
Но боже, после того как мозг пропитан REST и SOAP, сложно перестроться хотя бы для понимания
Под "Шаблон метода наблюдателя" имеется в виду паттерн Наблюдатель, я правильно понял?)
большое спасибо большая работа
Большое спасибо за это видео!
Было бы интересно узнать в чем разница КСШ (Корпоративная сервисная шина) и Apache Kafka или ещё какая нибудь MQ (message queue)
Поняли, возьмём на вооружение!
Спасибо, 7:34 3 строка HEADER*
6:58 "Позволяют уменьшить полезную нагрузку". А может все-таки увеличить полезную (в процентах)?
Расскажи про Шину данных)
Касались темы шины в статье по SOA ( th-cam.com/video/WaFIcJMLuNg/w-d-xo.html ). Если что-то ещё хочется узнать про шину, напиши :)
А чем собственно вызов функции отличается от обычного HTTP запроса?
Имеете в виду, чем отличается запрос REST от запроса RPC, например? REST оперирует ресурсами (то, над чем нам нужно произвести действие), а RPC оперирует конкретными действиями, т. е. функциями, которые дадут нам нужный результат. REST использует параметры пути URL для идентификации конкретных ресурсов (например, GET /persons/1), а RPC использует параметры запроса для ввода функций (например, GET /readPerson?personid=1).
@@ListenIT_channel Проще говоря rest это операции с абстракциями ресурсов, а rpc операции с исполняемым кодом. Верно?
@@MrSatan662 REST - это взаимодействие при помощи отправки/приема http запросов, а RPC c помощью вызова функций.
@@СергейСеливерстов-з2я так реализация rpc call тоже выполняется путём отправки запроса по http протоколу. Или я что-то путаю?
@@MrSatan662 Да. Только в соответствии с другим стандартом. И тут и там хттп только в случае с рестом нужно проектировать и создавать решения, а в случае с рпс есть либы и стандарты которые у прощают взаимодействие. Например рпс может вообще не иметь заголовков в запросе но проще понять что им проще пользоваться как библиотекой когда рест это взаимодействие на стандарте хттп.
Зачем gRPC сделан поверх HTTP? Почему не просто через TCP?
HTTP 2/0 даёт "из коробки" больше безопасности соединения, даёт управлять соединениями, обеспечивает потоковую передачу данных
@@ListenIT_channel ну безопасность даёт TLS, TCP не поддерживает потоковую передачу что ли?
frame [freɪm] рамка, обрамление, кадр, оправа
Использование 1го соединения для отправки множества запросов стало возможным уже в протоколе HTTP 1.1
Ага. Единственно что серверу нельзя было отвечать на следующий запрос не обработав предыдущего. В видосе неточность. Который раз убеждаюсь, что просмотр видосов - опасен, лучше RFC читать.
нормас, только хттп прикладной
Статья ужасная, только запутывает. Возьмем утверждение о том, что grpc не использует обычный http вызов, а использует вызов функции. Вопрос: почему не объяснить сразу что за волшебный "вызов функции"? Почему не рассказать сразу что данные также идут через HTTP/2 и пояснить разницу (тип передаваемых данных, способ коннекта, валидации и т.п.). Вода водой. Сути нет, нет нюансов, которые человеку, не сталкивавшимся с grpc так нужны.
Очень похоже на плохой перевод, причем переводчик иногда повторяет одно и тоже два раза, очевидно, вообще не понимая суть того, что он переводит
http протокол прикладного уровня. tcp и udp протоколы транспортного уровня
Стало еще непонятнее
Очень много ошибок. Понимаю, что это озвучка статьи, но тем не менее.
в какой то момент перестал понимаю какого объясняется http/2 мультиплекс, когда речь о gRPC. Автор делай паузы не для точки, а для восприятия... ставь смысловое ударение и больше сравнения.
Метаданные и заголовки... ну и какая разница? автор просто тупо прочёл, что такое есть... напоминает помощь от Micrisoft.
Капитан очевидность, пожалуйста удели вниманию разнице, что было и что стало и почему вдруг это лучше
спасибо, но ничего не понял, но это потому что я балван скорее всего
это статья явно перевод или написана неграмотным человеком
Автор не понимает
Ужас. Автору нужно в школу, подучиться читать и писать
Почему?)
buffer [ˈbʌfə] амортизатор, запас