What is gRPC? (Remote Procedure Calls)
Vložit
- čas přidán 12. 08. 2024
- Microservices → ibm.biz/What_are_microservices
IBM for Cloud Native → ibm.biz/Create_Data_Fabric
Are you using REST APIs for your microservice-to-microservice communication? There’s a faster, more scalable solution: gRPC. It is a modern communication framework from the Cloud Native Computing Foundation that simplifies the language-dependent code required for microservice-to-microservice communication; it also reduces the need for custom validation code for the receiver. In this video, Bryan Truong covers the advantages by way of example.
Download a free AI ebook → ibm.biz/Free_AI_Ebook_Now
Get started for free on IBM Cloud → ibm.biz/Free_Cloud_Account_Now
Subscribe to see more videos like this in the future → ibm.biz/subscribe-now
#AI #Software #ITModernization #GRPC #lightboard #DataFabric
The first ibm video I’ve found useful. This guy knows what he’s talking about
He literaly aaid.nothing of what GRPC is.
In a nutshell, when we deal with a microservice architecture, we often need to somehow communicate from a microservice to another. This can be accomplished in quite a few ways: for a serverless architecture, for example, we could implement streams and query systems (AWS provides DynamoDB streams and SQS), for a typical (not serverless but actual servers) architecture, we can use a message queue like Kafka to keep services decoupled: i.e user signs up, user service creates the user and publishes an event and job done. Email service, which is subscribe to 'user-signup-event' will pick that up and send an email, for example. This is communication between microserverices in a decoupled and very good way. gRPC is a way of achieving this without a message queue by straight up call a function (procedure) from another service (thus remote) and do the job. Same result, different way. This is what the video should've said.
Great breakdown… Love this guy’s flow
This is a great informative video but a couple key points I think were missed/not as explicit:
The binary serialization of gRPC messages is language neutral; meaning a component written in Java using some gRPC proto is interoperable with a component in C++, Go, etc,.
HTTP 2.0 can utilize HTTP streaming capabilities which is sufficient for high bandwidth performant applications. gRPC has this implemented with the “stream” proto keyword that can be used for defined RPC call. This feature supports both uni-directional and bi-directional streaming.
Backwards compatibility. One of the foundational reasons for gRPC’s inception was to avoid API breaking updates for new features. For example, imagine you have a bunch of client applications using a 1.0 iteration of your proto definition but your server upgrades to a 2.0 definition. In most other communication apis, all client applications would have to update to comply. However with gRPC this is not necessary, new fields are simply ignored by older client implementations. The key rule being you must keep legacy fields in proto files in the same place (the numbers in proto files dictate the position in the binary structure along with the size of the field).
Another really nice feature of gRPC is the ability for multiple gRPC services to bind to the same server socket. This does require a single server process for this methodology but is useful for micro services that may need to provide multiple rpc calls. (No need to allocate a range of ports for services).
Hope this info helps someone jump into gRPC! Here’s a link to my GitHub for anyone who’s interested: github.com/xTriixrx
Thanks. I learned a lot. 👍🏾
Thanks, Vincent. This was helpful
@@sillystuff6247 I believe their are numerous inaccuracies with your statement however I will just simply say that HTTP is not backwards compatible and is a transport protocol which doesn’t have any knowledge of the packets’ form it delivers. HTTP will never evolve to what you’re describing as it implies knowledge of the packet form and what is being carried. gRPC was created due to the need for high bandwidth web based applications and keep backwards compatibility not to replace CORBA (CORBA isn’t even web based, and it’s an ORB model). Their will always be a newer and better technology, literally our industry is built and sustained on that principle.
PS., for context the HTTP v3 spec does more to advance existing v2 bandwidth capabilities (further improving gRPC in future) rather than what you suggested.
Thanks @xTriixrx ! I wanted to give the lecture quick/light (I am the presenter in this video/this is my personal account), and you make some good clarifying points- thanks for the additional context 😄
@@bryan_truong hey bro nice comtent. Wish you made more contents on your channel as well. Your explanation is clear. ❤
Also, since proto schema is defined before generating stubs, the messages don't have to contain full keys. This actually saves a good amount of space.
this is the best lecture i have heard on gRPC.
Clean and simple explanation , perfect intro. Thank you.
The main focus of the rpc framework is on service-to-service requests, typically owned by the same organization within the same data center. RESTful APIs have other benefits. It is suitable for experimentation and debugging and has a diverse ecosystem of tools.
7:15mins of clean and good information. This helped me, thank you 🙏.
Wow! So Informative and well explained!! Thank you Mr Truong!
it's a really amazing powerful time saver. If you were around for COM & MIDL, gRPC & protocol buffers will blow your mind!
Found it really helpful. Gonna explore more into it.
Worked with gRPC it also had performance issues when serialising collections. Maps, lists. We even had to convert to JSON string those collections and send them as string field og gRPC model.
Maybe it is version specific but if you need to build fast services test serialisation performance for your particular data structure. From my experience it is not always linear depending on data volume.
i did my own tests, and for objects with 1000 small objects collections in it, there was almost no difference in speed between REST and gRPC.
for small data trees (like just few objects nested), gRPC half the time of REST (latency)
Very useful. Thank you.
Really great video. Thanks!
Great content! This helped me understand
This is an amazing tutorial. Short and crisp! Looking forward to more videos!!
Thanks! I no longer am with IBM, though, so check out my personal CZcams channel for my other stuff
Very good tutorial
great. thanks
Feels like enterprise has fundamentally different needs (and thus addressment) of issues I’m not to worried about as a small business
My main question is how do you write backwards? Very impressive.
I cant stop thinking about it whole time :D Maybe its turned horizontaly somehow...
He wrote on a transparent background, they recorded the video with all the text in reversed. Finally the video editor tools did its job by flipping the video once again and we can see the text in normal writing direction
Its called Light Board... check it out in Google/ CZcams.. you dont need any editing skills.. the board will take care
I always find it funny how surprised people are when they find out that mirrors exist.
great video
Great video, although i would've loved a small section about gRPC coordination
How is no one talking about the fact that he‘s writing backwards?! What a unique skill to have, that is so useful here. Such a kool setup and style of presentation. Well done!
He is not, the video is mirrored
@@diZrupt0r or he used to serve on a submarine bridge as a seaman.
is gRPC scalable? in terms of architecture it's a direct calls to the service instead of having event bus or queue to propagate message through
can be messy. unless you're creating a gRPC gateway to propagate the messages to the microservices
which adds things to build
Is it a re-upload? I watched the same video couple of days back. Not sure I had some crazy time travel 😀. Thank you for the video Brian.
You're right. We had to make a minor correction to the video, so we re-uploaded the video. Sorry for the confusion.
No problem, thank you for the video!
Nice video, can I use gRPC in a EDA Architecture?
AWESOME
It's really funny, because in a well designed microservice system, they are not making a lot of calls to each other, making gRPC less useful the better designed a system is.
tks
but where does the Remote Procedure Call part come in?
So protocol buffers are essentially language/platform agnostic schemas?
Great Information. I have a quick question. What is the technology or tool that you use to write on a screen like that?
Search on "lightboard videos".
I don’t understand what is the difference between gRPC and google’s protobuf ?
Energy of a school report.
How did they flip the writing board? If he's writing onto a transparent surface and we should be seeing it flipped from the other side. Neat setup 👌
Correct, we flip the image in post-production.
@@IBMTechnology Wow you guys put in a lot of effort into this 👏 I still can't figure out how you shot the video - if he was writing on a transparent screen, you would have had to edit out the screen and writing on the screen? In any case, really cool stuff 😎
@@IBMTechnology What’s the tool used for writing?
@@anarasi he's writing on a glass I guess
Fast way for creating distributed monolith
Good summary
Does anybody know a good router for gRpc messages?
Speaker says that we would have to import gzip library to perform gzip in our microservice while with grpc we dont have to. So how our data is being converted into binary when we use grpc? I assume that at the end of the day we also have some grpc dependency in our microservice to perform this conversion. If thats the case then i dont see the difference and dont know where is this convenience? :)
Does anybody know what he is using for the graphical representation? It looks cool!
Search on "lightboard videos"
So, compression is done by gRpc? How about encryption of messages?
encryption happens when using https to transport your gRPC messages
Is encryption necessary? I assume this is mostly used between 2 systems who are completely in the backend, so communication is hidden from the public?
Technical nitpick, but binary serialization isn't compressed, it's just more space-efficient than text serialization
Is it good for services in micro services to directly communicate?
Not ideally, as microservices are then somewhat more coupled at runtime. One can still independently evolve microservices, but you have to manage backwards compatible API changes (or running two API versions at the same time, for a time) and make your app capable of a zero-downtime (blue-green) release. The advantage is it is perhaps easier to understand and debug, but as with everything it is a tradeoff.
Honest question: Isn't it considered best practice for microservices to not call each other?
As a general rule of thumb yes however sometimes it’s unavoidable, some application domains are just very tightly coupled problems (signal processing, satellite telemetry, etc.). Tightly coupled microservices are a lot more manageable then a giant monolith.
they don't need to call each other directly. Usually a de coupling layer like message queue will be placed in between, so microservices sort off request other microservices to do the task at later point in time by placing that request onto the queue.
Did they reinvent the wsdl?
Well… I’m thinking about the truly “convenience” when you have to import the same library in different codes and creates new layers of configuration to deal with the descriptors of the services… looks like an kind of SOAP protocol.. and binary the communication to improve performance… it’s ok.. but.. that’s it ?? Nothing more ?
interestingly Kryo serialisation is still way faster and produces smaller data, however is not a standard and not used for interoperability :/
Unfortunately, this was way over my head. Maybe this was more for another audience, but I didn't quite get what a gRPC is from this. Let me look at it again...
You don't have to implement gzip compression of JSON data, because http server will do it for you.
This guy is pretty smart! I bet he spends a lot of time studying at a top university.
SOAP ? XD
Heater 🔥🔥🔥🔥
How you do you transmit the json string without serialization? anything that's sent over the network is serialized right?
so json is also transmitted as binary?
gRpc serializes messages in its own way.
The json string is serialized as utf-8 string, meaning each char in the json string can take up to 4 bytes. With protobufs, 4 bytes are enough to send a whole integer (32 bits) and you don't even need to transfer the key string because it is defined by the protobuf layout you write :D How cool is that
Ultimately if you're sending it over the network it must become binary, yes. The difference perhaps is that for gRPC, you convert an object to binary straight, whereas in JSON, you convert object to string to binary, which is more expensive. The JSON byte representation is also more verbose in including keys and in how it formats different types (though you can compress it with gzip, which helps).
Can I ask what sofeware are you using to record this kind of vedio?
How is he writing in mirror image so effortlessly?!
It's filmed through a glass pane and the image reversed in post-production. That's why you'll see a lot of "left-handers" in these videos. ;-)
Being a left-hander, I'm just curious whether inverting the image would make my handwriting more legible like that of a right-hander! 😉
@@vdpoortensamyn 😃
hi, is grpc only for MS or Server client like spriing boot and flutter great? how this think know url adresses like Rest?
Mmmm so it remainds me of RMI
Beware size limit 4 MB.
The 4 Mb limit only applies to the request message, the response has no limit... gRPC also supports streaming
so you re-invented soap?
You guys should consider slides tbh.
you should not have to do anything special to gzip requests and responses, plaintext or JSON. Just make sure your server is configured to do it. It will add the Content-Encoding: gzip header and the rest should work out on it's own. Any http client out there should already know how to handle that, it is spart of the http specs.
My guess is that he meant gRPC APIs are better suited for direct service to service communication, like for containers pushing actions to be made to other containers or so. As someone said on the comments, seems like gRPC binary encoding is less CPU intensive than gzip, so it's maybe reinforcing this guess.
Go bestie! Go bestie !
Does anyone knows, why my GMS soft soft is diffrent ?
Does anybody wonder how did this guy write with his left hand and in backwards?
See ibm.biz/write-backwards
eXcellent
so is he left handed or right handed???????
How is this guy writing backwards so effectively?
he is writing normally, as if people behind him are reading what he is writing, then the picture is mirrored (flipped for us viewers)
notice the he is left-handed?
there;s a 90% chance he isn't left handed in real life.
Do you guys really write backwards? Or it's just camera trickery? 😂
That's really the hard part, learning to write backwards. Kidding! It's flipped in post-production.
@@IBMTechnology I thought you people have some special skills man. For real. Same with Google guys making Android videos. 😂
REST is king. Anything else is just trying to get back to the dark ages of Corba and Webservices. I am quite sure there is some heavy payload situations that need gRPC but we should stick with REST as much as we could, and stop going back to the nightmares of yesteryears in the name of "we can do that with better performance."
Not quite, I'd say. REST lacks (or contradicts) RPC style. But in essence, cross service communication is usually far from resource orientation unlike front ends.
Agree. With except of graph
Ever read what restful is for? A lot of people think that everything that sends {} is a rest API. Rest is only for CRUD operations on a single extracted data, like account or transaction or item. For everything else, if you need to start some procedure, like login or register, you use gRPC.
REST has been hijacked from its originally intended use. The fact that clear interfaces are not enforced is a nightmare. However, it is relatively easy to be understood by a lot of programmers.
What about graph ?@@Readdeo
Not Understanding
“I’m not talking about communication between the front-end and back-end” [draws arrow anyway]
Cute guy
Unclear
Would you elaborate? Maybe the formal docs will help: grpc.io/docs/what-is-grpc/introduction/
bro why are you writing backwards. very distracting :D
very great video