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

51–60 of 73 posts

Re: gRPC for Microservices Communication

#51

Post by vidanay »

Smaug123 wrote: post #33
sfblah wrote: post #24

Earlier quoted context omitted.

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

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

You'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.

Re: gRPC for Microservices Communication

#52

Post by jeffffff »

dastbe wrote: post #17
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…

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

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

Re: gRPC for Microservices Communication

#53

Post by marsdepinski »

anonymoushn wrote: post #45
Toine wrote: post #26

Earlier quoted context omitted.

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

The user service team told us we were querying them too much, so we just stored usernames in addition to user IDs to avoid querying them, then later documents would have the wrong username on them if the user changed their username. One perspective is that we were negligent and caused a bug, but another possible perspective is that maybe the user service team should have caching instead of every other team building t…

They should send a cache-control header in the response or 304 Not-modified when queried with not-modified-since. The calling service should always be the one responsible for caching to save the network round-trip. And if you're going to duplicate data like usernames, get a message channel setup to propagate the changes into the system cloning data.

Re: gRPC for Microservices Communication

#54

Post by marsdepinski »

cbsmith wrote: post #35
gokhan wrote: post #30

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

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

SOAP. I'm waiting for gRPC and OpenAPI to get me where WSDLs were 20 years ago.

Re: gRPC for Microservices Communication

#55

Post by marsdepinski »

bitwize wrote: post #18
ramesh31 wrote: post #5

Earlier quoted context omitted.

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

Why are you using a browser to test microservices, for which browsers are an atypical-at-best client? Amiga got right what Unix got wrong: A well-structured, open binary protocol is almost always preferable to a "plain text" protocol because the parsing overhead really adds up.

Try telling that to a platform with a different endian format.

Re: gRPC for Microservices Communication

#56

Post by sjnair96 »

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?

Ahh, 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.

Re: gRPC for Microservices Communication

#57

Post by sjnair96 »

CommonGuy wrote: post #27
brinox wrote: post #25

Earlier quoted context omitted.

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

Yes, but that would involve us digging into the code of the gRPC server, which is unfortunately closed to us :(

Re: gRPC for Microservices Communication

#58

Post by hiram112 »

atombender wrote: post #48
gokhan wrote: post #30

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

On 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 corre…

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

Bingo. I learned C++ and then Java first, so I've always been biased towards static typing. When the whole MEAN stack (including non-relational databases i.e. just shoving tons of JSON back and forth) become the cool thing, I refused to buy into the hype and continued using Java, even if it didn't make me popular with the newer developers.

And now I make good money cleaning up Node / Python monstrosities that grew too big for dynamic typing to handle. The worst thing about these is that somewhere in the last 4-5 years, the dynamic advocates began to realize that static types really did make sense, and so now they've added all sorts of hacks like Typescript or Python typing libs (Pydantic) and annotations that try to bridge the gap.

But it doesn't work. The few actual benefits of "simple" languages like Python and Javascript (e.g. One Way to Do Things and quick prototyping) are a thing of the past. Instead, a typical Python or Express web app now has just as many unintelligible annotations and verbose "interfaces" or model objects as an "enterprise" Java / C# app had 10 years ago.

And the pseudo-types aren't even all that helpful. The IDEs can sometimes understand things, but usually not 100% like they would with a Java app. Rarely does auto-complete or large refactoring work. Typing errors aren't always found at "compile" time - still plenty of surprises discovered only at runtime.

Readability is just as bad as the typical Java-Spring app with all sorts of magic going on underneath the covers at runtime. There is no way to just glance at a simple controller and understand what's going on without knowledge of increasingly bloated frameworks.

It's just a mess. At least I'll have plenty of work for the next decade.

Re: gRPC for Microservices Communication

#59

Post by bitwize »

marsdepinski wrote: post #55
bitwize wrote: post #18

Earlier quoted context omitted.

Why are you using a browser to test microservices, for which browsers are an atypical-at-best client? Amiga got right what Unix got wrong: A well-structured, open binary protocol is almost always preferable to a "plain text" protocol because the parsing overhead really adds up.

Try telling that to a platform with a different endian format.

Little endian won. If you're developing modern software for modern machines, you pretty much needn't even consider big endian.

Re: gRPC for Microservices Communication

#60

Post by omegalulw »

Zababa wrote: post #20
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 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 o…

> In a way, services and microservices are OO programming in the Alan Kay sense: late binding, message passing, local retention and hiding of state.

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

This is a moot point. Following up on you OO example, there is not reason you can have separate public and private implementations within a (modularized) monolith.

The biggest downsides of (modularized) monoliths lie in 1) scaling - e.g., you can independently scale and load balancer each service, 2) releases - you can have independent releases (at the risk of maintaining version compatibility).

Post reply on HN