Part I: Setup a Repository
How to structure/organize a project in production ?
It's almost time to code! But first, we'll need a code repository and for that we'll need to decide on the code organization and structure within the repository. Why is that needed though? If you don't give it much thought, then you have to be prepared for frequent refactors as your code base increases. That's why always create a skeleton structure of folders that will act as a foundation for further code development. Mind you, don't let your code base go rogue, follow the standards and things will fall into place.
The Pet Store Project Structure
Developers of different programming languages follow different guidelines. Java developers usually write it in the MVC approach while Python project structures are somewhat different and so on. There isn't any predefined way to structure projects, it completely depends on the developers and the project's requirements.
Based on one of previous posts ( and with a little more research), we have come up with a sample structure for our pet store project which will be used in our future posts too:
You can replicate this structure directly download the repository from our GitHub repo.
git clone https://github.com/gochronicles/petstore.git
The folders include:
pkg
The "pkg" folder will have all the code that can be used publicly in other packages and even in other projects. In our case, we have a subfolder call "models" which will have the domain definitions (similar to models in Java). That is, all the struct and interface definitions which will describe the data entities. This can be used by other packages which will implement the interfaces and business logic. For example, the REST (http) interface can use these models and so can the grpc, CLI or GraphQL interfaces.
internal
All private code, which cannot be imported in other applications will go in the internal package. each application will have a separate subfolder within it. There's a subfolder for the petstore application in our case which has multiple subfolders which includes:
- rest : All code implement the REST based APIs
- repo : Database related logic, including connecting to the database and performing operations on it. Each database will have a separate folder (postgres in our case)
- service: Any specific business logic required for the application
cmd
This folder will house all the main applications. That is, all main.go files for each application will go here under the subfolder having the application's name. The code under "cmd" will just have a small main function that will mostly import and use code from the "internal" and "pkg".
In our case, a subfolder "petstore" with the main.go file is present under /cmd. This will generate a binary called "petstore". The main.go file corresponds to REST interface of the application. If in future, you want, say, a CLI interface, then another subfolder with the name "petstorecli" will be created with its own main.go file.
Other folders
- build
directory to store files related to packaging and continuous integration. This includes Docker files, OS related package files (.deb, .rpm) and CI related configuration files - docs
documentation files generated by godoc along with other design and user documentation files - bin
All application binary files that will be generated after the compilation is completed successfully. - scripts
Additional script files like bash scripts, makefiles etc
Now that we have a structure in place, filling in the code is all the more easier. Want to know how to start? Then head over to the next post which dives right into implementation.