I literally followed your tutorial on how to build an API in Go (I did a couple of changes, like using Gin + GORM, but fundamentally it follows your teachings) My teammates congratulated me and now we have a new micro service running in PROD. Ofc, I didn't take the credit but recommended your channel in the startup that I am working Thank you so so much good Sir ! God bless
Coming from Laravel where everything is setup and ready to go, it's both refreshing and frustrating having to learn to build stuff from scratch, I guess that's the price of becoming better at programming.
08:24 Don’t you think that according to DDD the validateOrder should be a method on Order type? That is it is responsibility of that part of domain to validate itself?
Great! I'm starting in Golang now, and structure is a big pain, I worry about the size of the files and files in a big codebase. I know we have this same problem in other languages, but some of them have frameworks that facilitate to have structured modules without name conflict, the package in go is good at same time is bad haha. In my side project, I'm organizing inside internal with three dirs application, domain and infra. in application I have more two dirs, handlers and usecase, but usecases it's been a huge that I'm not comfort to use this in real project. The structure you showed seems to be better than I'm using, but maybe the tradeoff will be the size of files.
I am working as a go developer for almost 4 months proffessionaly now, and 1 year coding in go i studied hexagonal architecture a lot specially that i used to work with .Net so it really fits the echosystem of .Net but Go is not designed for abstractions and interfaces, i mean if we will have only one implementation why we just depends on concrete types .. it will be much easier in debugging and understanding the code for new project contributors, I know that somethimes we really needs interfaces and some abstractions but in my opinion GO is not deisged for that .. what do you think ?
The architecture you mentioned by layers separation is typically good and we are actually working with it through each microservice, but my comment was about when you mentioned that we should inject an interface for the service.
Thanks for the feedback! But how do u usually handle testing? Imo if I pass an implementation and not an abstraction it's going to make testing a nightmare for me. Because golang interfaces are so practical it removes a bit that barrier.
I miss-understood the title of your video .. i hoped that it would be project structuring video in Go, not layered architecture (as a java spring developer, i really liked to see how modules and packages are devided in non-OO language) That said, what was explained, was pretty good
Thanks for the feedback! Yee I had a hard time choosing a title for this one because I wanted beginners developers that are looking on how to structure their apps to don't stress much about it. However now as u suggested, for more advanced folks might seem misleading... I'll think about it!
I have cloned a Spotify web API using Go. My experience with Go is pretty good, here some pros and cons. - Pros: library well documented, gin support is very good. Package in Go is far way better than module in Python imo. And I believe that long file is not a problem, the problem is the whether your project is tight coupled. - Cons: if you are not using orm, a lot of boilerplate code waiting for you, this is the situation when I working with pgx, but I hate "maigc code" from orm and complex query need a lot of time to figure out. Swagger API can't be auto generated like FastAPI, you need external package like Swaggo and play around with annotation, a lot of boilerplate again. But I believe if you familiar with Java, this is not big issue. Anw, I have good experience when coding with Go more than coding five lines then need to reading ten pages of document in Spring Boot.
You can have multiple files in the same package and so you can have as many files as you want and all of them will be exported as one package at the end.
Please, don't record videos unless you master the craft because this spurious information spreads swiftly. Packages are meant to be used as abstraction layers in Go. Also, don't split your code based on technical details. Creating a file called types is a sin. More, you merged composition root and the code which is completely wrong.
Relax 😂😂😂 Jesus. Who the fuck are you? A lot of people found this video very helpful. Including me. Do what works for you. If this doesn't, move along.
I literally followed your tutorial on how to build an API in Go (I did a couple of changes, like using Gin + GORM, but fundamentally it follows your teachings)
My teammates congratulated me and now we have a new micro service running in PROD.
Ofc, I didn't take the credit but recommended your channel in the startup that I am working
Thank you so so much good Sir ! God bless
You're too kind! Thank you so much for your words, they really mean a lot!
I'm glad I helped! All the best for you and your team 💪
bro i love your content , but as a beginner i found the content hard to digest. but after a little bit digging , then i found your content great
First sane mental model approach to programming I have seen in a long time. Simple, efficient, clean and flexible.
Great content. Congratz, Tiago.
Please, keep doing this good work
Great content man, keep it up, you will go high!
Thank you so much!
Thanks Tiago for these concepts , I will watch API video next . Thanks .
Coming from Laravel where everything is setup and ready to go, it's both refreshing and frustrating having to learn to build stuff from scratch, I guess that's the price of becoming better at programming.
08:24 Don’t you think that according to DDD the validateOrder should be a method on Order type? That is it is responsibility of that part of domain to validate itself?
You deserved it +1 sub 🎉
Thanks a lot boss, you are a legend. 🙇
💪
Great!
I'm starting in Golang now, and structure is a big pain, I worry about the size of the files and files in a big codebase. I know we have this same problem in other languages, but some of them have frameworks that facilitate to have structured modules without name conflict, the package in go is good at same time is bad haha.
In my side project, I'm organizing inside internal with three dirs application, domain and infra. in application I have more two dirs, handlers and usecase, but usecases it's been a huge that I'm not comfort to use this in real project. The structure you showed seems to be better than I'm using, but maybe the tradeoff will be the size of files.
Ye I feel you!
The structure you're using it's also very popular im big projects, I've seen a couple times.
In go I see a lot the division by feature as well (something similar to the usecases folder).
Excellent explanation!
Thanks for sharing buddy.
I really like your channel, could you bring content about grapqhl with go?
Nice, keep going
What software are you using to draw? Tks bro
It's called Eraser
🔥🔥🔥🔥
Please what tool did you use for the flowcharts and your visual representations, thanks
It's called "Excalidraw"
@@TiagoTaquelim thanks
Can you share the project code?
I am working as a go developer for almost 4 months proffessionaly now, and 1 year coding in go
i studied hexagonal architecture a lot specially that i used to work with .Net so it really fits the echosystem of .Net
but Go is not designed for abstractions and interfaces, i mean if we will have only one implementation why we just depends on concrete types .. it will be much easier in debugging and understanding the code for new project contributors, I know that somethimes we really needs interfaces and some abstractions but in my opinion GO is not deisged for that .. what do you think ?
The architecture you mentioned by layers separation is typically good and we are actually working with it through each microservice, but my comment was about when you mentioned that we should inject an interface for the service.
Thanks for the feedback!
But how do u usually handle testing? Imo if I pass an implementation and not an abstraction it's going to make testing a nightmare for me. Because golang interfaces are so practical it removes a bit that barrier.
I miss-understood the title of your video ..
i hoped that it would be project structuring video in Go, not layered architecture (as a java spring developer, i really liked to see how modules and packages are devided in non-OO language)
That said, what was explained, was pretty good
Thanks for the feedback!
Yee I had a hard time choosing a title for this one because I wanted beginners developers that are looking on how to structure their apps to don't stress much about it.
However now as u suggested, for more advanced folks might seem misleading... I'll think about it!
what your theme ?
Gruvebox
do files get very long in golang? how do people manage that. eg in java you create multiple controllers, services ect how does that translate
I have cloned a Spotify web API using Go. My experience with Go is pretty good, here some pros and cons.
- Pros: library well documented, gin support is very good. Package in Go is far way better than module in Python imo. And I believe that long file is not a problem, the problem is the whether your project is tight coupled.
- Cons: if you are not using orm, a lot of boilerplate code waiting for you, this is the situation when I working with pgx, but I hate "maigc code" from orm and complex query need a lot of time to figure out. Swagger API can't be auto generated like FastAPI, you need external package like Swaggo and play around with annotation, a lot of boilerplate again. But I believe if you familiar with Java, this is not big issue.
Anw, I have good experience when coding with Go more than coding five lines then need to reading ten pages of document in Spring Boot.
You can have multiple files in the same package and so you can have as many files as you want and all of them will be exported as one package at the end.
Please, don't record videos unless you master the craft because this spurious information spreads swiftly. Packages are meant to be used as abstraction layers in Go. Also, don't split your code based on technical details. Creating a file called types is a sin. More, you merged composition root and the code which is completely wrong.
You're based. That is your opinion... you do whatever you want as long you solve whatever problem the business has and make money.
@@TiagoTaquelim It matters because these faulty ideas shoot us in the foot, thwarting us from achieving business goals.
Relax 😂😂😂 Jesus. Who the fuck are you? A lot of people found this video very helpful. Including me. Do what works for you. If this doesn't, move along.
Make a video explaining your way then chief