Предполагаю следующие причины, по которым можно использовать REST вместо gRPC: 1) Проста для клиента. С REST не потребуется на стороне клиента реализовывать и поддерживать gRPC Stub 2) Безопасность. На клиенте, особенно если это публичная система, сложнее обеспечить безопасность относительно доступа к gRPC Stub.
вот без шуток, я посмотрел штук 10 видео по гРПС, потому что у меня на проекте он используется, но я не шарил что это. Нужно было сразу включить это видео и все. Все вот так вот просто встало на свои места. Спасибо
Хочу разграничить понимание между REST и gRPC. REST подходит для общения между клиентом и сервером. А gRPC, это больше про общения каких то внутренних действий между сервисами/микро сервисами, который не должны отдавать явного ответа, а просто обозначение того что операция по запросу была успешна выполнена и можно продолжать программу (например: отправка email-письма,запись в бд, либо же ручка для других сервисов). Но очень важная фича, что можно выстраивать архитектуру между разными сервисами который написаны на разных языках.
Начал смотреть, чтобы импрувнуться. Увидел мем с собакой "Вам наверное интересно зачем я вас всех собрал". Смеялся настолько долго, что забыл всё, что изучал в течении дня. Придется опять всё пересматривать :(
2:50 - "конечно, теперь надо ... проводить сериализацию" - не совсем корректно, потому что json тоже проводит сериализацию перед отправкой (это и есть формат сериализированных данных), хотя и отображается в human-readable виде
В proto3 удалены required и optional. Все по умолчанию optional. Выбрал grpc в своем микросервисном приложении только из-за того, что proto файл это по сути и есть документация api. На остальные плюсы в целом пофиг было😅, я готов был мириться с оверхедом реста, но протофайлы это, имхо, киллер фича.
Есть расширение, которое позволяет помечать в третьем протобафе помечать поля как обязательные, не факт что все генерилки умеют с ним работать, но scalapb умеет.
OpenAPI (бывший swagger) - отличная документация. Точно так же по ней генерят и контроллеры (и модели) для бекенда и клиентов для разных языков. И наоборот по коду на бекенде генерят доку. Единственный минус - нельзя описать websocket (раньше по крайней мере так было). Но при помощи AsyncAPI можно (им не пользоваться).
Посмотрел все ваши видосы, после того как вы попались в предложке. Очень доволен подачей материала! Но после описания модели OSI не увидел описание модели TCP/IP, которая, на мой взгляд, более ёмкая. Прошу сделать следующий ролик о ней)
почему, для тех же мобилок grpc как по мне лучше будет ибо меньше данных гоняется туда-сюда. плюс можно будет сгенерировать готовый сервис клиент под необходимый язык. это оч удобно
Тоже так думал пока не прочел Site Reliability Engineering от инженеров Google. У них фронт с бэком по rpc общается. Поэтому так шустрр и стабильно возможно
@@semenloktionov3512 разве что придётся фронтов переучить. Хотя тем, кто пользовался автогенерацией клиента по openapi будет проще, думаю. Значит, за grpc будущее. А вот что с graphql тогда - не понятно
Есть только одна причина использовать gRPC - это если вы гугл и увеличивая пропускную способность, прилучается солидная экономия на ресурсах оборудования. Во всех иных случаях - вы получаете сложность поддержки и отладки
Верно, но передается текстовая информация (структура json - ключи, значения, всякие управляющие скоробочки и конструкции), когда как в gRPC только значения (структуру мы определяем на этапе создания protobuf). Т.е. gRPC в этом случае гораздо меньше по объему, соответственно быстрее.
Предположу, что REST нужен там, где не нужна потоковая передача данных и мультиплексирование, но конкретный пример в голову не приходит. Кидайте свои мысли камрады :)
Дожили... Хайп подняли... Ню, стандарт это хорошо... 10 лет назад делал самописную херню такую... А сейчас пришли крутые парни... Это как C# сборки иметь вместо js скриптов в браузере... Очередная блестяшка для сорок...
Предполагаю следующие причины, по которым можно использовать REST вместо gRPC:
1) Проста для клиента. С REST не потребуется на стороне клиента реализовывать и поддерживать gRPC Stub
2) Безопасность. На клиенте, особенно если это публичная система, сложнее обеспечить безопасность относительно доступа к gRPC Stub.
Как на счет безопасности наоборот
вот без шуток, я посмотрел штук 10 видео по гРПС, потому что у меня на проекте он используется, но я не шарил что это. Нужно было сразу включить это видео и все. Все вот так вот просто встало на свои места. Спасибо
Спасибо, еще интересно было бы глянуть видео про UNIX сокеты,и вообще сокеты в вашей интерпретации.
unix сокеты?
@@VitaliySunny да, ошибся
Бля чел хуйней не занимайся,таких видео 1000 на утуб,там все логично сокеты конекты,порты.или ты просто фанатической хуйней занимаешься
Хочу разграничить понимание между REST и gRPC. REST подходит для общения между клиентом и сервером. А gRPC, это больше про общения каких то внутренних действий между сервисами/микро сервисами, который не должны отдавать явного ответа, а просто обозначение того что операция по запросу была успешна выполнена и можно продолжать программу (например: отправка email-письма,запись в бд, либо же ручка для других сервисов).
Но очень важная фича, что можно выстраивать архитектуру между разными сервисами который написаны на разных языках.
grpc больше подходит для внутренних api, а rest для того чтоб предоставлять api своего сервиса сторонним разработчикам.
Хороший ответ, мне нравится)
Начал смотреть, чтобы импрувнуться. Увидел мем с собакой "Вам наверное интересно зачем я вас всех собрал". Смеялся настолько долго, что забыл всё, что изучал в течении дня. Придется опять всё пересматривать :(
как все свежо и молодежно 😊
как будто и не было корбы и ms rps больше 30 лет назад...
Скоро снова придумают distributed transactions, вот тогда заживём...
Всё новое это хорошо забытое старое
2:50 - "конечно, теперь надо ... проводить сериализацию" - не совсем корректно, потому что json тоже проводит сериализацию перед отправкой (это и есть формат сериализированных данных), хотя и отображается в human-readable виде
В proto3 удалены required и optional. Все по умолчанию optional.
Выбрал grpc в своем микросервисном приложении только из-за того, что proto файл это по сути и есть документация api. На остальные плюсы в целом пофиг было😅, я готов был мириться с оверхедом реста, но протофайлы это, имхо, киллер фича.
Есть расширение, которое позволяет помечать в третьем протобафе помечать поля как обязательные, не факт что все генерилки умеют с ним работать, но scalapb умеет.
OpenAPI (бывший swagger) - отличная документация. Точно так же по ней генерят и контроллеры (и модели) для бекенда и клиентов для разных языков. И наоборот по коду на бекенде генерят доку. Единственный минус - нельзя описать websocket (раньше по крайней мере так было). Но при помощи AsyncAPI можно (им не пользоваться).
@@avpmk вебсокети тепер теж можна
Посмотрел все ваши видосы, после того как вы попались в предложке. Очень доволен подачей материала! Но после описания модели OSI не увидел описание модели TCP/IP, которая, на мой взгляд, более ёмкая. Прошу сделать следующий ролик о ней)
отличный видос, продолжайте в том же духе
иногда вот кажется что всё подобное придумывается только для души, выглядит супер чётко, но потом чтобы поддерживать это нужно прям страдать...
Главное что за это платят деньги)
Супер урок! Спасибо 🎉
Отличный видеоролик
Интересно будет если расскажете про Kafka или Redis
Обязательно будет! Кстати, про redis мы уже немного рассказывали в нашем видео про NoSQL
Наверное, пока что лучше юзать rest для общения фронтенда и бекенда. Можно через api gateway преобразовывать запросы в grpc
почему, для тех же мобилок grpc как по мне лучше будет ибо меньше данных гоняется туда-сюда. плюс можно будет сгенерировать готовый сервис клиент под необходимый язык. это оч удобно
Тоже так думал пока не прочел Site Reliability Engineering от инженеров Google.
У них фронт с бэком по rpc общается. Поэтому так шустрр и стабильно возможно
@@semenloktionov3512 разве что придётся фронтов переучить. Хотя тем, кто пользовался автогенерацией клиента по openapi будет проще, думаю. Значит, за grpc будущее. А вот что с graphql тогда - не понятно
@@RatchetTV1515 graphql по-моему концепт другого уровня. Он вполне может работать и поверх grpc.
@@uuuummm9 ну, кстати, думаю, что хороший вариант в виде интерфейса BFF делать через graphql
Не понял момента в чем преимущество общения grpc в микросковисах , когда для этого используют брокеры с http
Спасибо за видео! Бвло интересно 😊
А есть видео о том, как хранятся данные(object(array, {}, function)) в памяти и как происходит push, unshift, etc. c этими данными?
Есть только одна причина использовать gRPC - это если вы гугл и увеличивая пропускную способность, прилучается солидная экономия на ресурсах оборудования. Во всех иных случаях - вы получаете сложность поддержки и отладки
Херь написал
Тогда переходи на голубей😂
@@midrim гRPC
офигенные видосы, все пересмотрел по несколько раз) предлагаю следующее видео запилить про graphql
Хотите сказать что для взаимодействия с Docker-Compose их контейнерами? Юзать TCP не логично?
Рест удобно года пэйлоад не очень большой или когда всегда большая часть полей присутсвует в каждом запросе
Для внешних интеграций конечно лучше REST
Лучший
Хорошее видео. Понятное ❤
можно пояснительную бригаду, причем тут икс зибит?)
я правильно понял, что можно переставать учить rest и начинать учить grpc?
Дай бог здоровья
Но передача json тоже по сути бинарный, не ?
Верно, но передается текстовая информация (структура json - ключи, значения, всякие управляющие скоробочки и конструкции), когда как в gRPC только значения (структуру мы определяем на этапе создания protobuf). Т.е. gRPC в этом случае гораздо меньше по объему, соответственно быстрее.
о новый видосик
отличный ролик
Так это все же технология, фреймверк или система? А то за одну минуту чем только не назвали
Чот подумал, а что в grpc с bigendian\littleendian ?
8:37 очень много кодаааааа не супер нужного, но если очень много денег и времени, вполне можно попробовать
2:03 не PATCH?
Мне интересно что за микрофон у Диктора ))
Меня тут на собес спросили: а можно ли через http реализовать асинхронную интеграцию? И что - то я подвисла) Помогите, знатоки!
можно
Контент краткий и интересный! Можно узнать название саундтрека к вашим роликам?
И правда, наконец, стало понятно! Как будто ангельской золотой дождь на темечко пролился. Хотелось еще немного по минусам grpc послушать
Предположу, что REST нужен там, где не нужна потоковая передача данных и мультиплексирование, но конкретный пример в голову не приходит. Кидайте свои мысли камрады :)
Я уже давно все вебные протоколы использую как функции, начиная с веб-сервисов.
Rest лучше в названии) простота а еще независимость.
Жду видос по эластику
Жду видос по мантикоре
Когда нужен синхрон , наверно тогда REST
Rest и на асинхронном пишут
пришел по зову из телеги
Все круто. Но я ничего не понял
Сделайте видео про Unix сокеты пожалуйста
Сделайте пожалуйста Видео про ISCSI
Сделайте видео про сокеты на трансплртном уровне пожалуйста
А ответ на вопрос можно ?)
а 👉а 👉
Рест умер , вкатываемся на grpc?
Не-а, для микросервисов больше эта технология.
Жесть, пчел юзает мёртвые мемы и то криво (
Помянем
❤
Автор видео, вы куда то очень торопились?
На троллейбус только, а что?
Moore Maria Lopez Brian Thompson Frank
Esteban González, Fernando Sánchez, Enrike Espenoza, Mario Garcia
😂😂😂бляяя
Ахаха
Эта бабка со свечами разорвала меня нахуй)
Что за ересь? Где лягушонок с компуктером?
Дожили... Хайп подняли... Ню, стандарт это хорошо... 10 лет назад делал самописную херню такую... А сейчас пришли крутые парни... Это как C# сборки иметь вместо js скриптов в браузере... Очередная блестяшка для сорок...
⁴⁴⁸
САМЫЙ ОТВРАТИТЕЛЬНЫЙ САЙТ У ВАС