STOP! This Is How You Structure Golang Applications

[@anthonygg_]

► Join my Discord community for free education 👉 discord.com/invite/bDy8t4b3Rz ► Become a Patreon for exclusive tutorials 👉 www.patreon.com/anthonygg_ Thanks for watching

[@EricFialkowski]

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. 🍹👍

[@tehseensajjad1003]

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"

[@su1cedek]

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

[@pelic9608]

Stopped using 'cmd' folder after company's cybersec approached me the third time for running unkmown .exe with 'cmd' in the path. 😄

[@vitiok78]

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.

[@AlbertBalbastreMorte]

YES! The crazy structures needed for code that's 1M lines long are usually overkill for microservices!

[@vitiok78]

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.

[@ElderSnake90]

Finally a sane developer!

[@ryanjoy0000]

Awesome ! Proud to be part of HVE family!

[@JackWeaver]

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.

[@aqezzz]

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.

[@CorleyPC]

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.

[@mm100latests5]

great edu vids, i've learned golang completely from scratch using your channel and patreon

[@kavereon]

You're really knowledgeable and hilarious! 😂 I'm glad I found your channel. Subscribed!

[@toroktechnology7420]

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

[@anthonygg_]

Im the deviation. I decide

[@austecon6818]

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...

[@WaldirBorbaJunior]

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

[@EricWAtchesVideos]

Will you please do a video on go-echarts? Specifically how to group and filter axes in bar or line charts.

[@thesaintseiya]

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

[@idearat0]

"You are not programming... you are confused. You are not a programmer... you are a configurator." -- Anthony GG ... priceless.

[@EnterCloud]

The title definitely caught my attention

[@vitiok78]

1. Just make it work. 2. Throw it away. 3. Write it better the second time using the info from step 1. 4. Margaritas!!!

[@90hijacked]

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

[@austecon6818]

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

[@Nexjsdeveloper]

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.

[@DUKENNSCHMILPs]

With too many folders/packages also you can get the problem of cyclic depedencies.

[@anthonygg_]

So true

[@suikast420]

What about if you build a lib. At least the internal is very useful. Isn't it?

[@aslkdjfzxcv9779]

second time the in the last couple days i've heard of "hexagonal" architecture. figured it's just DI.

[@deNudge]

Not exactly. It's more like onionskins. Inside you have the business logic, outside you have everything for I/O.

[@aslkdjfzxcv9779]

@@deNudge thanks, i'll have to dig a little deeper

[@Nexjsdeveloper]

You r the best " honestly i don't know what is it"" 🤣🤣🤣🤣🤣

[@dr3w979]

Thanks for this

[@tgaming2518]

Amazing videos! Thank you so much

[@adanpalma4026]

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

[@guledomer]

wonderful. Just do it, it doesnt matter

[@hassananwar2431]

I think I was forgeting main problem and was lost in my folder structuring...

[@anthonygg_]

You are cured now.

[@Flascoo]

support comment for youtube algos sheeesh

[@GrahamAtDesk]

Very pragmatic 👍

[@cipcip4986]

another beer 🍻

[@goocarry_dailyroutine]

👍🏻👍🏻👍🏻

[@nodidog]

Your comment about ports being equal to skill level 😂

[@anthonygg_]

No more 1337 or 3000 from now on.

[@charlesbcraig]

“You are not a programmer. You are confused” 😂

[@bodunjo]

I start this shit on stream))

[@TheSupahG]

sheeesh, so many mouse clicks, probably the most from all your videos

[@anthonygg_]

Lmao true that.

[@su1cedek]

I feel pain every time he writes ACcount