Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

gRPC for Microservices Communication

techdozo.dev

Post reply on HN
Print view View original

21–30 of 73 posts

Re: gRPC for Microservices Communication

#21

Post by CommonGuy »

snypox wrote: post #6
kyrra wrote: post #4

Earlier quoted context omitted.

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

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

I would recommend 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

Re: gRPC for Microservices Communication

#22

Post by sjnair96 »

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

Re: gRPC for Microservices Communication

#23

Post by georgeburdell »

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

Re: gRPC for Microservices Communication

#24

Post by sfblah »

georgeburdell wrote: post #23

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

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

Re: gRPC for Microservices Communication

#25

Post by brinox »

sjnair96 wrote: post #22

Have 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…

You can configure the message size limit on your gRPC server, doesn't that fix your issue?

Re: gRPC for Microservices Communication

#26

Post by Toine »

mirekrusin wrote: post #12

"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 pef…

I've seen "confirmed" developers create one microservice for each entity/model they have. Everything is simple CRUD, absolutely no domain logic. Literally, a "user" microservice, with its User class and repository, 100 LOC, a "message" microservice with 80, etc. Aggressively arguing the superiority of their monster. Of course the services all shared the same db, completely missing the actual benefit of microservices. And every service was completey coupled to others and could not run on its own.

How do you fix that ?

Re: gRPC for Microservices Communication

#27

Post by CommonGuy »

brinox wrote: post #25
sjnair96 wrote: post #22

Have 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…

You can configure the message size limit on your gRPC server, doesn't that fix your issue?

Another 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

Re: gRPC for Microservices Communication

#29

Post by davidw »

Toine wrote: post #26
mirekrusin wrote: post #12

"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 pef…

I've seen "confirmed" developers create one microservice for each entity/model they have. Everything is simple CRUD, absolutely no domain logic. Literally, a "user" microservice, with its User class and repository, 100 LOC, a "message" microservice with 80, etc. Aggressively arguing the superiority of their monster. Of course the services all shared the same db, completely missing the actual benefit of microservices.…

> How do you fix that?

You run away as fast as you can is what you do.

Re: gRPC for Microservices Communication

#30

Post by gokhan »

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

Post reply on HN