Go-MediatR VS fx

Some of the features: - ✅ Using Vertical Slice Architecture as a high level architecture - ✅ Using Event Driven Architecture on top of RabbitMQ Message Broker with a custom [Event Bus](pkg/messaging/bus/) - ✅ Using Event Sourcing in Audit Based services like [Orders Service](services/orders/) - ✅ Using CQRS Pattern and Mediator Patternon top of Go-MediatR library - ✅ Using Dependency Injection and Inversion of Controlon top of uber-go/fx library - ✅ Using RESTFul api with Echo framework and using swagger with swaggo/swag library - ✅ Using Postgres and EventStoreDB to write databases with fully supports transactions(ACID) - ✅ Using MongoDB and Elastic Search for read databases (NOSQL) - ✅ Using OpenTelemetry for collection Distributed Tracing with using Jaeger and Zipkin - ✅ Using OpenTelemetry for collection Metrics with using Prometheus and Grafana - ✅ Using Unit Test for testing small units with mocking dependent classes and using Mockery for mocking dependencies - ✅ Using End2End Test and Integration Test for testing features with all of their real dependeinces using docker containers (cleanup tests) and testcontainers-go library

There are some mediator-like libraries like https://github.com/mehdihadeli/Go-MediatR or https://github.com/erni27/mob but they are not used widely like for example their C# sibling https://github.com/jbogard/MediatR. Also, neither I see custom implementations of mediator in many projects.

I found fx(https://github.com/uber-go/fx) to be a super simple yet versatile tool to design my application around.

All the advice in the article is still helpful, but it takes the "how do I make sure X is initialized when Y needs it" part completely out of the equation and reduces it from an N*M problem to an N problem, ie I only have to worry about how to initialize individual pieces, not about how to synchronize initialization between them.

I've used quite a few dependency injection libraries in various languages over the years (and implemented a couple myself) and the simplicity and versatility of fx makes it my favorite so far.

Some of the features: - ✅ Using Vertical Slice Architecture as a high level architecture - ✅ Using Event Driven Architecture on top of RabbitMQ Message Broker with a custom [Event Bus](pkg/messaging/bus/) - ✅ Using Event Sourcing in Audit Based services like [Orders Service](services/orders/) - ✅ Using CQRS Pattern and Mediator Patternon top of Go-MediatR library - ✅ Using Dependency Injection and Inversion of Controlon top of uber-go/fx library - ✅ Using RESTFul api with Echo framework and using swagger with swaggo/swag library - ✅ Using Postgres and EventStoreDB to write databases with fully supports transactions(ACID) - ✅ Using MongoDB and Elastic Search for read databases (NOSQL) - ✅ Using OpenTelemetry for collection Distributed Tracing with using Jaeger and Zipkin - ✅ Using OpenTelemetry for collection Metrics with using Prometheus and Grafana - ✅ Using Unit Test for testing small units with mocking dependent classes and using Mockery for mocking dependencies - ✅ Using End2End Test and Integration Test for testing features with all of their real dependeinces using docker containers (cleanup tests) and testcontainers-go library

any take on https://github.com/uber-go/fx?

I’m not sure of much that can do all of that - maybe it’s a use case for https://github.com/uber-go/fx

If I still find myself stuck/waiting, I switch over to studying more about our team's main language Go. Currently looking around at Fx ( https://github.com/uber-go/fx ). Which is interesting, though I doubt we'll actually migrate anything for it, but might make a neat lunch and learn topic.

Hello gophers, I am using https://github.com/uber-go/fx and https://github.com/rs/zerolog for logging.

Also, I like to use Uber FX for my DI stuff. You can check it out here:https://github.com/uber-go/fx

I only have private and work repos... But I use Uber fx. https://github.com/uber-go/fx

Spring Boot is notable for its dependency injection / inversion of control. The closest Go has to this is Uber's Fx which also includes some lifecycle management.

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.