Go Micro
Languages and libraries
microservices framework
SHOW HN2019
How HN took it
0 positive, 2 neutral or asking, 0 mixed, 8 critical, out of 10 comments about the project. Thread score -0.59.
Execution: 0 for, 4 againstIdea: 0 for, 2 againstPrivacy: 0 for, 1 againstDocs: 0 for, 1 against
The thread, comment by comment
Each row is a top-level comment and its replies, in HN's order. Select a cell to open that comment on HN.
positive neutral or mixed critical about another commenter or something else the maker
What HN said
Objections
Microservices are often overkill and add complexity before organizational need
From 3 comments
Not knocking the OP, or his/her effort, but I think the number of microservice frameworks exceeds the number of organizations that actually have the problems that microservice…
GiorgioG on HNI would argue that, unless you are supporting many developers working on the same project simultaneously (as in, hundreds if not thousands), that microservices will actually slow…
roganartu on HNEvery microservice you carve out of a monolith gives you at least 2 public APIs you didn't have to worry about before, and makes local development that much more complicated. I…
PopeDotNinja on HN
Frequent breaking changes and poor communication channels
From 2 comments
There are breaking changes like every second minor release, functionality gets removed, dependent repositories get deleted/renamed/moved by author. PRs are discussed on the wrong…
Someoneelse77 on HNThank you for the honest feedback. We're moving fairly quickly in regards to the evolution of the framework. Some of that results in breaking changes and you're right we haven't…
chuhnk on HN
Service discovery and load balancing are better handled by the platform such as Kubernetes
From 2 comments
Service Discovery, load balancing. Aren't these things that should be done by the underlying platform? In other words: if I'm using this with K8s doesn't K8s do that for me? What…
holografix on HNI fear this does too much. All applications should care about is an API to do what they want, so all you need to decide on is a messaging protocol, which is probably going to be…
jrockway on HN
Framework lacks documented rationale and tradeoffs
From 1 comment
I'd help a lot if the project showed rationale, alternatives, its taken choices and the corresponding tradeoffs. Otherwise, one is essentially invited to blindly adopt someone…
vemv on HN
Requests
Document design rationale, alternatives and tradeoffs
From 1 comment
I'd help a lot if the project showed rationale, alternatives, its taken choices and the corresponding tradeoffs. Otherwise, one is essentially invited to blindly adopt someone…
vemv on HN
Establish proper communication channels for breaking changes
From 1 comment
There are breaking changes like every second minor release, functionality gets removed, dependent repositories get deleted/renamed/moved by author. PRs are discussed on the wrong…
Someoneelse77 on HN
Questions
What benefits does Go Micro give beyond Kubernetes service discovery and load balancing?
From 1 comment
Service Discovery, load balancing. Aren't these things that should be done by the underlying platform? In other words: if I'm using this with K8s doesn't K8s do that for me? What…
holografix on HN
Why use this framework rather than a simpler approach such as net/rpc?
From 1 comment
Having built a micro service of sorts just yesterday with nothing more than net/rpc, it wasn't that bad.
tedunangst on HN
Alternatives named
Envoy, Istio and Linkerd for load balancing and tracing
From 1 comment
I fear this does too much. All applications should care about is an API to do what they want, so all you need to decide on is a messaging protocol, which is probably going to be…
jrockway on HN
Kubernetes for service discovery
From 1 comment
Service Discovery, load balancing. Aren't these things that should be done by the underlying platform? In other words: if I'm using this with K8s doesn't K8s do that for me? What…
holografix on HN
Plain net/rpc
From 1 comment
Having built a micro service of sorts just yesterday with nothing more than net/rpc, it wasn't that bad.
tedunangst on HN
Prometheus, Grafana, Jaeger for observability
From 1 comment
I fear this does too much. All applications should care about is an API to do what they want, so all you need to decide on is a messaging protocol, which is probably going to be…
jrockway on HN