Go is very flexible when it comes to writing apps and structuring them.
Though, you should always write idiomatic Go when possible.
While not thinking about structuring your apps is okay, but as your app starts to grow, you have to have a structured architecture so that it's easy for you and other devs to know how things connect in your app. It also avoids duplication of code and, maybe, will help you scale heights.
I was looking for that one structure I could follow, but almost everyone has their stuff.
So, I started reading blogs and even started reading open-source projects and finally picked the best parts.
Before showing you the structure, I'll try to build your mental model for this architecture by this analogy.
Let's say you want to start a business and the product your building is a Dancing Doggos App, which will contain dancing videos and photos of dogs.
Exciting right?
Now, what should we do next?
The first that comes to my mind is management that can manage our product specific to our needs.
So we need to hire product managers, CEO, CTO and other fancy managers with those suits and ties :p
Next, we need is the people who'll be working under our Managers.
So, marketing team, sales team, and a team of amazing people aka developers :p
Now that we have everything ready to go, we need to think about how everything will work.
The following few lines are going to be the crucial part of all the useless stuff I wrote.
Product Owners -
- They want their idea out in the market.
- They only talk to the managers.
- They don't care how you do it ( of-course not if its unethical :p)
Managers -
- They are the people who are responsible for getting the work done.
- They manage the people working under them to work according to the needs
- Their work is mostly product specific.
- Their decisions and choices are governed by the product they are building. (A Manager who is working for Pepsi will have to make different decisions if he starts working for Gucci)
Teams -
- They usually don't care what you are building
- They usually don't have to change their decisions based on the product (A Go Developer working on Go in Pepsi will also be working on Go if he makes a switch to Gucci).
- Teams are usually independent and don't require any other team to make their work done. ( Marketing team doesn't depend on Devs team to work)
You might be thinking I have read so much and still haven't found anything I can take away from this but please bear 🧸 with me for the next few minutes.
Building upon our business workflow, we can structure our app.
/app
Product owner
This folder contains our business logic, and that's it.
This directory doesn't care about what database driver you are using or which caching solution your using, or any third-party apps.
Its only job is to provide the business-related details, including structuring the models, authorizing the clients, storing them in the database, or sending it to the clients.
/platform
teams
This folder contains all the platform-level logic that will build up the actual product, like setting up the database, Redis instance, or maybe a router.
All of the packages inside this directory are independent of each other.
Packages inside this folder also don't care what's inside /app or /cmd
/cmd
Management
This folder contains all the application-specific code tailored only for your business use case—things like configuration, logging, and DB migrations.
This directory talks to the /app for instructions, and then it takes the services offered by /cmd and finally delivers the product
This directory is the Mitochondria of our application (Bad science pun, sorry :p)
tl;dr
Your app's business-related logic shouldn't care about the platform and app-level code like routes, databases, and third-party packages you are using.
Your Application-level code (/cmd) like configurations and routes will vary according to different services or business ideas.
Your Platform level code doesn't care what you are building, and they should only have a single purpose. It shouldn't produce any side-effects inside your business logic.
Here is the WIP project uses the above structure
The project below is just a work in progress and only for my learning purpose, but the structure is handy if you want to use it in your next project.
Top comments (6)
On the contrary I'd advocate for organising by responsibility [1]. Furthermore, I'd suggest that when programming you shouldn't focus on the layout of the source code files and more on the code you're writing. As your project grows the abstractions and patterns that you use will present themselves to you. Using this, you can easily begin refactoring your code into something more logical and manageable. I'd always suggest a new comer to Go to just start writing code, and to not spend their time designing the layout of the source code in their program. I view designing the layout of a program's code before writing it as no different than measuring your own coffin. Sure you may know how the program will operate at a high-level, but you don't know the intricacies yet, nor how the data will flow through your program. This should be the focus in my opinion, not the structure of directories or files.
[1] - rakyll.org/style-packages/#organiz...
I know it looks a lot and I get your point but what bad it'll do if you take some time out to think about the layout before writing the code.
You risk putting your code in places where it might not belong, and this makes refactoring your code harder. Write the obvious code first, and refactor from there. And again, you want to avoid making too many assumptions about what your program could do, as this diverts your attention away from what the program will do. You figure out what your program will do by writing it.
Not if you know what your layout is and what you are trying to achieve.
again, if you know what you are doing than making assumptions is not bad
a more in-depth guide,
Standard Go Project Layout
Standard Go Project Layout
Translations:
Overview
This is a basic layout for Go application projects. It's
not an official standard defined by the core Go dev team; however, it is a set of common historical and emerging project layout patterns in the Go ecosystem. Some of these patterns are more popular than others. It also has a number of small enhancements along with several supporting directories common to any large enough real world application.If you are trying to learn Go or if you are building a PoC or a simple project for yourself this project layout is an overkill. Start with something really simple instead (a singlemain.gofile andgo.modis more than enough).As your project grows keep in mind that it'll be important to make sure your code is well structured…github.com/golang-standards/projec...