► Join my Discord community for free education 👉 discord.com/invite/bDy8t4b3Rz ► Become a Patreon for exclusive tutorials 👉 www.patreon.com/anthonygg_ Thanks for watching
Too many developers forget that the goal is solving the problem, not playing around with all the "computer science-y" stuff. Don't get me wrong, that stuff is what got me into programming but it doesn't pay the mortgage or buy the margaritas. 🍹👍
i dont remember who said it or where or how it was said but "Whats ultimately important is the value your program is going to provide to the user, not the tools you're building it with"
If you want to write a huge monolith then by all means use Clean Architecture, good abstractions, and all that stuff. But... Go is the best when it comes to microservices. And you don't need to add that kind of complexity to a microservice. You'll only burn all your time. Microservices don't usually live long and you will eventually kill them or rewrite completely. So... Do not overengineer things. Make it simple, make it fast, make it readable.
Thanks, very simple and straightforward. I think the "cmd" folder is only useful if your project has multiple executables, i.e. if you have multiple CLI tools, or a rest+grpc APIs
I often put every API handler in its own file because it's an entry point and you often need some extra helper functions logically tied to this entry point only. But all the middleware that is common to multiple entry points I put in a single file. It is very convenient to find and change them later.
Imagine building a house. 450 sqft, it's like a studio apartment. You don't need massive support beams, or reinforced foundation, etc. This would be like a minimal approach, no crazy deep nested folders, etc. Just solving the problem and done. Now imagine building a sky-scraper. You're going to need a hell of a lot more. This would be your gigantic enterprise application, with multiple go modules, folders & organization, documentation, etc etc. But you have to be aware of the scope of the problem, and fit that problem with the appropriate sized tactics.
Definitely agree. Lots of developers today see (and especially start with) small software problems to solve and forget that big software comes with its own set of problems that *do* have to be solved. No one made these patterns up for fun, they did it to get out of the hell that is a huge spaghetti code base that developers literally quit over. No, you don't need all the architectural patterns for hello world, but yes they do have a place when software grows to a certain size.
Great video, really helps me as someone new to Go! I however put my main package in a cmd/app folder simply because I don't want it laying around the 20 JavaScript/frontend config files lmao. Also love your style of humor
Good stuff! All projects should be born with a flat structure. If the need for restructuring arises, refactoring is cheap. Bearing with useless folders isn't.
Don't get me wrong but this has many downsides - refactoring - scaling - solving deep business problems - this will not work for team has different members because updating and writing everything in the root file will result my merge conflicts
Most software projects only have 2-3 developers anyway... many have a one dev per microservice policy. Any project that grows beyond 2-3 devs would already have scaled up to having most things separated out into directories a long time ago...
100%. That's partly why I like python so much... when I moved to C# I was lost for words at the insane over-engineering!!! Python let's you scale up the project structure as it is called for. I'm sure you can do the same I'm C# but it's not what the culture encourages
This video is so usefull for me, also if u can, make a video for creating video streaming server by pure golang and not with help of "HLS" like your video for large stream files.
Any time that you spend designing a more manteinable software and don’t respeat your self is priceless. Is not overthhink is arxhitecture. Any can write Lines of code and solve problems but build more manteinable software umm no sure
► Join my Discord community for free education 👉 discord.com/invite/bDy8t4b3Rz
► Become a Patreon for exclusive tutorials 👉 www.patreon.com/anthonygg_
Thanks for watching
Too many developers forget that the goal is solving the problem, not playing around with all the "computer science-y" stuff. Don't get me wrong, that stuff is what got me into programming but it doesn't pay the mortgage or buy the margaritas. 🍹👍
i dont remember who said it or where or how it was said but
"Whats ultimately important is the value your program is going to provide to the user, not the tools you're building it with"
If you want to write a huge monolith then by all means use Clean Architecture, good abstractions, and all that stuff.
But... Go is the best when it comes to microservices. And you don't need to add that kind of complexity to a microservice. You'll only burn all your time. Microservices don't usually live long and you will eventually kill them or rewrite completely.
So... Do not overengineer things. Make it simple, make it fast, make it readable.
YES! The crazy structures needed for code that's 1M lines long are usually overkill for microservices!
Thanks, very simple and straightforward. I think the "cmd" folder is only useful if your project has multiple executables, i.e. if you have multiple CLI tools, or a rest+grpc APIs
Stopped using 'cmd' folder after company's cybersec approached me the third time for running unkmown .exe with 'cmd' in the path. 😄
Finally a sane developer!
I often put every API handler in its own file because it's an entry point and you often need some extra helper functions logically tied to this entry point only.
But all the middleware that is common to multiple entry points I put in a single file. It is very convenient to find and change them later.
Imagine building a house.
450 sqft, it's like a studio apartment. You don't need massive support beams, or reinforced foundation, etc. This would be like a minimal approach, no crazy deep nested folders, etc. Just solving the problem and done.
Now imagine building a sky-scraper. You're going to need a hell of a lot more. This would be your gigantic enterprise application, with multiple go modules, folders & organization, documentation, etc etc. But you have to be aware of the scope of the problem, and fit that problem with the appropriate sized tactics.
Definitely agree. Lots of developers today see (and especially start with) small software problems to solve and forget that big software comes with its own set of problems that *do* have to be solved. No one made these patterns up for fun, they did it to get out of the hell that is a huge spaghetti code base that developers literally quit over. No, you don't need all the architectural patterns for hello world, but yes they do have a place when software grows to a certain size.
Great video, really helps me as someone new to Go! I however put my main package in a cmd/app folder simply because I don't want it laying around the 20 JavaScript/frontend config files lmao. Also love your style of humor
Good stuff!
All projects should be born with a flat structure. If the need for restructuring arises, refactoring is cheap. Bearing with useless folders isn't.
great edu vids, i've learned golang completely from scratch using your channel and patreon
Don't get me wrong but this has many downsides
- refactoring
- scaling
- solving deep business problems
- this will not work for team has different members because updating and writing everything in the root file will result my merge conflicts
Im the deviation. I decide
Most software projects only have 2-3 developers anyway... many have a one dev per microservice policy.
Any project that grows beyond 2-3 devs would already have scaled up to having most things separated out into directories a long time ago...
Awesome ! Proud to be part of HVE family!
You're really knowledgeable and hilarious! 😂
I'm glad I found your channel. Subscribed!
Will you please do a video on go-echarts? Specifically how to group and filter axes in bar or line charts.
Perfect. Just as I work.
1st make it work and let the customer happy and put money into my pocket.
2nd. refactor the code.
Simple as that. #go4ever
1. Just make it work.
2. Throw it away.
3. Write it better the second time using the info from step 1.
4. Margaritas!!!
100%. That's partly why I like python so much... when I moved to C# I was lost for words at the insane over-engineering!!!
Python let's you scale up the project structure as it is called for.
I'm sure you can do the same I'm C# but it's not what the culture encourages
With too many folders/packages also you can get the problem of cyclic depedencies.
So true
"You are not programming... you are confused. You are not a programmer... you are a configurator." -- Anthony GG ... priceless.
The title definitely caught my attention
I think I was forgeting main problem and was lost in my folder structuring...
You are cured now.
Don't diss my attention span senpai!
I've been watching these videos every day after work for a couple months now!
-- sincerely, a lurker
This video is so usefull for me, also if u can, make a video for creating video streaming server by pure golang and not with help of "HLS" like your video for large stream files.
second time the in the last couple days i've heard of "hexagonal" architecture. figured it's just DI.
Not exactly. It's more like onionskins. Inside you have the business logic, outside you have everything for I/O.
@@deNudge thanks, i'll have to dig a little deeper
What about if you build a lib.
At least the internal is very useful.
Isn't it?
You r the best
" honestly i don't know what is it"" 🤣🤣🤣🤣🤣
“You are not a programmer. You are confused” 😂
wonderful. Just do it, it doesnt matter
Very pragmatic 👍
support comment for youtube algos sheeesh
Any time that you spend designing a more manteinable software and don’t respeat your self is priceless. Is not overthhink is arxhitecture.
Any can write Lines of code and solve problems but build more manteinable software umm no sure
Thanks for this
Amazing videos! Thank you so much
Your comment about ports being equal to skill level 😂
No more 1337 or 3000 from now on.
another beer 🍻
👍🏻👍🏻👍🏻
sheeesh, so many mouse clicks, probably the most from all your videos
Lmao true that.
I feel pain every time he writes ACcount
I start this shit on stream))