Protocol Buffers in gRPC

[@artofsoul7518]

Easy to understand and learn... , Thanks for this information.

[@yashasmudiyar6054]

Excellent ! Good Learning - Thanks !

[@maniaharshil]

Woo really great .... Can't wait to use grpc...huge thanks for tutoring

[@pbznt]

Hi Stephane, I really like your videos about gRPC. I understand that a service can be both a service, and a client. For example, the purchase service at 7:20 is serving the mobile app stub, but it acts as a stub too. The shipment service is serving the purchase service stub. Following this logic, how could I store data to google cloud firestore from a back end service with a flutter front end? Flutter(Stub) gRPC_Server(Service and stub) Google Cloud Firestore (Service). I ask you this question because I am a beginner in mobile dev and I think that it's not a good idea to query database directly from the front-end code. Separation of concerns. Thank you!

[@dicolteja]

Thanks for great and simply explanation. 👍

[@msgarima07]

great explanation, thanks a lot! :)

[@krishnagupta6323]

Amazing man, thanks, saved a lot of my time by briefing me into this

[@Malagon194]

ayy yoh dude im trying to follow your course on gRPC and I find it pretty hepful but you may want to add some links in between videos to let people know which video to watch next lol.

[@StephaneMaarek]

Hi Luis, these are all video extracts. The full course is here: links.datacumulus.com/grpc-golang-coupon

[@joecaruso3756]

The byte comparison of JSON vs Protocol Buffers doesn't make sense. The strings had different content.

[@MegaMario0007]

Would gRPC replace things like redis or rabbitmq in service to service communication? Or do they complement each other somehow?

[@anhnguyenhoang7142]

' i get error with Nodejs ' 'protoc' is not recognized as an internal or external command, operable program or batch file. please help me ! thanks so much

[@rutger3188]

Hi Stephane, cool course, very easy to follow! I have two questions tho. - What are the downsides of protocol buffer? - On what literature or other sources is this information based?

[@rajeshg3570]

hi, you can find some details around pros and cons of proto buff here - kzbin.info/www/bejne/ameyaGaFo5War6s

[@Elzelgator]

Hello I believe you can see gRPC messages in side wireshark with HTTP2 Decoding

[@saumya1712]

Really a good learning, thanks Stephane. Could you please answer the following questions: Considering I am only concerned with payload size, then 1) What if I use REST api with binary data format to overcome payload size? 2) Which protocol is being used by RPC in general, and how it reduces the network overhead.

[@rayhuang8275]

1) If a REST API uses binary data for transmission, it would be very difficult to support crossing platform and language, just like you need to create a standard on your own. Even it is doable, it definitely requires clients to spend more time integrating the API. 2) gRPC is based on http/2, you could check the improvement comparing to http 1.

[@pawankumarmeena6737]

Thanks

[@mitos95176]

Why do you think the Protocol Buffer is not more widespread considering the advantages it has over JSON and do you predict that it will overcome JSON in popularity any time soon?

[@codelucky]

Do you think gRPC will take over GraphQL?

[@StephaneMaarek]

because it's a binary format and humans for now have to do extra steps to read the content. JSON is text format and easy to reason about

[@andy_lamax]

@@codelucky From the technical stand point, I think yes gRPC will take over GraphQL. But something kinda tells me that GraphQL can evolve support gRPC (If it currently doens't support it yet). If not, the I think one can use both GraphQL and gRPC to reap benefits from both

[@JimstrVids]

4 years later and still basically nobody uses grpc outside of seriously data intensive scenarios where nanoseconds matter. The additional grpc skill curve to make something marginally smaller isn’t practical for a lot of applications, nor are microservices. The dev world outside of tooling is still run by companies that for the most part have 1-3 base languages and a regular rest API does the job well enough. The customer is king in a lot of scenarios and the time it takes for them to get what they want is such that improving it by even 100% will often not change their mind. That’s my admittedly negative take anyway

[@AlexanderShelestov]

It's cool, except those things when protobuf doesn't have required feilds, set its own defaults, and doesn't allow to check if the value was really set: > Note that for scalar message fields, once a message is parsed there's no way of telling whether a field was explicitly set to the default value (for example whether a boolean was set to false) or just not set at all It produces a mess and we can't trust the incoming data. When in JSONrpc, for example, we don't have such problems. The bandwith economy (does it really a bottleneck? like, really?) costs too much this way.

[@JimstrVids]

I don’t really get it. A regular api can do all of this, and as long as clients and servers use json, it’s the same thing but a little slower. You say “any language can use this” but they can basically all use json as well, so that’s not really a benefit of grpc. Neither is how easy it is to implement. In fact we’re trading an improvement in speed for slowed development because while json is easy and inherit it knowledge of most devs, each team in your example, the delivery service, the buying service, the pricing service etc now needs to know grpc

[@JimstrVids]

And to boot, Amazon and Microsoft have both announced a path that diverts from micro services. Sure it’s popular and cool, but as far as practicality, who wants 10 micro services running instead of a single app?