What is gRPC? (Remote Procedure Calls)

preview_player
Показать описание


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.

#AI #Software #ITModernization #GRPC #lightboard #DataFabric
Рекомендации по теме
Комментарии
Автор

The first ibm video I’ve found useful. This guy knows what he’s talking about

shanestephens
Автор

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.

RusuTraianCristian
Автор

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).

xTriixrx
Автор

this is the best lecture i have heard on gRPC.

sainathmandavilli
Автор

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.

sekulim
Автор

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.

souryavarenya
Автор

7:15mins of clean and good information. This helped me, thank you 🙏.

phxm
Автор

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.

valentyn.kostiuk
Автор

Wow! So Informative and well explained!! Thank you Mr Truong!

pranavram
Автор

This guy is pretty smart! I bet he spends a lot of time studying at a top university.

Vim_Tim
Автор

My main question is how do you write backwards? Very impressive.

philipxiong
Автор

Found it really helpful. Gonna explore more into it.

abhishekk
Автор

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.

Tony-dprl
Автор

Clean and simple explanation, perfect intro. Thank you.

Purii
Автор

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!

gurki
Автор

Great video, although i would've loved a small section about gRPC coordination

hassanaoutof
Автор

I don’t understand what is the difference between gRPC and google’s protobuf ?

Bbduyg
Автор

Feels like enterprise has fundamentally different needs (and thus addressment) of issues I’m not to worried about as a small business

dixztube
Автор

but where does the Remote Procedure Call part come in?

dorktales
Автор

it's a really amazing powerful time saver. If you were around for COM & MIDL, gRPC & protocol buffers will blow your mind!

richardclarke