search

gilcrest / diygoapi

A Go RESTful API template
MIT License
539 stars 67 forks source link

How do you plan to avoid duplication when multiple binaries: worker, api, migration under cmd #153

Closed alok87 closed 1 year ago

alok87 commented 1 year ago

Any suggestion on how to avoid the duplication across the main.go of cmd/diy/main.go and cmd/worker/main.go.

I see you have cmd/cmd.go but it wont work for different binaries? Should we have generic functions there?

gilcrest commented 1 year ago

Hey @alok87! The cmd package is meant to be a shared package for functions you'd call from main.go. It is a similar setup to the commands package in hugo, except they only have one main.go in the project root.

I chose to have the cmd/diy subdirectory as it makes sense to me and is similar to the cmd setup in the wtf project which I drew a lot of inspiration from. You can have any number of subdirectories for your needs. Each one can have it's own subdirectory exactly as you mentioned cmd/diy/main.go, cmd/worker/main.go or whatever you like.

As for your last question: "I see you have cmd/cmd.go but it wont work for different binaries? Should we have generic functions there?" You are correct, the cmd.go file is geared towards running the server. It's just how I organized the files in the package though. You'll notice there are other files in the package that are not used as part of cmd/diy/main.go, for instance, the cmd/ddl.go file is for migrations, etc. The programs to call these other functions are in the magefiles directory right now as I'm using mage as my build tool. I am considering switching to task, and if I do, I would setup everything currently under magefiles as subdirectories under cmd if that makes sense.

alok87 commented 1 year ago

Looks good. Thanks for the detailed response.

I have seen one more pattern internal/boot instead of cmd/