Что такое gRPC и Protobuf?

Поменяй работу и стань Python разработчиком за 4 месяца 👉
wiki.merionet.ru/merion-acade...
Короче, gRPC это такая система, или фреймворк, который расшифровывается как "Remote Procedure Calls". Подождите, а "g" что значит?
Нууу, кто-то говорит что Google, потому что это их разработка, а официальная документация говорит что g значит gRPC, то есть да это “gRPC Remote Procedure Calls”.
А сами разработчики дико рофлят и каждую новую версию меняют название, так что это особо ни на что не влияет. Нам в мерионе больше всего нравится - glamorous.
Погнали разбираться что такое gRPC и что там делает Protobuf.
Merion Academy - платформа доступного IT образования ❤️
wiki.merionet.ru/merion-academy
Наш Telegram канал:
t.me/it_knowledge_base
#grpc #protobuf

[@user-wh9tr5cf2o]

Предполагаю следующие причины, по которым можно использовать REST вместо gRPC: 1) Проста для клиента. С REST не потребуется на стороне клиента реализовывать и поддерживать gRPC Stub 2) Безопасность. На клиенте, особенно если это публичная система, сложнее обеспечить безопасность относительно доступа к gRPC Stub.

[@italky84]

grpc больше подходит для внутренних api, а rest для того чтоб предоставлять api своего сервиса сторонним разработчикам.

[@devospos]

Спасибо, еще интересно было бы глянуть видео про UNIX сокеты,и вообще сокеты в вашей интерпретации.

[@VitaliySunny]

unix сокеты?

[@devospos]

@@VitaliySunny да, ошибся

[@Nicktimes]

Бля чел хуйней не занимайся,таких видео 1000 на утуб,там все логично сокеты конекты,порты.или ты просто фанатической хуйней занимаешься

[@MrCter]

как все свежо и молодежно 😊 как будто и не было корбы и ms rps больше 30 лет назад...

[@Qiqpop]

отличный видос, продолжайте в том же духе

[@sergey.k]

иногда вот кажется что всё подобное придумывается только для души, выглядит супер чётко, но потом чтобы поддерживать это нужно прям страдать...

[@sasichkamega]

В proto3 удалены required и optional. Все по умолчанию optional. Выбрал grpc в своем микросервисном приложении только из-за того, что proto файл это по сути и есть документация api. На остальные плюсы в целом пофиг было😅, я готов был мириться с оверхедом реста, но протофайлы это, имхо, киллер фича.

[@avpmk]

Есть расширение, которое позволяет помечать в третьем протобафе помечать поля как обязательные, не факт что все генерилки умеют с ним работать, но scalapb умеет.

[@avpmk]

OpenAPI (бывший swagger) - отличная документация. Точно так же по ней генерят и контроллеры (и модели) для бекенда и клиентов для разных языков. И наоборот по коду на бекенде генерят доку. Единственный минус - нельзя описать websocket (раньше по крайней мере так было). Но при помощи AsyncAPI можно (им не пользоваться).

[@frez_x]

@@avpmk вебсокети тепер теж можна

[@ZRKDark]

Посмотрел все ваши видосы, после того как вы попались в предложке. Очень доволен подачей материала! Но после описания модели OSI не увидел описание модели TCP/IP, которая, на мой взгляд, более ёмкая. Прошу сделать следующий ролик о ней)

[@user-zm7hz6zi2d]

Спасибо за видео! Бвло интересно 😊

[@hunterxvov4ik]

вот без шуток, я посмотрел штук 10 видео по гРПС, потому что у меня на проекте он используется, но я не шарил что это. Нужно было сразу включить это видео и все. Все вот так вот просто встало на свои места. Спасибо

[@20GK20]

Отличный видеоролик Интересно будет если расскажете про Kafka или Redis

[@merionacademy]

Обязательно будет! Кстати, про redis мы уже немного рассказывали в нашем видео про NoSQL

[@daniyarzhanakhmetov7741]

А есть видео о том, как хранятся данные(object(array, {}, function)) в памяти и как происходит push, unshift, etc. c этими данными?

[@Exy63]

Супер урок! Спасибо 🎉

[@spacexnix]

Хорошее видео. Понятное ❤

[@artemrokhmakov6373]

Хочу разграничить понимание между REST и gRPC. REST подходит для общения между клиентом и сервером. А gRPC, это больше про общения каких то внутренних действий между сервисами/микро сервисами, который не должны отдавать явного ответа, а просто обозначение того что операция по запросу была успешна выполнена и можно продолжать программу (например: отправка email-письма,запись в бд, либо же ручка для других сервисов). Но очень важная фича, что можно выстраивать архитектуру между разными сервисами который написаны на разных языках.

[@RatchetTV1515]

Наверное, пока что лучше юзать rest для общения фронтенда и бекенда. Можно через api gateway преобразовывать запросы в grpc

[@semenloktionov3512]

почему, для тех же мобилок grpc как по мне лучше будет ибо меньше данных гоняется туда-сюда. плюс можно будет сгенерировать готовый сервис клиент под необходимый язык. это оч удобно

[@MRoose]

Тоже так думал пока не прочел Site Reliability Engineering от инженеров Google. У них фронт с бэком по rpc общается. Поэтому так шустрр и стабильно возможно

[@RatchetTV1515]

@@semenloktionov3512 разве что придётся фронтов переучить. Хотя тем, кто пользовался автогенерацией клиента по openapi будет проще, думаю. Значит, за grpc будущее. А вот что с graphql тогда - не понятно

[@user-wj9tp2od4d]

Есть только одна причина использовать gRPC - это если вы гугл и увеличивая пропускную способность, прилучается солидная экономия на ресурсах оборудования. Во всех иных случаях - вы получаете сложность поддержки и отладки

[@__ali__97]

офигенные видосы, все пересмотрел по несколько раз) предлагаю следующее видео запилить про graphql

[@fab4key]

о новый видосик

[@user-ir1fj5jl4x]

Контент краткий и интересный! Можно узнать название саундтрека к вашим роликам?

[@user-xc8dn1wz7t]

Дай бог здоровья

[@Edgar-pu1lc]

Но передача json тоже по сути бинарный, не ?

[@VitaliySunny]

Верно, но передается текстовая информация (структура json - ключи, значения, всякие управляющие скоробочки и конструкции), когда как в gRPC только значения (структуру мы определяем на этапе создания protobuf). Т.е. gRPC в этом случае гораздо меньше по объему, соответственно быстрее.

[@Daleever]

отличный ролик

[@dan_feed8264]

я правильно понял, что можно переставать учить rest и начинать учить grpc?

[@zakirovio]

2:03 не PATCH?

[@uudecode]

Чот подумал, а что в grpc с bigendian\littleendian ?

[@faclokX]

Хотите сказать что для взаимодействия с Docker-Compose их контейнерами? Юзать TCP не логично?

[@user-bk9dt5li5n]

Меня тут на собес спросили: а можно ли через http реализовать асинхронную интеграцию? И что - то я подвисла) Помогите, знатоки!

[@milton4691]

Жду видос по эластику

[@panda58dev]

Жду видос по мантикоре

[@Hadagan_man]

Мне интересно что за микрофон у Диктора ))

[@user-jx2ne8qq6p]

Сделайте видео про Unix сокеты пожалуйста

[@stari4ok702]

Предположу, что REST нужен там, где не нужна потоковая передача данных и мультиплексирование, но конкретный пример в голову не приходит. Кидайте свои мысли камрады :)

[@GladSpiR]

Когда нужен синхрон , наверно тогда REST

[@nevdupIenysh]

Rest и на асинхронном пишут

[@user-uq5zi4xp7u]

А ответ на вопрос можно ?)

[@Aleksandr37rus]

Rest лучше в названии) простота а еще независимость.

[@flaviusaecius7021]

Все круто. Но я ничего не понял

[@qlobik]

Сделайте пожалуйста Видео про ISCSI

[@DoggerProgger]

8:37 очень много кодаааааа не супер нужного, но если очень много денег и времени, вполне можно попробовать

[@Serofim2013]

❤

[@svinoswag]

Сделайте видео про сокеты на трансплртном уровне пожалуйста

[@Qiqpop]

пришел по зову из телеги

[@Madgav777]

И правда, наконец, стало понятно! Как будто ангельской золотой дождь на темечко пролился. Хотелось еще немного по минусам grpc послушать

[@user-zy7ug4sl6z]

⁴⁴⁸

[@user-sk1zz6on8g]

а 👉а 👉

[@user-sq3rf6tg7f]

Рест умер , вкатываемся на grpc?

[@asedael5519]

Не-а, для микросервисов больше эта технология.

[@Naumkovich]

Жесть, пчел юзает мёртвые мемы и то криво ( Помянем

[@v.lavrinovics1970]

Автор видео, вы куда то очень торопились?

[@merionacademy]

На троллейбус только, а что?

[@user-rg6gi5ve1g]

😂😂😂бляяя Ахаха Эта бабка со свечами разорвала меня нахуй)

[@RustamMajidov]

Что за ересь? Где лягушонок с компуктером?

[@100BAXOV]

САМЫЙ ОТВРАТИТЕЛЬНЫЙ САЙТ У ВАС