11–20 of 73 posts
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.
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.
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.
Is this the path to a tightly coupled distributed monolith?
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.
You still have to unmarshal json into some sort of object/struct.
How do you test gRPC? E.g. a gRPC microservice.
Is this the path to a tightly coupled distributed monolith?
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.
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).
"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…
Is this the path to a tightly coupled distributed monolith?
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.
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.
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.
"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…
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.