Define project directory structure.

[aguzmans]

The app directories will be organized in a plugins system.

f. We will have a single config folder where one yaml or a few yaml files define options needed to run each of the apps we will create. g. The app directories will be organized in a plugins system. This plugins need to be just plugins that do not break the app if they change and the app is configured correctly. h. The config will have a section that defines the flow of a request and this flow needs to be flexible like to include and exclude components. For instace just as example: in the future we might have different plugins for compression, Antivirus, encryption/decryption and more than one storage class(Glacier/s3/disk). So in the configs it must be defined which one to use when and basic rules about them. It should be VERY flexible to be used in many different scenarios, for the MVP we will narrow the scope and will make it better and support more over time.

I propose something like this: https://github.com/aguzmans/cool-storage as initial approach. to be discussed once assigned.

Story Points: 3

[ezielramos]

Project directory structure

Project Structure Example

     Cool-storage-api 
      ├─ conf
      │    ├─ cool-api.yaml
      ├─ plugins
      │   ├─glacier
      │   ├─s3
      │   ├─encrypt
      ├─user
      │  ├─user_test.go
      │  ├─user.go
      ├─mysql
      ├─ldap
      ├─ .gitignore
      ├─ go.mod
      ├─ go.sum
      ├─ README.md
      ├─ main.go

in this possible structure we are going to define the packages by folders where the files name.go and name_test.go are in the same folder

Question

Do you think it is necessary to design the packages in folders attached to their corresponding tests?

Useful comands resume

• To generate the go.mod - go mod init
• To run test - go test ./... or go test -v .\some_test.go
• Using coverage test -- go test --coverprofile=coverage.out -- go tool cover --html=coverage.out