Why gRPC is Popular

[@Dht1kna]

Ridiculously dense and efficient way to teach. Amazing, thanks

[@Mr.Andrew.]

Please keep feeding me important system design information across my lazy entertainment feeds! You make me smarter while I attempt to be lazy. Kudos!

[@David-gj6dc]

I also want to note you don't need to use gRPC to encode your data using protocol buffers. You can still get a lot of the network savings on your REST endpoints by leveraging protocol buffers by itself.

[@rmidifferent8906]

It also works other way around - you don't need to use protocol buffers with gRPC. It is the default though

[@mendyslam3986]

Got a specific resource I can study to get more insight and knowledge on how to leverage protocol buffers on REST endpoints

[@mamupelu565]

What is a buffer?

[@lpjunction]

@@mamupelu565 Some sort of waiting room.

[@David-gj6dc]

@@mendyslam3986 It's not that complicated actually if you just want to use protobuf and not understand the encoding itself. You just need to use a protobuf compiler (i.e. protoc) to generate encoders/decoders for your language of choice. Then use that generated code at each end of the network

[@laughingvampire7555]

10 years ago I remember people talking about REST and reminding that "all of this comes in waves, 10 years ago we were talking about CORBA & RPC, now we are talking about REST in the next 10 years we are coming back to CORBA or something similar" and here we are.

[@Rgotto2]

Cobra is wild to bring up. We have came along way

[@pajeetsingh]

Just send packets Jesus Christ!

[@Alexis-yg2xi]

"CORBA uses an interface definition language (IDL) to specify the interfaces that objects present to the outer world. CORBA then specifies a mapping from IDL to a specific implementation language like C++ or Java." Yeah, that sounds like gRPC 😅

[@straightup7up]

Remember CORBA? Generate client/server code from CORBA IDL interface definitions, that's essentially gRPC minus transaction propagation you get with CORBA.

[@rajeshdansena]

Wondering, How does the auth. is managed?

[@darogajee3286]

​@@rajeshdansena have you got any answer how to handle.... Authentication in gRPC

[@rajeshdansena]

@@darogajee3286 Nope!

[@antonkuranov]

Remember my pain with impossible to debug serialization faults when the consumer's IDL version does not correspond to the producer's one. Reading stream byte by byte and comparing structures field by field...

[@straightup7up]

@@antonkuranov I hear ya, been there

[@ShortFilmVD]

Ah, takes me back to the 90s 😂 a fair few big-name companies in the UK are still running Perl codebases that talk to each other over RPC, never needed replacing

[@supriyochatterjee4095]

Best teaching of most difficult concepts in the world in the simplest way.

[@charliesumorok6765]

Besides the format discovery in REST, REST and gRPC can give nearly identical network performance.

[@jamesevans2507]

Sorry, false.

[@thedevmachine]

BS

[@oncedidactic]

best quick synopsis on this I've seen. thanks

[@conundrum2u]

what a lot of people don't realize is because protobuf is a binary format, you have to be very careful how you change your message format and who has access to new message formats in a certain time frame. I'd recommend grpc for high load services that don't change much. versioning becomes necessary.

[@RichardCurrie]

In practice it's not a big deal? Don't change the field numbers or repurpose numbers for other purposes? Certain type changes are compatible and protos themselves can be renamed

[@conundrum2u]

@@RichardCurrie I'm speaking from experience. Consider long running, state machine type of services where messages/data can exist in storage over months or longer. protobufing everything carries a cost. sometimes in the form of extra testing or services breaking in unforseen ways.

[@frodej6640]

@@conundrum2u Is there a difference from the json/xml way of dealing with this? If I change/delete an element in doc, that could break the other side. But adding new elements should be tolerated by the other side. So when "breaking changes" is needed, you need to come up with a way of bridging old and new elements on both sides.

[@conundrum2u]

@@frodej6640 the json de/serializers I'm used to using are pretty flexible when it comes to missing/added fields. of course you're going to use validators before or by the time it hits your service layer. if there are extra fields in the message, they're ignored, and missing fields are handled in an implementation specific way (usually null or defaut value). with either xml or json you can enforce strict conformance for the entire message, and that brings it closer to what protobuf forces you to do. but the binary format for protobuf is very specific, and that's why it's so efficient. if you change the number of fields, it changes the size of the package and throws deserialization off. protobuf de/serializer also may throw an error because the message version itself isn't forward compatible. the truth is you can come very damn near protobuf/gpc speeds with json de/serializers if it's a forward reading (not buffering), field order specific message like protobuf does. I'm not saying don't do protobuf, but with all things there are tradeoffs

[@PaulHobbs23]

Protobufs are explicitly created with the design goal of being changeable over time in backwards compatible ways. If you ran into incompatibility problems in practice, that’s a skill issue.

[@WhiteDoppler]

gRPC is pretty neat, only problem comes when you try to deserialize an empty buffer into a simple data type, which can result in a valid message object from invalid data

[@miss-astronomikal-mcmxcvii]

Learning gRPC and Protobuf now! Very interesting, I like it :)

[@705tv]

You are definitely one of my favorite KZbinr/Teacher.. 🙌🏽😂

[@WilliamDye-willdye]

*Reduces boilerplate

[@ByteByteGo]

Thx. Good point.

[@seheyt]

In fact only automates it

[@MasterSergius]

But it doesn't support some datatypes and no custom validation, thus you should write some big wrapper in most cases

[@MuchlisNopq]

nullable value also ugly

[@AllanSavolainen]

I hate it for public APIs, fine for internal ones but classic REST APIs are superior and don't require any libraries to work

[@ayoublaarouchi]

What is the difference between grpc and classic rest apis ? Can't you make rest apis using grpc ?

[@KebabTM]

Are you complaining about gRPC vs REST or Protobuf vs JSON? Those are 2 very different arguments.

[@AllanSavolainen]

@@ayoublaarouchi I recommend playing with Firebase with Curl only. It is fun :)

[@AllanSavolainen]

@@KebabTM Just please give me simple url where I can point Curl and get an utf8 result back. For public APIs. For internal use, do whatever you prefer.

[@KebabTM]

@@AllanSavolainen Yea perfectly fair to expect a human readable result from a web API. As long as it doesn't require a persistent socket, REST is the way.

[@demogyani2419]

Don't worry in few years we will have gSOAP and gREST😂. This field always goes through full circle.

[@lhxperimental]

Exactly this is CORBA all over again

[@MagnumCarta]

My backend code kept failing when I returned g-ints but after I replaced it with g-strings everything worked as intended!

[@aurinator]

Surprised Rust's Tonic wasn't listed along with all the other languages.

[@annoorange123]

I cringe every time people mention REST in this discussion. Not once has JSON over HTTP mentioned in Fielding's dissertation. REST is agnostic to underlying protocols

[@呀咧呀咧]

Straight to the point, nice

[@nonamehere9658]

System design in KZbin shorts - I feel old because of this.

[@1989arrvind]

If you need top performance, grpc delivers, Great words from really Great highly enthusiastic person 👍👍👍👍👍

[@alessiozamboni4694]

is not really smaller... in terms of size, the library needed is huge and quite complex. You can leverage Protobuf (the serialization used on gRCP) on lighter protocols to have lighter and smaller applications

[@SatyamKumar-bw4vi]

faster and language-independent, in our Technology (5G & 6G) also we are using gRpc.

[@niknt]

Could you please tell us what kind of data you transfer via gRPC?

[@troooooper100]

So anywhere a rest API could be used. Can we use GRPC and what kind of data are we sending? Is it like a get request or post request. Is the data streaming. Does it have to be on the same stack? Meaning can the apps that are talking to each other be on different servers under different networks?

[@SatyamKumar-bw4vi]

@@troooooper100 Rest Support Http1 & gRpc Supports Http2 Anywhere Http2 is used, GRPC can be used but it is complex to implement as compared to Rest. GRPC uses Proto buf to send data, so any data that can be sent is converted to protobuf & again at the receiving end is decoded.

[@troooooper100]

@@SatyamKumar-bw4vi does encoding and decoding add significant delay, enough to negate performance gained by not using json

[@troooooper100]

@@SatyamKumar-bw4vi I'm pretty sure all apps probably send json though proto buff

[@NickTheCodeMechanic]

Ok, gotta try grpc in c#. Already have blazing fast frontend and turso/mysql views. This would help my thing architecture 😊

[@genma986]

*heavy breathing* You had me at typesafe

[@HemitPatel-s3f]

best for server to server (interserver) communciation!!

[@jcdelacruz4984]

I encountered a significant challenge in handling custom business errors across microservices.

[@obijan42]

I remember this from like 30 years ago. It was using XML then. which solves all problems /s

[@Asto508]

Doesn't solve the ugliness of XML though

[@MK-lh3xd]

Are you referring to CORBA?

[@leezhieng]

@@Asto508 at that time they were trying to minimize the code base and stick to XML, since HTML is basically XML, so it doesn't need extra code or library to parse different types of formats.

[@blaaaaaaaaaaaaargh]

And slowly we're going back to WCF

[@trialappsemail3915]

Great channel ❤

[@purdysanchez]

I encountered a bunch of Chinese guys who wrote their own protocol on TCP. They got super pissed when I pointed out that gRPC was 40x faster. But they still write software for the stock market.

[@Kenbomp]

Proto buffers have been around for 10 years , top tech moves real slow

[@BeastinlosersHD]

gRPC is super old

[@Fran-kc2gu]

First papers were from 2006-2008 don't remember exactly, even more than 10 years

[@Rachelebanham]

CORBA was a bit on the heavy side to be fair whereas gRPC is a bit more lightweight. Annoyingly it doesn't work well with Unreal Engine. We had to do quite a bit of hackery to make it work. But for python apps it's excellent.

[@neonmidnight6264]

By far the best tooling for gRPC is in C#

[@mohinicoder]

we are using protobuf for our web api response time. but we are not using grpc, still it works well.

[@tracy_gao]

Yea, 99.9% of services do not need gRPC unless you want to build a live chat app or low-latency trading app

[@LuisCardozoC]

We use Thrift in my company. Can you make a video comparing both gRPC and Thrift?

[@leezhieng]

Web developers keep reinventing the wheels and make things more complicated

[@vyrp]

At 0:46, there seems to be a typo on the 8th bullet point: "The DaC$#rt language"

[@theo1103]

nice to know

[@thegrumpydeveloper]

How’s debugging? If we could toggle some understandable version on off that’d be great.

[@systemBuilder]

At google the standard "Hello World" program is 300MB, it includes a web page (www.google.com/rpcz) that gives counts and samples of all gRPCs. That endpoint is deleted by the google load balancer but you could see all ~15 z endpoints (such as /varz, the monitoring vars) until about 2005-2007.

[@vuthien6960]

Please have a video to compare GQL vs gRPC

[@muzzletov]

graphql serves a completely different purpose

[@__hannibaalbarca__]

Every one tell C is old language, until realizing that entire networking make it by C.

[@leezhieng]

my company's interns are so anti C like it's some kind of monster

[@Soma2501]

Doesnt rpc increase coupling between microservices? When does it actually make sense to use it?

[@RayZde]

They are passing json data through grpc.

[@zephyrprime]

HTTP for remote procedures was always a dumb idea. gRPC is no doubt better because literally anything is better than than SOAP/REST but why use http still for this? UDP is a more reliable protocol.

[@botyironcastle]

why would that be more reliable

[@voidbinary]

Maybe this is a dumb question. But how exactly does it reduce boilerplate yet auto generate client/server code. I mean isn't that exactly what a boilerplate would do. Generate on a given set of rules and just handle inputs? Also. Did we have some sort of big AHA moment in the last decade that made us be like hey let's create HTTP/2 and allow it to handle more at once so we can do more with less? Like. Couldn't we just define one protocol that is scalable for whatever need? Need 5 packet concurrently? No problem. 20? No problem. etc. I can understand we only develop what we need at the time, but if we know already what types we need and know time increases the amount of it. Why not just make modular protocols?

[@IsmeGenius]

1. It doesn't reduce boilerplate, it reduces the need to write it by hand. 2. As pretty much everything in software engineering, it is hard to predict what exactly will need tomorrow and even harder to work around or banish cruft resulted from wrong predictions.

[@systemBuilder]

You write a language-independent interface with types, interface name, and a set of function calls. Press a button and all the code you need is generated (in java, python, or C++, and probably other languages are available, too). That boilerplate is treated like assembly code and so your codebase does not have any hand-written boilerplate.

[@rtm876]

You can use 'protoc' official utility that makes libs for most languages, even for grpc-web/typescript

[@ryuuzakiuchiha9712]

could you talk about load balance with gRPC?

[@muzzletov]

well, theres no official protobuf compiler for rust

[@ebenolivier2762]

Wow. Microsoft has COM+ in 2000 already that did exactly this.

[@VVIan-cn5cs]

Seems like what Thrift can do as well.

[@priyeshgupta164]

Will you make a series on gRPC? Or recommend something M

[@jo-fe9mb]

protobuf is painful

[@user-wr4yl7tx3w]

What are the current options before this?

[@Dychord]

"Faster, Smaller and Time Saver" well it's not just the gRPC buddy!!

[@janvandermeer6159]

Go back in time some decades and replace gRPC with CORBA. Anything new here?

[@saulotarsobc]

Vou tentar aprender isso aí. Tentar e conseguir 😅

[@waynes84]

Are top companies changing to GRPC in their services? Or are you making that up?

[@praveens2272]

Recently LinkedIn switched to gRPC from rest protocol. gRPC is next gen rest

[@charliesumorok6765]

gRPC and REST are for different use cases.

[@praveens2272]

@@charliesumorok6765 what are the use cases, can you describe it.

[@x4fingers]

Who know a little bit always talking shits, gRPC not the competior with REST.

[@iggusify]

Why not JSON-RPC? It seems more convenient IMO, because you don't need to generate any stubs.

[@Alwaysiamcaesar]

What the heck is this, an ad? There’s very little actual information here

[@ClashClash89]

cool... no clue why youtube's algorythm thought my smoothbrain would understand anything ^^

[@MohammadRezaYusufy]

So why didn't you tell us about the disadvantages of gRPC

[@nithinb9671]

It's just that protobuf is a protocol that can be used to create binary data instead of json or XML. So just wondering what if we use pure binary with rest. I feel that will be better than this grpc. Considering rest supports only json is not appropriate i think

[@muzzletov]

the typical rest backend uses http, not some binary mixture of http2

[@Frank-xu2ed]

asn.1 is finally back 😅

[@Pharisaeus]

The real answer: because zoomers don' remember RPC and CORBA and they believe they invented something new. It happens every few years in tech.

[@bruceliebewilma]

Ok so good. Well tell me the drawbacks

[@charliesumorok6765]

The format of the messages is not discoverable.

[@tensor5113]

It’s sometimes not faster at all and screwing up a very specific deployment method will make it slower than a basic rest api call

[@bruceliebewilma]

Oh really@@tensor5113

[@christianrazvan]

So how is this different or better than the wcf from microsoft?

[@RiversJ]

I've switched to it in my personal projects, can't at work as I'm the only one even remotely familiar with it at this point I think.

[@portusdelphini]

So where is websockets gone? Why do we need grpc?

[@AshishKumar-kv4hr]

What are the cons? Is it an alternative to rabbitmq, kafka?

[@JulienReszka]

Thx I didn't know that

[@recoveryplanx]

FlatBuffers vs MessagePack vs CBOR vs gRPC?

[@changtimwu]

anybody know how to make a static diagram get animated in this way? Assume the diagram is made with SVG.

[@Nekroido]

People love gRPC because it allows them to build distributed monoliths instead of designing proper scalable event driven microservices

[@spookycode]

Since when are micro services proper? Micro services add so much processing overhead that it should only be a last resort. Monoliths can most of the time get the job done quicker

[@Nekroido]

@@spookycode You are right about monoliths doing job quicker, and missed the point I was making. With a distributed monolith we also have to deal with latency, data loss due to network errors, race conditions, introduce caching for heavy stuff. Oftentimes it can't even scale horizontally which sort of defeats the purpose of splitting single codebase into gRPC-powered chunks. It's still a monolith that only pretends to be a system of microservices along with their issues and complexities, yet with barely any tools for common problems and inability to easily scale via instance replication. Each project has its own requirements, so I don't agree on using microservices should ever be considered "a last resort". What that even supposed mean?

[@BeastinlosersHD]

@@Nekroido Tbf, google made it, and google just doesn't have those problems anymore (and actively work on them with dedicated teams)

[@Nekroido]

@@BeastinlosersHD google made what?

[@BeastinlosersHD]

@@Nekroido gRPC specially (originally the g meant google but they changed it to mean gRPC). It’s old as dirt

[@alshaifhir]

How do you horizontally scale and authorize?

[@piotr780]

so gRPC make difference only in case of massive number of requests ?

[@SrinivasNirvana]

Debugging will be very hard

[@goldfinch5522]

How such animation are made

[@alizaaliza253]

The guy looks like RM for some reason

[@justingiovanetti]

What are the diagram animations made in?

[@ubayyd]

mad ting bruv

[@niknt]

Thank you for the video. I wonder if we have highload service, does it mean that we should use gRPC instead of REST?

[@raccoon0413]

I was about to ask this too. What’s the cons from using it?

[@harmandeepsingh8287]

Do not use it unless you are trying to build something where you need extreme optimizations

[@SatyamKumar-bw4vi]

Grpc is a better choice we have seen this in our product.

[@SatyamKumar-bw4vi]

@@raccoon0413Complex to implement

[@charliesumorok6765]

You can use REST over protobuf.

[@mylaluna]

Any content about http3

[@vetrivendhan6122]

What is it use-case?

[@kinershah464]

What about DDS (OpenDDS)? Is it better or worse than gRPC?

[@dangkhanhlinh476]

thanks you! Why is it open source so far?

[@nickheyer]

Even mildly complex enterprise applications and "autogenerated code" is a recipe for disaster. 99% of the time, it results in technical debt and some very hacky workarounds. Sounds like something a PM would pitch to an executive lol.

[@teckyify]

Well that's not what I've heard and been experiencing. People actually moving away from increasingly more complex protocols and standards.

[@EMWMIKE]

Anyone can give a real life example where it is a performance issue in a regular json over https request and needed grpc???

[@xiaoshen194]

Which one to prefer among gRPC and tRPC if I prefer typescript only?

[@mohameddhiazoghlami9802]

They are not the same thing

[@reece5706]

If you have to ask, then tRPC. I would recommend something like ts-rest if you just want typesafe APIs tRPC is quite a complex framework under the hood, so unless you need all of its caching, batching etc that it does then stick with plain ol rest

[@reece5706]

@@mohameddhiazoghlami9802they are actually remarkably similar, you can draw ALOT of parallels between them

[@AngusMcIntyre]

Good luck getting your midsize shop to let you use service contracts. Everyone is addicted to rest

[@seheyt]

"This eiliminates boilerplate"? On the contrary, it automates it. And then you cake on some layers to interact with that boiler plate because, by god, the code that's generated is not pretty

[@VaibhavSharma-zj4gk]

Everyday new technologies

[@leezhieng]

Everyday reinventing old technologies

[@rishabhgupta4133]

I want this guy brain

[@manoelramon8283]

except if you need to transmitt few bytes.. on this case the overhead is inevitable

[@amwtkeamwtke6543]

In short, cause it was made by Google, and no more.

[@Petreonvitor]

gRPC is better than websockets ?

[@rtm876]

GRPC in web works best using websockets (Improbable-eng) or WebTransport API (HTTP/3). Other ways, GRPC is slower than even JSON/REST because it also works through XHR and HTTP/1 but still needs additional encoding/decoding + proxying for GRPC-web. So no, websockets are better - they already good for production for what you probably want to achieve from GRPC, but that's a situation for web.

[@666KING6666]

O tempora, o mores! So basically, more efficient and more opinionated WSDL

[@complexity5545]

I am trying to figure out if I want to build OpenAPI, GraphQL, XML+WSDL+XSD, or now this gRPC stuff. I chose OpenAPI, but I am second guessing that because it uses YAML or JSON files and I hate both of those. I also hate Nodejs which is what all the good tools run on. Its seems like I'm running on a hamster wheel. All these new techs, but there is no improvement; nothing but opinions everywhere.