wire VS watermill

code generation is a mostly disjoint topic from DI. Granted, some solutions like https://github.com/google/wire use code generation, but you're exactly right about their pitfalls. If your dev environment doesn't have good support for generated code, it is a nightmare. If you can goto-definition the generated code, then it is suddenly feasible, but perhaps still a bad choice.

We use https://github.com/google/wire for every bigger project, take a look at it, it beautifully solves initialisation and also gives you a guideline on how to do it.

Im by no means a "purist" in such things, I love my magic and QoL-features/libs, but havent seen something that is so easy to use in go, that I immediately wanted to add it. And to be fair, I only looked closely at https://github.com/google/wire , others I have just skipped - and I will be looking into uber-fx as mentioned in the other comment.

If you have such a complex and deep dependency graph, and you don't want to manually maintain it, you could use some DI library to handle that for you. Something like https://github.com/google/wire for small-medium size stuff, or https://github.com/uber-go/fx for larger scale, more enterprise projects.

Try https://github.com/google/wire. Compile time generated like dagger 2 in java.

Most people probably do it by hand (I do). But otherwise, probably https://github.com/google/wire is the most popular, maybe followed by https://github.com/uber-go/fx.

For larger object graphs do you roll everything by hand or encourage something like https://github.com/google/wire

The other thing is that I'm lazy, so I don't construct all dependencies in main.go manually but use wire to generate the construction of my dependency tree.

I’ve successfully worked on projects using an asynchronous event-driven way of connecting services. I really like the decoupling of business logic and the events triggering it. I highly recommend https://github.com/ThreeDotsLabs/watermill to be more flexible when it comes to choosing the actual technology driving the async patter. It might be NATS today but requirements might change and you need to change. Watermill prepares you for this.

Highly recommend https://watermill.io lib for building async apps (using among others pub/sub patterns). It greatly decouples your code from the underlying technology and gives you the freedom to choose depending on the environment (e.g dev, prod). For dev or small scale purposes, it supports pub/sub purely based on go channels.

Look at this library: https://github.com/ThreeDotsLabs/watermill

Watermill is a good pubsub abstraction. You can start with native go channels and grow into a cloud pubsub or Kafka/Pulsar if you need to.

These conditions have led me to discover two packages watermill.io and go-kit. Both of these seem to do what I want and I am thinking of implementing the project using watermill and go Chanels and deploying to a server or some sort.

github.com/ThreeDotsLabs/watermill package provides a framework for building event-driven applications. It allows easy communication between independent components by decoupling the sender and the receiver.

My personal favorite tools: - https://github.com/go-kit/ for building services (although it's not necessary a great tool for prototyping) - https://github.com/gorilla/mux router (although it's been recently deprecated, so I'm looking for a similar, maintained library) - https://entgo.io/ ORM - https://watermill.io/ for messaging

Checkout https://watermill.io/