Project directory structure

[GoingToGo]

Hi,

Assume that I have an Football API and trying to the construct a directory structure to make things organised. When we look at the two structures below, which one is more GO-ish way of doing things? I come from PHP (Symfony) background and the V2 is the way to go but I have a feeling that the V1 is the ideal one for GO. Am I right to assume that?

Thanks

V1

.
|_ cmd
  |_ main.go
|_ internal
  |_ app
    |_ football.go
    |_ config.co
    |_ middleware.go
    |_ router.go
    |_ server.go
  |_ team
    |_ controller.go
    |_ entity.go
    |_ repository.go
    |_ service.go
  |_ league
    |_ controller.go
    |_ entity.go
    |_ repository.go
    |_ service.go

V2

.
|_ cmd
  |_ main.go
|_ internal
  |_ app
    |_ football.go
  |_ controller
    |_ league.go
    |_ team.go
  |_ config
    |_ config.co
  |_ middleware
    |_ middleware.go
  |_ entity
    |_ league.go
    |_ team.go
  |_ http
    |_ router.go
    |_ server.go
  |_ repository
    |_ league.go
    |_ team.go
  |_ service
    |_ league.go
    |_ team.go

[Yamil_Bracho]

I think what it should be needed it is organize your code in order to make easy to understand and easy to fix or update.
For me, V1 it is the way to go because i always try to organize my code by feature, by businees funcionality, so ite could be easy to substitute one of them for a particular way to do, according business needs or maybe you can use on of those units in another application (For example if you have an application for football and another for baseball, you can reuse team folder).

Just my two cents…

[hollowaykeanho (Holloway)]

@GoingToGo

the V2 is the way to go but I have a feeling that the V1 is the ideal one for GO. Am I right to assume that?

@Yamil_Bracho

For me, V1 it is the way to go because i always try to organize my code by feature, by businees funcionality, so ite could be easy to substitute one of them for a particular way to do, according business needs or maybe you can use on of those units in another application

The vX directory is * ahem *, according to Go dev, a way to ensure the package is backward compatible, when the major number is greater or equal than 2. It’s complying to Semantic Versioning requirement.

Since an increment of major number (e.g. v1.21.0 → v2.0.0), something is expected to break and it is not backward compatible. Your v1.21.0 users may not be able to migrate to v2.0.0 in time when you release it.

Hence, the vX directory comes in to provide smooth import under the same package repository, even the major update is non-backward compatible. The X denotes the major number (v1 → v1.21.0 and v2 → v2.0.0). Your v1.21.0 can retain to use v1 directory, while your new users uses v2.

If the project is assumed complying to semantic versioning, then we can safely says V2 is better than V1 (since they progress from there). Otherwise, you need to contact the maintainer for further information.

As for my soft cough…

I have no idea why they came up with that idea and create codes duplication across major versions.
Checking out git tag is good enough but currently it’s unavailable as they impose strict rules against vX directory.