go-kit and CQRS and Event sourcing

[Antonio Antelo]

Why is not a goal CQRS+ES in go-kit right now?

CQRS/ES is a commun pattern used today for build micro-service and golang have some nice library like:

https://github.com/andrewwebber/cqrs

https://github.com/looplab/eventhorizon

https://github.com/pjvds/go-cqrs

Those libraries need more people to put ideas and I guess if you include one of them it is probable that 

go-kit will have a complete set of tools for micro-services. 

go-kit is a great work. Congratulations.

[Peter Bourgon]

Hey Antonio,

Thanks for asking! The short answer is just that we're focusing on RPC
pattern at the moment. There's still a lot to do to make it a
compelling story for the users we're targeting, and I want to be
careful not to get distracted until that's in a good place.

But maybe the time is right to begin exploring what a good
dataflow/event sourcing/CQRS/message bus/... story would look like in
Go kit? It's worth remembering the reason Go kit exists — to drive the
adoption of Go in larger "modern enterprise" organizations, by solving
the [large] class of problems that need to be solved if you're doing
microservices at scale. (So event sourcing is definitely in scope.)

Equally important is that Go kit doesn't impose too many opinions, or
infrastructural constraints, that would prevent it from being adopted
in a lot of different environments. For example, we support equally
any of Consul, etcd, DNS, SmartStack, etc. for service discovery, and
provide SD patterns and idioms at a layer removed from the specific
implementation. We want to work in as many infrastructures, with the
least amount of friction, as is feasible. So I'm not so interested in
anointing a particular system, pattern, or library as "the Go kit way"
— at least, until I do a •lot• more research.

So far, optimizing for those high-level goals with RPC as the
messaging pattern has been straightforward, because for RPC it's a
pretty well-defined set of things we need to do & be careful about,
and our contributors have good experience implementing them. But I
(personally) don't have a lot of experience in event sourcing. So I'd
need a lot of help, to answer questions like

• What systems will we commonly interact with? Kafka, NSQ, Rabbit, ...?
• What are the common/must-have patterns that users typically implement?
• What precautions do our application services need to take? e.g. how
do these data systems fail?
• Can those patterns and precautions be meaningfully abstracted away
from specific protocols/systems?

Maybe it can all be distilled to a single question—

• What would you expect Go kit to provide, here?

I'd love to start gathering opinions on that. Care to give yours? (Or
anyone else?)

Cheers,
Peter.

> --
> You received this message because you are subscribed to the Google Groups
> "Go kit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to go-kit+un...@googlegroups.com.
> To post to this group, send email to go-...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/go-kit/bfab5a1e-8656-4664-af41-caafc9e1b961%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.