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

41–50 of 73 posts

Re: gRPC for Microservices Communication

#41

Post by keithnz »

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

eventually they are just going to invent an actor framework

Re: gRPC for Microservices Communication

#42

Post by twistedpair »

kyrra wrote: post #4
fhood wrote: post #2

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

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

Swagger is handy here. Auto-generate your API model objects, interfaces, and REST clients in any language (e.g. Typescript).

Re: gRPC for Microservices Communication

#43

Post by jeffbee »

envyac wrote: post #9
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.

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

Please elaborate on the ways in which protocol buffers conforms to the definition of the word "proprietary".

Re: gRPC for Microservices Communication

#44

Post by nextaccountic »

RideAndWave wrote: post #40

gRPC 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

Does 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

Re: gRPC for Microservices Communication

#45

Post by anonymoushn »

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

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 their own caching for the user service.

Re: gRPC for Microservices Communication

#46

Post by keithnz »

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.

no, there are multiple alternatives, but from what you have said, perhaps using something like MassTransit would work well for you https://masstransit-project.com/

Re: gRPC for Microservices Communication

#47

Post by ammanley »

gravypod wrote: post #16
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.

There's no reason you couldn't use gRPC with json as a serialized message format. For example grpc-gateway [0] provides a very effective way of mapping a gRPC concept to HTTP/JSON. The thing is, after moving to gRPC, I've never really felt a desire to move back to JSON. While it may be correct to say "parsing json is fast enough" it's important to note that there's a "for most use cases" after that. Parsing protos is…

> The thing is, after moving to gRPC, I've never really felt a desire to move back to JSON.

Second this. I think its also really important to consider the "trap" of going in on gRPC, but using something like grpc-gateway to also spit out JSON as a "backup". We did this for a project I was on, and the JSON API was the thing everyone else used (because up until then, everything there was a JSON API, naturally). As a result, unless a consuming team was willing/able to get involved in the protobuf definition internals, most of our consumers didn't reap any benefits from our typed protobuf API.

I know it really isn't hard to do, but lowest friction denominator wins far too often in a feature-focused environment :-\

Re: gRPC for Microservices Communication

#48

Post by atombender »

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

Re: gRPC for Microservices Communication

#49

Post by gravypod »

ammanley wrote: post #47
gravypod wrote: post #16

Earlier quoted context omitted.

There's no reason you couldn't use gRPC with json as a serialized message format. For example grpc-gateway [0] provides a very effective way of mapping a gRPC concept to HTTP/JSON. The thing is, after moving to gRPC, I've never really felt a desire to move back to JSON. While it may be correct to say "parsing json is fast enough" it's important to note that there's a "for most use cases" after that. Parsing protos is…

> The thing is, after moving to gRPC, I've never really felt a desire to move back to JSON. Second this. I think its also really important to consider the "trap" of going in on gRPC, but using something like grpc-gateway to also spit out JSON as a "backup". We did this for a project I was on, and the JSON API was the thing everyone else used (because up until then, everything there was a JSON API, naturally). As a re…

One thing that was doable in my last company where I used gRPC was I made interfacing with the gRPC API dead simple. Something like `connect(ServiceBlockingStub.class)` was in your code and it would instantly pull configs, build the service, wire up all of our middle wares + logging, etc.

You can automate a lot of this which essentially makes the normal level of friction easier.

Re: gRPC for Microservices Communication

#50

Post by chuckcode »

bitwize wrote: post #19
envyac wrote: post #9

Earlier quoted context omitted.

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

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

Great 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.
Post reply on HN