Status of go-micro

[rajeshatverbtech]

As we at Verb migrate away from other platforms to Golang, I could not find a better framework than go-micro. We are seriously considering exploring it at Verb to all future development however I am not sure where it is headed. I saw Asim's message from back in 2020 where he gave up working on it yet see his recent responses to Rene and other folks.

Can someone please help me with the following?

1. What major companies (that we know of) are using this framework?
2. How does it compare to popular Microservices frameworks like echo and fiber?
3. Is it truly enterprise-scale?
4. Where is it headed? I see discussing related to v5 but not enough to understand if there is a roadmap.

Feel free to contact me directly, if you would like.

Regards.

Rajesh Ashtapture
CTO, Verb Technology Company
rajesh@verb.tech

[Davincible]

Hi @rajeshatverbtech, thanks for taking an interest in the project.

To answer your questions;

1. personally I don't have a list of companies that use it. However, as the project is 7+ years old, and one of the major microservice frameworks I know it's used a lot across the board.
2. echo and fiber aren't micro-service frameworks, but web frameworks. While I am sure they are nice, they cover one specific sub-part of what go-micro does. Go-micro is an all-in-one microsevice framework, covering almost all bases regularly needed to develop micro services at scale. If you specifically need a web framework, take one of the two you mentioned.
3. Short answer, yes.
4. While we haven't published a clear public roadmap as of now (maybe we should), here is the quick rundown;

• v4: currently in maintenance mode. No new features are actively added, however, it has been developed for years and is feature complete. We do of course accept any community contributions.
• v5: actively being developed, but not yet ready for mass use. After careful consideration, we concluded that anno 2022 v4 has some shortcomings. This mainly stems from the fact that the original versions of go-micro have been developed years ago, and technology has progressed since then. E.g. gRPC was not the defacto standard back then, and generics were not available. As a result, some things are not as optimal. E.g. a lot of reflection is used in v4, which causes the code the perform at a sub-optimal level. While modularity is the motto of go-micro, we are improving this even further in v5. From the user's point of view, v5 will not be a directly drop-in replacement of v5, but minimal work will be required to port v4 projects over to v5.

If you have more questions feel free to ask :)

[vtolstov]

how generics can help with grpc and avoid reflection?

[jochumdev]

@vtolstov see how @Davincible solved it in go-orb/plugins#27

[vtolstov]

i don't see any benefits, mostly this is direct use of grpc server and it interceptors that breaks go-micro design that you can have any handler wrapper that works for any server (http/grpc/etc)

[Davincible]

how generics can help with grpc and avoid reflection?

The big change in v4 to v5, is that in v4 handlers are 'registered' by completely decomposing the entire handler. Meaning, it reflects on the handler function, records it input and output types, and subsequently stores it as a text representation, not as a function object. When you then make a call, it has to completely re-compose everything. Through all of this you loose type safety and speed. While yes, you might be using gRPC over the wire, at the application level you're not really due to all the added extra steps.

In v5, we register handlers directly, which you can see in the code linked by Renee. Thus for an http server, the handler is directly added to the http router, for a gRPC server, your handler will be directly registered to the server as if there was no framework in between, thus performance will be directly the performance offered by the server. This in part is made possible through generics.

To also touch on some points from your email, which I forgot; with the help of generics we have designed the new server to be much more modular. In v5 we use a concept called entrypoints, representing one server with one address to listen on. You can have as many entrypoints as you'd like, in any number of combinations. It's thus very easy to add different servers, e.g. drpc, frpc, the the banking server you talked about. All it takes is a simple plugin that implements the entrypoint interface.

One promising future change of generics, which I am looking forward to, is shared properties. I.e. if you have two structs with shared fields, you could write a generic constraint on them and access the shared fields, which you currently can't. This will be very useful for things like config in go-micro

[Davincible]

i don't see any benefits, mostly this is direct use of grpc server and it interceptors that breaks go-micro design that you can have any handler wrapper that works for any server (http/grpc/etc)

You can again use generics to make one wrapper compatible with another

[adrian-moisa]

@rajeshatverbtech What is your current conclusion? I'm evaluating if to use go-micro or not. I'm not convinced the health of project is looking great. I'm having trouble finding clear cut answers.