There is a trending 'microservice' library called go-kit. I've been using the go-kit library for a while now. The library provide a lot of convenience integrations that you might need in your service: with service discovery with Consul, distributed tracing with Zipkin, for example, and nice logic utilities such as round robin client side load balancing, and circuit breaking. It is also providing a way to implement communication layer, with support of RPC and REST.
The toolchain that the library provide is very nice, and it does try to solve a fundamental problem we have in the Go community: missing ecosystem to write microservices. I do like the approach of the package: 'take what you want', you can write your service and use certain tools given in this libary, and not use all of it. But, I recommend not to use the library server implementation for your REST microservices. (I think this recommendation will also apply for the RPC part of the library, but I don't have any experience with that).
You could read why, and I would love to hear your opinion about it, if you agree, disagree, and why.
Usually microservices expose APIs: external, which are exposed, and internal for inter-service communication.
When using the go-kit, it was very noticeable that the overhead of adding API you your service is very high. You need to add a lot of code, which is mostly copy-paste of other APIs and there are too many places to make mistakes.
To add a single simple API, you should add:
a. Function in the interface (make sense) b. Implementation (make sense) c. Endpoint factory function d. Transport function e. Request encoder, request decoder, response encoder and response decoder. f. Add the endpoint to the server g. Add the endpoint to the client.
For a quick impression of what I mean by "a lot of code" take a look at the simple example in the go-kit website
I think the main reason for this verbosity is the layer separation for the business logic, endpoint and transport, which is nice, and benefits in nice abstractions for the client-side load balancing, circuit breaking, tracing, etc.
But, it is hard to understand.
If you are using the go-kit as REST service library, I recommend to know the following ServerHTTP function by heart: Only then you truly understand how your service is expected to behave.
When using the go-kit, your endpoints get an interface{} object and return an
interface{}, error tuple. You need to explicitly write the conversion to your
implementation function.
Actually, your endpoint factory will almost be a copy-paste of the following function:
func makeUppercaseEndpoint(svc StringService) endpoint.Endpoint {
return func(ctx context.Context, request interface{}) (interface{}, error) {
req := request.(myRequest)
v, err := svc.Function(req.A, req.B)
if err != nil {
return myResponse{v, err.Error()}, nil
}
return myResponse{v, ""}, nil
}
}This library is really nice, and with really good intensions. It looks very
popular, but can't really understand how much production ready it is, and how many actual use
cases there are out there. I personally don't
like the basic concepts of it, specially because of the interface{} and the verbosity issues
discussed above, and I find them not easy to use, and not intuitive.
You couldn't use the nice features of the library of load-balancing, circuit breaking, and tracing, if you are not using the endpoint APIs, but if you look at the code, it is not that big. You could use the actual code or find other libraries that provide them as middleware for the standard http client/server.
If you find this interesting, please, ✎ comment below or ★ star above ☺
For more stuff: gist.github.com/posener.
Cheers, Eyal
Great article. Must read to avoid using of go-kit. This framework is nothing more than code hell. For 1 line of code, you must write 10-20 lines of boilerplate. Just check any of the examples, for instance, https://github.com/go-kit/kit/tree/master/examples/profilesvc Why you need all these Endpoints and Middlewares? Why just not to use a proxy pattern? Why just not to write straight code without
func(ctx context.Context, request interface{}) (response interface{}, err error)? Use interface{} only in middlewares, in other cases you can fully control your types.I'm 99% sure that you want to use gRPC with microservices — in that case, you absolutely do not need complex abstractions that go-kit provides. Just use gRPC directly. With its interceptors, logging, tracing, service discovery ecosystem. Straightforward, simple to debug and understand.
Another unresolvable problem with Go-kit is error passing: you can’t just take your custom error and throw it through metadata from server to client to handle it correctly. Go-kit popularizes anti-patterns like error throwing via struct properties. But it can be done easily with custom gRPC interceptors and few lines of code.
Using event-driven approach? Try to use native libraries with tiny helpers for metadata, encoding/decoding, logging, etc.. You do not need to bind your hands with go-kit thinking how to make this or that task — just do it with as little code as possible.
I'm glad that I refused to work with go-kit a long time ago. In retrospect, it was like — one day for actual business logic programming and another 2-3 days for annoying wrapping all together into endpoints and middlewares.
BTW Go-Micro looks much better designed. If you still want to stay with some framework, give go-micro a try.
Sorry if rude, but I'm upset with that fact that go-kit spread among many companies and I periodically have to work with it. Anti-go-way for sure.