What does this look like when you start to have 10, 20, 30 repos and services? How can you organize them with this pattern in mind? Are all of the services and repos created in main, and passed down through closures?
Btw I'm using this pattern for over years in a lot of my Go projects. I ended up using IoC library like Wire or Fx to wire my dependency automatically due to my codebase get bigger overtime. What's your opinion of using IoC library like Wire or Fx? I personally disagree with that but somehow makes my work easier. Thanks!
I've wondered this myself. I'm not a "native gopher". I come from languages that have no problem bringing in all the libraries to do whatever you want, and it seems to me that gophers have a little bit different philosophy. It feels a little weird having some initialization code that manually injects the things... So far, though, I'm manually injecting all the things. Would be nice to hear what's "idiomatic".
I do it this way in most of my non-trivial Go work. The only aesthetically questionable part is the "newing up of all the things and injecting"- compared to Java Spring Boot, say (lol, but then you have to write Java). Otherwise, it's a total win, and you'll really thank yourself when it comes to unit testing.
@@B0re_d Easy, just use channels between the API part and the database interaction layer. Message passing makes it easy to actually decouple layers as long as you don't expose internal IDs from the db. Interface objects that give you synchronous calls to interact with your DB without any way to bulk calls together or to optimize things are absolutely awful, since you throw away the perks of the DB but still get temporal coupling between the frontend and the DB interactions that makes it impossible to optimize anything, bulk calls together, or to refactor your architecture by using a message bus instead of writing straight to the db. Since interfaces like the ones mentioned in the video force the reads and writes to happen in a very specific order with no way to reorder them. Go gives you the amazing ability to have daemons that manage different parts of your application. Use it.
@@BosonCollider I promise you that nobody watching this video is working on a project or even capable of working on a project of the kind you're recommending, and even if they were a developer at the level of being able to understand and properly manage the many, many potential pitfalls of the concurrency model, only 1 in 10 of that developer's projects actually would benefit from it over more traditional DI. If someone has just watched this video and learned about the repository pattern, they are nowhere near being capable of this and more likely will regret ever trying. I feel even worse for the poor sap who might inherit that monstrosity.
You just explained the general concept of DI, there was nothing specific to Go. The hard hard is, how do you register dependencies and create a system that automatically injects the correct dependency. Sorry but you missed the point.
Well, I don’t think it exactly did. The main package / file should be the only place where you resolve the dependencies (that is: instantiate db conn, repositories , services and any other object). It does not matter if you’re using a DI Container to resolve (i.g: Fx) or manually resolving it , as long as they are resolved at the main package. Your business layer only declares the constructor and its dependencies , who is resolving does not mattter to the business layer. :)
Ah, I have used this pattern without knowing this is what Dependency Injection is. Thanks for this video.
This is so good! Its hard to find good content on Go about more advanced topics. Thats an easy subscribe from me!
Thanks for your kind comment! 😊
How do you handle the mapping between domain objects and db tables?
Thanks for a very pragmatic example
What does this look like when you start to have 10, 20, 30 repos and services? How can you organize them with this pattern in mind? Are all of the services and repos created in main, and passed down through closures?
Btw I'm using this pattern for over years in a lot of my Go projects. I ended up using IoC library like Wire or Fx to wire my dependency automatically due to my codebase get bigger overtime. What's your opinion of using IoC library like Wire or Fx? I personally disagree with that but somehow makes my work easier. Thanks!
I've wondered this myself. I'm not a "native gopher". I come from languages that have no problem bringing in all the libraries to do whatever you want, and it seems to me that gophers have a little bit different philosophy. It feels a little weird having some initialization code that manually injects the things... So far, though, I'm manually injecting all the things. Would be nice to hear what's "idiomatic".
Great video and thank you for describing where in real time one can see such usage. You got me subscribed and thumbs-up!
I do it this way in most of my non-trivial Go work. The only aesthetically questionable part is the "newing up of all the things and injecting"- compared to Java Spring Boot, say (lol, but then you have to write Java). Otherwise, it's a total win, and you'll really thank yourself when it comes to unit testing.
Awesome. Thanks for the content
really useful thanks mate
Nice content Brooo keep share your knowledge
Thanks man! I will do :)
Good explanation mate
Thanks Daniel!
What linter do you use?
this is good, but as projects gets bigger you will find harder to maintain. IoC library should be considered
Good ❤❤❤
❤
This approach falls short. Interfaces should be defined where they are needed to follow the dependency inversion and the interface segregation rule.
Noice video
Thanks for watching!
Isn't dependency injection an anti pattern?
How so?
Make a production grade project with hard dependencies and try to change the database you are using to another one and let me know how it went 😂
@@B0re_d Easy, just use channels between the API part and the database interaction layer. Message passing makes it easy to actually decouple layers as long as you don't expose internal IDs from the db.
Interface objects that give you synchronous calls to interact with your DB without any way to bulk calls together or to optimize things are absolutely awful, since you throw away the perks of the DB but still get temporal coupling between the frontend and the DB interactions that makes it impossible to optimize anything, bulk calls together, or to refactor your architecture by using a message bus instead of writing straight to the db. Since interfaces like the ones mentioned in the video force the reads and writes to happen in a very specific order with no way to reorder them.
Go gives you the amazing ability to have daemons that manage different parts of your application. Use it.
@@BosonCollider I promise you that nobody watching this video is working on a project or even capable of working on a project of the kind you're recommending, and even if they were a developer at the level of being able to understand and properly manage the many, many potential pitfalls of the concurrency model, only 1 in 10 of that developer's projects actually would benefit from it over more traditional DI. If someone has just watched this video and learned about the repository pattern, they are nowhere near being capable of this and more likely will regret ever trying. I feel even worse for the poor sap who might inherit that monstrosity.
You just explained the general concept of DI, there was nothing specific to Go.
The hard hard is, how do you register dependencies and create a system that automatically injects the correct dependency. Sorry but you missed the point.
Well, I don’t think it exactly did. The main package / file should be the only place where you resolve the dependencies (that is: instantiate db conn, repositories , services and any other object).
It does not matter if you’re using a DI Container to resolve (i.g: Fx) or manually resolving it , as long as they are resolved at the main package.
Your business layer only declares the constructor and its dependencies , who is resolving does not mattter to the business layer. :)