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.
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
@@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 😄
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.
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!
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)
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
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.
@@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 😎
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.
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...
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 ?
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
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.
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.
Be mindful of the performance; gRPC may not perform as well as REST. Here are some reasons: 1. gRPC uses Protocol Buffers as the data serialization format, which is more compact and efficient than JSON for transmission. However, it may require more processing power to encode and decode, which could result in longer serialization times and higher latency compared to REST. 2. gRPC uses a flow control mechanism to prevent the sender from overwhelming the receiver with too much data, which can introduce additional latency. I recommend watching this benchmark comparison between gRPC and REST for further evaluation: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ZwP4ly03n00.html
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? :)
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.
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?
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).
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.
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.
