Peter Bourgon
unread,Aug 30, 2018, 9:25:00 PM8/30/18Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Go kit
These are embryonic-level thoughts, but I wanted to put them out into
the world, for feedback if anyone cared to give it.
The new draft proposals, especially the contracts proposal, has
significant consequences for Go kit. A contracts-enabled Go kit would
have a radically different approach to what is currently accomplished
by the endpoint abstraction. (The current endpoint abstraction and the
concomitant boilerplate was always a compromise forced by an
underpowered type system.)
Additionally, in the years since Go kit's initial release, the
landscape in which it operates has changed significantly. This was
bound to happen. Many of the things that Go kit originally needed to
provide — notably, the antifragile middlewares like ratelimit and
circuitbreaker, and to some degree the package sd and metric
abstractions — have become less important, or less necessary for a
toolkit like Go kit to provide.
As I've continued to evangelize and educate about Go kit, in talks and
workshops and consulting, some things have become clear. Go kit's
greatest value hasn't been its collection of packages themselves, but
rather the way it serves as an example of a coherent and robust
microservice program architecture. (Closely related to DDD concepts
like bounded contexts, and architectural patterns like the Hexagonal
architecture and the Clean architecture.)
Therefore: I think I'll plan to draft a 1.0.0 release of the ~current
state of the Go kit repo, and then start thinking and experimenting
about what a contract-enabled Go kit 2.x.x would look like. My
intuition is that it would be a lot less code.
I would want to keep the current set of transports, package log,
whatever was necessary to keep distributed tracing healthy, and
_maybe_ finish my re-imagining of package metrics. I would probably
drop package sd, because runtime environments have largely solved this
problem. I would probably drop packages ratelimit, circuitbreaker, and
auth; or, figure out a better way to provide "helpers" for those kind
of concerns. And package endpoint would likely go away, though I can't
say precisely how until the draft specs are solidified.
Cheers,
Peter.