Seriously. Every other presentation other than this starts talking about Transport layer, Serialization, L5, L6, L7 of the OSI model and all the stuff. Just tell me what it is and maybe then we can get into the inner details. This presentation nailed it.
gRPC is a game changer in microservices world, all the companies going to adapt it very soon. Its time to say good bye to REST-JSON. Instead go with gRPC-Protobuf. I made a complete gRPC Java Course, Check it out for FREE Complete Course on my channel. #techtter
It seems that a lot of talks about IPC protocols only really consider the fate of the thing that came just before it. It would be good to show how system-Y is less likely to die compared to numerous systems that come before; starting with the likes of ASN.1 (which started out simple enough, but died/marginalised due to design-by-commitee and resultant feature proliferation, and poor tool support). As an observer, I think looking at this of comparative analysis would give a good indication of when the system is suitably stable. At least, I'm glad that its an open specification which is largely driven by one large diverse body with largely technical interests at heart.
The bad and the ugly: - Load balancing: Can be mitigated by using a service mesh (eg. through ISTIO virtualservices) - Rich errors: perhaps just do one_of(message, rich_error)? Am I wrong?
The client lib creation and compiler belongs to protobuf not gRPC, and it was happening years before gRPC. Presenter convolutes Protocol Buffers with gRPC.
No. Protobuf doesn't understand about timeouts or RPC endpoints. I guess you could say protobuf is how you define what the RPC call takes as an input and what it produces as output, but the service / RPC call itself / timeouts / client lib creation is definitely gRPC stuff.
Its seems very easy to setup for internal services but nothing in particular for browsers, are there any javascript libraries we can use to implement for the web? what about the web?
I can't make anything work. Visual Studio nuget doesn't work, and can't find protoc-gen-grpc. I just want to get SOMETHING - the most simple hello world working. And I don't want a small application that demonstrates every aspect of gRPC. The very most basic command line procedure to compile and use a service; and don't assume I know Anything because nothing I do know seems to be useful. I'm just going in circles with documentation that doesn't actually spell it out.
this presenter makes me feel he enjoys bragging about his knowledge and understanding of the topic without "educating" the audience how to use the technology.
What about graphql, with it you get the same benefits without the drawbacks of grpc in terms of load balancing, error messages/handling, browser support, documentation, etc..
@@khaled_osman Ah ok sorry! Didn't realise you were asking. So lets talk at the architectural level to begin specifically at a networking level. HTTP2 vs HTTP1.1. You use HTTP1.1 currently, any time you start querying a graphql server, set up subscriptions mutations etc all that fun stuff. REST also follows this approach currently. So what does HTTP2 provide that HTTP1.1 doesn't? Well firstly, HTTP2 uses binary protocols to complete requests. What does this mean? It's faster to decode and encode the request, and it's more 'compact' over the network so it makes the network more efficient too. Allows for bi-directional streams. Allows for domain sharding. Those are 'some' of the differences between HTTP2 vs HTTP1.1. You'd be correct in saying those are differences at the Networking level and aren't a direct comparison between graphql and GRPC but GRPC does expose this functionality as GRPC uses HTTP2 as it's transport layer. So lets talk about individual differences. GRPC uses Protofiles as a way describing an API. So what's so good about this? REST can do a similar thing with YAML. Well firstly, Protofiles use a binary serialisation, which means the file size of a protofile structure will always be less that it's counter part of JSON or XML for example message Sample { string sample = 1; } vs { sample: "some value" } Now this is a silly comparison to be honest because the difference in byte size between the two would be tiny. But what if the response was bigger? Couple hundred lines? and that API is being hit thousands of times a day? Ok, now were going to notice the difference. Other benefits? So, another purpose of those proto files serve is in conjunction with protoc. Protoc can take your protofiles and turn them into a language client (if you've ever worked with an api large enough that's exposed to other customers they may require a REST client that exposes the functionality of the api in some kind of arbitrary abstraction of a curl request. Here's an example github.com/sendgrid/rest). Well now, with protoc and protobuffs you can generate those clients in almost any language and distribute them to a clients, customers etc eliminating the need to generate rest clients, AKA developer time. An example of such a command would be protoc --proto_path=src --go_out=build/gen --go_opt=paths=source_relative src/foo.proto src/bar/baz.proto protoc --proto_path=src --cpp_out=build/gen --go_opt=paths=source_relative src/foo.proto src/bar/baz.proto protoc --proto_path=src --java_out=build/gen --go_opt=paths=source_relative src/foo.proto src/bar/baz.proto 3 commands generating 3 clients in 3 different languages. Voila.
The python example at ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-RoXT_Rkg8LA.htmlm58s can't really work. You can't use the keyword `from` as a parameter name.
Excellent talk -- thanks! Just one thought. At ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-RoXT_Rkg8LA.htmlm30s he mentions the difficulty in modeling a "restart the machine" operation in REST; if you've been there, you might find this interesting: nicholassterling.wordpress.com/2014/02/16/rebootrestart-in-a-rest-api-using-put/
gRPC is a game changer in microservices world, all the companies going to adapt it very soon. Its time to say good bye to REST-JSON. Instead go with gRPC-Protobuf. I made a complete gRPC Java Course, Check it out for FREE Complete Course on my channel. #techtter
The existence of the new thing is usually motivated by a desire to fix / avoid the problems of the old thing. Trashing the old thing explains the why - why gRPC when we already have REST? And it is a bid for resonance in the audience. "You find these parts of REST annoying??? Me too!!"
Humour isn't meant to substitute valid arguments ;) Rest is Easy and rules the web, no reason to hype things that do not really solve the same kind of problems
Tried Zeromq before, have to admit it's a wonderful tech. But way more complicated ,especially if you want to use some of its advanced ideas other than req and reply
