[HN Gopher] gRPC for Microservices Communication
___________________________________________________________________
gRPC for Microservices Communication
Author : pankaj021
Score : 60 points
Date : 2021-09-23 18:10 UTC (4 hours ago)
(HTM) web link (techdozo.dev)
(TXT) w3m dump (techdozo.dev)
| RideAndWave wrote:
| 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
| nextaccountic wrote:
| 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
| gokhan wrote:
| 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.
| atombender wrote:
| 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.
| dboreham wrote:
| Flared trouser periodicity is 20 years.
| xtracto wrote:
| Haha, 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 wrote:
| 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.
| georgeburdell wrote:
| 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.
| sfblah wrote:
| 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.
| Smaug123 wrote:
| 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.)
| keithnz wrote:
| 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/
| Rochus wrote:
| Again a bit closer to GIOP and DCE RPC. The circle closes.
| baldeagle wrote:
| Is this the path to a tightly coupled distributed monolith?
| ramesh31 wrote:
| 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.
| bitwize wrote:
| 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.
| envyac wrote:
| 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.
| bitwize wrote:
| 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.
| jeffbee wrote:
| Please elaborate on the ways in which protocol buffers
| conforms to the definition of the word "proprietary".
| dasloop wrote:
| Unless you are communicating C++ services for example and
| you prefer a lib that does the parsing and transformation
| to native object for you
| gravypod wrote:
| 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 fast enough for even more use cases. You
| also get streams which are amazing for APIs where you have to
| sync some large amounts of data (listing large collections
| from a DB for example) across two services.
|
| With gRPC you also have a standardized middleware API that is
| implemented for "all" languages. The concepts cleanly map
| across multiple languages and types are mostly solved for
| you.
|
| Adding to that you can easily define some conventions for a
| proto and make amazing libraries for your team. At a previous
| job I made this: https://github.com/CaperAi/pronto/
|
| Made it super easy to prototype multiple services as if you
| mock a service backed by memory we could plop it into a DB
| with zero effort.
|
| I think this "gRPC vs X" method of thinking isn't appropriate
| here because protos are more like a Object.prototype in
| JavaScript. They're a template for what you're sending. If
| you have the Message you want to send you can serialize that
| to JSON or read from JSON or XML or another propriety format
| and automatically get a host of cool features (pretty
| printing, serialization to text/binary, sending over the
| network, etc).
|
| [0] - https://github.com/grpc-ecosystem/grpc-gateway
| ammanley wrote:
| > 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 :-\
| gravypod wrote:
| 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.
| konart wrote:
| What does this (client to web service communication) has to
| do with interservice communication?
|
| You still have to unmarshal json into some sort of
| object/struct.
| brown9-2 wrote:
| Why would it lead to any tighter of a coupling that other
| styles of APIs?
| Toine wrote:
| Almost 100% of microservice implementations I've come across
| are exactly this.
| fhood wrote:
| 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.
| kyrra wrote:
| 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).
| twistedpair wrote:
| Swagger is handy here. Auto-generate your API model objects,
| interfaces, and REST clients in any language (e.g.
| Typescript).
| snypox wrote:
| 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.
| rileymichael wrote:
| I personally use BloomRPC -- just point it at your protos
| and go. (plus it supports grpc-web)
| travisd wrote:
| +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 wrote:
| 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
| jayd16 wrote:
| GrpCurl helps a bit with this.
|
| https://github.com/fullstorydev/grpcurl
| mirekrusin wrote:
| "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_re...
|
| * https://www.youtube.com/watch?v=GBTdnfD6s5Q
|
| etc.
| Zababa wrote:
| 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 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.
| [deleted]
| jayd16 wrote:
| >the discussion about "microservices" is drowning the
| discussion about plain services.
|
| Yeah I think this really sets back the conversation when, in
| my mind, microservices are just services with the
| acknowledgement that minimum size should not factor into
| breaking off a new service.
| Toine wrote:
| 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 ?
| keithnz wrote:
| eventually they are just going to invent an actor framework
| anonymoushn wrote:
| 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.
| davidw wrote:
| > How do you fix that?
|
| You run away as fast as you can is what you do.
| dastbe wrote:
| 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.
| sjnair96 wrote:
| 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.
| brinox wrote:
| You can configure the message size limit on your gRPC server,
| doesn't that fix your issue?
| CommonGuy wrote:
| 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
| the_gipsy wrote:
| How do you test gRPC? E.g. a gRPC microservice.
| brown9-2 wrote:
| how do you test a HTTP/REST microservice?
| spyremeown wrote:
| If you mean actual testing, we use a lot of mocks and this[1]
| little dude.
|
| [1] https://github.com/fullstorydev/grpcurl
___________________________________________________________________
(page generated 2021-09-23 23:01 UTC)