Hey, thanks a lot for the kind words. I’m glad you liked it!
So the advantage of Go kit, specifically the endpoint layer might indeed not be obvious if you think on terms of a single transport.
There are two ways to rationalize its existence.
First one is from an architectural standpoint. When you build an application, you want to delay certain decisions in time as long as possible. For example which transport layer you want to use. Ideally (again: from an architectural standpoint) whether you use HTTP or gRPC should not affect the core behavior of your application. For example: authorization is commonly done in the HTTP layer, based on HTTP routes and methods, but why should authentication and authorization be tied to HTTP? That’s probably not the most realistic example though, because most applications are hardcoded into one type of transport.
There is a more practical way to think about it though. Let’s say you have an Account service which has two clients:
- Web UI (HTTP; through some sort of API gateway)
- Newsletter service (gRPC)
In a service oriented environment it’s perfectly valid to have two (or more) exposed interfaces for the same service. (A third example could be some sort of async processing from a queue)
In this case, you want to make sure that (roughly) the same middleware are wired into two separate transports. That’s a lot of duplication, lot of testing. The endpoint layer allows you to wire all that logic into the service, independently from the transport.
These are the two common reasons for the endpoint layer. I admit that not everyone has use cases that justify using a Go kit like architecture. But it can save you a lot of time and pain if you need to support more than one transport or have to migrate from one to another (which is also not without precedent).
Hope that clarifies what the endpoint layer is for!