8 ms·
gRPC for Microservices Communication
- fhood 5y agoI've been seeing gRPC support in the various api-gateway solutions for a decent while now, was always interested in its use in the abstract, but having a human readable interface would be very difficult to give up, and something I personally probably wouldn't do unless I was bumping against some hard efficiency limits.
- kyrra 5y agoDepends on what your goals are. Protos give a nice API definition if you want to make sure you don't screw up that data that's on the wire (field name misspelled or something similar). Obviously JSON has OpenAPI (swagger), but I'm still a fan of protobufs (probably stockholm syndrome).
- snypox 5y agoHow do you replace Postman? I feel like it's pretty easy to test text encoding formats that are human readable, but not sure how I'd do that with gRPC.
- rileymichael 5y agoI personally use BloomRPC — just point it at your protos and go. (plus it supports grpc-web)
- travisd 5y ago+1 for Bloom. The only thing it’s missing is support for the gRPC introspection API. It’s not bad if you have all of your organizations protos in one repo (which is what we do), but otherwise annoying to have to clone a repo and point Bloom at the .proto file just to talk to the API. Other tools (grpcui I believe is one) support introspection but aren’t as polished at Bloom.
- CommonGuy 5y agoI would recommend https://kreya.app https://kreya.app as the Postman alternative for gRPC. It supports much more features than BloomRPC or Insomnia and has some additional goodies that will help advanced users. For example global authentication configurations or support for easy git syncing. Disclaimer: I am one of the creators of Kreya
- twistedpair 5y agoSwagger is handy here. Auto-generate your API model objects, interfaces, and REST clients in any language (e.g. Typescript).
- jayd16 5y agoGrpCurl helps a bit with this. https://github.com/fullstorydev/grpcurl https://github.com/fullstorydev/grpcurl
- baldeagle 5y agoIs this the path to a tightly coupled distributed monolith?
- ramesh31 5y agoYeah imagine if instead of just using plain text JSON for your web application you could use a proprietary binary format that web browsers know nothing about and require a translation layer to talk to. It's awesome.
- envyac 5y agoAgreed. Use JSON, proprietary binary formats are terrible, and 99% of the time the bandwidth savings aren't worth it. For messaging, I really like NATS (incubating in the K8S landscape - probably graduating soon). My fav thing is the wildcard usage in NATS.
- dasloop 5y agoUnless you are communicating C++ services for example and you prefer a lib that does the parsing and transformation to native object for you
- bitwize 5y agoBandwidth isn't the primary concern here. CPU time spent parsing/unparsing is. Depending on how your application is structured, it can actually dominate time spent in application logic. Whatever the case, it's simply waste heat being added to the universe. Use a little-endian, 64-bit-aligned binary format, and parsing overhead simply goes away.
- chuckcode 5y agoGreat point. I'm not one to over optimize, but seems like parsing messages for internet sized apps is worth spending a little effort to save energy and environment.
- jeffbee 5y ago
- the_gipsy 5y agoHow do you test gRPC? E.g. a gRPC microservice.
- spyremeown 5y agoIf you mean actual testing, we use a lot of mocks and this[1] little dude. [1] https://github.com/fullstorydev/grpcurl https://github.com/fullstorydev/grpcurl
- the_gipsy 5y agoAmazing, thanks!
- brown9-2 5y agohow do you test a HTTP/REST microservice?
- the_gipsy 5y agoAha so my tests should be gRPC clients/servers. Do we have something like the usual http request mock/interceptor libs?
- mirekrusin 5y ago"In the olden days, a software application was built as a large monolith (...)" - people should stop writing this kind of shit. You can hear this nonsense from some poor quality bloggers. People who are serious about it say things like "for most startups microservices is bad idea", "monolith should be starting point in most cases", "there is a price that comes with microservices", "modularised monoliths are often pefect fit" etc. this is coming not from random internet dudes but from Sam Newman author of "Building Microservices" and "Monolith to Microservices", Martin Fowler etc. Microservices/services/monoliths are one of design kinds, they best fit into different setups. References: * https://www.theregister.com/2020/03/04/microservices_last_resort/ https://www.theregister.com/2020/03/04/microservices_last_re... * https://www.youtube.com/watch?v=GBTdnfD6s5Q https://www.youtube.com/watch?v=GBTdnfD6s5Q etc.
- dastbe 5y agoyou can see a similar lack of understanding when they use a browser-based test of http/1.1 vs http/2 to justify the improved performance of http/2 for service-to-service communication. what that test is really demonstrating is the fact that your browser hard limits the number of http/1.1 connections it will make much moreso than it limits the number of http/2 connections it makes.
- jeffffff 5y agosure maybe the browser is limiting the number of http/1.1 connections, but it's not true that it doesn't limit the number of http/2 connections in a similar manner. it only creates one http/2 connection but due to multiplexing that is all it needs.
- Zababa 5y agoI especially dislike when people talk about microservices and scalability like they are a solution. Most companies won't see the kind of scale Facebook/Google/etc sees, not because they won't have that much clients, but also because there's a good chance that they don't need all clients in the same system. Most business don't benefit from the network effect. In that case, your scale is not the total sum of the size of all your clients like Facebook/Google/etc, it's just your biggest client! Also, I don't like how the discussion about "microservices" is drowning the discussion about plain services. Services are a natural consequence of Conway's law when your organization gets bigger. You can see parallels with the first wave of OO programming for software projects, where the goal of having a public interface and private internals was to make projects scale when 10/100/1000 times more people are working on it. This is exactly what's happening with services: a team maintain a public API, and private internals (and the developpers from the other team depend on the internals anyways because reality isn't that easy). Then it's easy to see what microservices are: ravioli code. In a way, services and microservices are OO programming in the Alan Kay sense: late binding, message passing, local retention and hiding of state.
- sjnair96 5y agoHave you guys run into the issue of gRPC being used for ML inference engines/platforms, and having the message size be an issue? Recently, I was working on building the backend for our Speech Recognition engine and it seems like the message size limit came in the way of being able to perform batch/offline inference. I might be lacking some of the intuition behind designing and deploying such services, and am curious if you guys have run into this issue. The platform doesn't seem to accept the channel options from the client. That and the issue of no easy way to do gRPC calls from a browser yet, and the resulting architecture then needing to have been built the ground up with considerations for an extra piece - a gateway, or something like Envoy to make it more accessible over the web. I feel like that would be okay if I was working on a project with k8 ingress set up already and already utilizing microservices. But for getting running it seems like added complexity. Not hating on it or anything, just sharing my experiences and thoughts, hoping that some of you might've had experience reasoning and dealing with such designs and can offer some insight.
- brinox 5y agoYou can configure the message size limit on your gRPC server, doesn't that fix your issue?
- sjnair96 5y agoAhh, we don't have access to the server. It's closed - an NVIDIA inference engine. Which under the hood talks to their Triton engine. Unfortunately, while Triton allows configuring the limit, the layer in front of it eats our channel options which have the message size configurations.
- CommonGuy 5y agoAnother option could be to "chunk" the messages with client-/server-streaming or bi-directional calls. But if you call your API from a browser, that may not be possible yet
- sjnair96 5y agoYes, but that would involve us digging into the code of the gRPC server, which is unfortunately closed to us :(
- georgeburdell 5y agoRelated question: is gRPC the anointed successor to WCF for .NET? I'm looking at a re-write of our mostly monolithic code at work, which uses C# on an old framework with a little WCF to communicate with one service, and got a bit concerned as WCF appears to be on the way out in the new .NET Core versions.
- sfblah 5y agoI think it basically is. I've done work for a company using .Net Core since about 2018. Back then, you had to use the Google stubs and work around a lot of the Microsoft host setup to get it to work. These days, gRPC seems to be on par with REST as a framework. That said, I'd like to see better support for C# code generation from proto files. For example, the support for nullable types works ok but is a bit cumbersome.
- Smaug123 5y agoNote that Grpc.Core is deprecated, and will be entirely unsupported some time next year. grpc-dotnet, which is AFAICT the only replacement, by design requires ASP.NET Core for the gRPC server. That is, there is no upgrade path for the .NET Framework or in situations where you don't want to pull in ASP.NET. (Please, someone tell me I'm wrong. Please.)
- vidanay 5y agoYou're not wrong. I was researching this exact topic just this afternoon. We are creating new clients using .NET 5 and talking to legacy services via gRPC. Unfortunately, the legacy services are .NET Framework 4.8 or 4.6, so there is no option to use grpc-net, only grpc.core.
- keithnz 5y agono, there are multiple alternatives, but from what you have said, perhaps using something like MassTransit would work well for you https://masstransit-project.com/ https://masstransit-project.com/
- gokhan 5y agoI love the cyclical nature of everything in remote execution world. Corba, Remoting, some XML sauce, WCF, Http methods and Url's, some Json sauce, and than gRPC. Same ideas. Just like having flared trousers every 10 years or so. Payload is binary, it's fast -> Anybody can read the payload but it's structured -> Structure is redundant, look how lightweight is this -> Payload is binary, it's fast The problem in software world is, there's no silver bullet for any particular problem but there are technology fashions claiming otherwise.
- dboreham 5y agoFlared trouser periodicity is 20 years.
- xtracto 5y agoHaha, that was my thought when I started reading about gRPC. Waaay back in the day I remember programming "distributed" systems using Java RMI. For some whatever reason we are coming back full circle to that approach.
- cbsmith 5y agoI couldn't help but read this article through the eyes of CORBA, and the bit about "the olden days" made me crack up even harder.
- marsdepinski 5y agoSOAP. I'm waiting for gRPC and OpenAPI to get me where WSDLs were 20 years ago.
- cbsmith 5y agoSOAP was the successor to CORBA really, and then everyone decided it was too complicated and heavy weight. ;-)
- atombender 5y agoOn the other hand, past technologies like CORBA, DCOM, and RMI were all object-oriented, whereas gRPC is data-oriented. CORBA (as was DCOM) provided an object model where the client would make method calls to object by identity. This provided "locality transparency" — an object looks identical in the client as in the server. The client object is just a "stub" in CORBA parlance (or "proxy" in DCOM, if I remember correctly), and method calls are transparently translated to RPC calls. The consequence of this is that a client can hold onto entire object graphs, and gets very tightly coupled with the server. For example, a single client can keep tons of objects "open" inside the server just by virtue of having references to them. Very careful tracking of object references would be needed. Both CORBA ans DCOM use explicit reference counting; if a client gets this wrong, it can cause memory leaks inside the server. Not great for scalability, and a big weakness in terms of security. gRPC is more like DCE RPC or Sun RPC, while leveraging a bunch of the web stack which didn't exist back then. There's no denying that technology is cyclical in some ways, of course. But we're not exactly coming full circle. We bring back some things and integrate it into the new stuff. The tooling around gRPC is miles ahead of what we had back then, while being based more or less on the same principles. Interestingly, there's a similar (but maybe more depressing) cyclical story with dynamic vs. static typing in programming language. Python, Ruby, PHP, etc. allowed more people to shift away from commercial tech stacks (especially the horrific Java app server stuff in the early 2000s) while building out super-productive web frameworks. JavaScript allowed us to write web apps that were capable of competing with desktop apps. But in the process we gave up static typing. Millions of person hours have been spent in blogs and discussion boards defending, and extolling the superiority of, dynamic typing — yet this was found (in my view) to be a fallacy, and something of a shared delusion among developers drunk on web frameworks like Rails.
- Rochus 5y agoAgain a bit closer to GIOP and DCE RPC. The circle closes.
- RideAndWave 5y agogRPC is quite counter-ergonomic with its own set of issues when trying to map a business domain to actual solutions. protoforce.io has better modeling and implementation design, supports also 2-way communication, while remaining sane to read and debug. /disclaimer: one of the authors
- nextaccountic 5y agoDoes protoforce have sum types / tagged unions? And is it open source? (apparently not, and is only free for non-commercial uses) Kinda hard to compete when grpc and cap'n'proto are fully FOSS