1. Repeatation
   • Package helloworld contains a function NewHelloWorld.
   • So the client would initialize the HelloWorld type as helloworld.NewHelloWorld which is simply repeatation of the fact that helloworld package contains a HelloWorld and is not recommended Package Names
   • This should instead be helloworld.New()
2. Interfaces
   • Package helloworld contains an interface HelloWorld and function NewHelloWorld returns this interface type instead of concrete type. Interfaces on implementor side as an abstraction has no meaning
   • Package helloworld should contain a concrete type HelloWorld which is returned by helloworld.New function as recommended here
   • Clients who need to use features of HelloWorld type can define interfaces with only the features they really need and inject instance of HelloWorld as an implementation.

This PR allows applications to run on Windows.

The application will not support graceful restart, since TableFlip doesn't have Windows support, but it is still adequate for users who use Windows machines for development and Linux for production.

It extracts the tableflip code into internal/platform/reloader with conditional compilation depending on which platform is being used.

I have not finished testing it yet, but I wanted to get it out here to see if you want any changes to it.

Hi @sagikazarmark I am an open source enthusiast and I am looking to expand my work portfolio. I would like to collaborate with your project for free, I can provide you with a logo for your project

Good day Skull C.

There is a folder .gen/api/openapi with generated code. I do not see it's used somewhere. What it is for? Could you please suggest a way how to use it ?

Embedding build times is generally poor form as it introduces undeterministic builds. To ensure the binaries are reproducible, we should be looking for SOURCE_DATE_EPOCH in the build environment as specified by the reproducible builds project.

https://reproducible-builds.org/docs/source-date-epoch/

Thanks for this awesome project.

Before I came into this project, I have no experience of gokit. I want to use this project to learn gokit and start my first gokit project. Is there any tutorial or more detailed document for gokit beginner to do things like steps of creating new service etc.

Best regards.

When running the init script in the boilerplate, import name might break alphabetical order.

This has been fixed for now in #50 , but we should make sure it continues to work in the future as well.

• [x] Check IDE settings
• [x] Write some test/lint rule?

The application was generated with

? Package name (/home/dima/develop/go-app1) github.com/dmdv/go-app1
? Project name (go-app1) 
? Binary name (go-app1) 
? Application name (go-app1) 
? Friendly application name (Go App1) Modern Go Application
? Update README (Y/n) Y
? Remove init script (y/N) n

When I tried to sync dependencies, I got the following error

go: finding module for package github.com/dmdv/go-app1/internal/app/go-app1
go: finding module for package github.com/dmdv/go-app1/internal/app/go-app1/todo/tododriver
github.com/dmdv/go-app1/cmd/go-app1 imports
	github.com/dmdv/go-app1/internal/app/go-app1: no matching versions for query "latest"
github.com/dmdv/go-app1/cmd/go-app1 imports
	github.com/dmdv/go-app1/internal/app/go-app1/todo/tododriver: no matching versions for query "latest"
github.com/dmdv/go-app1/internal/app/mga imports
	github.com/sagikazarmark/todobackend-go-kit/todo/tododriver imports
	github.com/sagikazarmark/todobackend-go-kit/internal/.generated/api/v1/graphql: malformed import path "github.com/sagikazarmark/todobackend-go-kit/internal/.generated/api/v1/graphql": leading dot in path element
github.com/dmdv/go-app1/internal/app/mga imports
	github.com/sagikazarmark/todobackend-go-kit/todo/tododriver imports
	github.com/sagikazarmark/todobackend-go-kit/internal/.generated/api/v1/rest/go: malformed import path "github.com/sagikazarmark/todobackend-go-kit/internal/.generated/api/v1/rest/go": leading dot in path element

And script generation completed with an error

The overall impression is that the template has never been tested and too much stuffed with the extra unnecessary functionality

The above mentioned configuration needs to be changed either in the jaeger config or the environment variable so that viper properly unmarshalls it into the application configuration ( Field name in the Config struct: CollectorEndpoint, env var name: v.SetDefault("instrumentation.jaeger.endpoint", "http://localhost:14268")

I am happy to push the PR if this is valid ...

Bumps github.com/cloudflare/tableflip from 1.2.0 to 1.2.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Using the latest go version and the latest main pull, I get the following error:

$ ./init.sh 
? Package name (/home/oipo/Programming/chargepoint/go/modern-go-application) nrg-playground
? Project name (nrg-playground) 
? Binary name (nrg-playground) 
? Application name (nrg-playground) 
? Friendly application name (Nrg Playground) 
? Update README (Y/n) 
? Remove init script (y/N) 
mv: cannot stat '.idea/project.iml': No such file or directory
./init.sh: line 36: .idea/modules.xml.new: No such file or directory
mv: cannot stat '.idea/modules.xml.new': No such file or directory
./init.sh: line 36: .idea/runConfigurations/All_tests.xml.new: No such file or directory
mv: cannot stat '.idea/runConfigurations/All_tests.xml.new': No such file or directory
./init.sh: line 36: .idea/runConfigurations/Debug.xml.new: No such file or directory
mv: cannot stat '.idea/runConfigurations/Debug.xml.new': No such file or directory
./init.sh: line 36: .idea/runConfigurations/Integration_tests.xml.new: No such file or directory
mv: cannot stat '.idea/runConfigurations/Integration_tests.xml.new': No such file or directory
./init.sh: line 36: .idea/runConfigurations/Tests.xml.new: No such file or directory
mv: cannot stat '.idea/runConfigurations/Tests.xml.new': No such file or directory
./init.sh: line 36: .vscode/launch.json.new: No such file or directory
mv: cannot stat '.vscode/launch.json.new': No such file or directory
mv: cannot stat 'cmd/modern-go-application': No such file or directory
find: ‘.gen’: No such file or directory

I love using https://github.com/ldez/seihon for multi-arch docker builds. Adding https://goreleaser.com might be another addition, though both are on the build, less on the code side. And golangci-lint and...

I was just reviewing the code, and I found a part that looks a little suspect..

https://github.com/sagikazarmark/modern-go-application/blob/master/cmd/modern-go-application/main.go?ts=4#L89

if ReadInConfig does not return an error, then configFileNotFound would be false, right? since the type assert from nil to viper.ConfigFileNotFoundError would fail?

err := v.ReadInConfig()
_, configFileNotFound := err.(viper.ConfigFileNotFoundError)
if !configFileNotFound {
	emperror.Panic(errors.Wrap(err, "failed to read configuration"))
}

# more stuff, including configuring the logger

if configFileNotFound {
	logger.Warn("configuration file not found")
}

it seems like the code will either always panic, or log a warning.

The viper shows the correct way: https://github.com/spf13/viper?ts=4#reading-config-files

if err := viper.ReadInConfig(); err != nil {
    if _, ok := err.(viper.ConfigFileNotFoundError); ok {
        // Config file not found; ignore error if desired
    } else {
        // Config file was found but another error was produced
    }
}

// Config file found and successfully parsed

Additionally, I don't think this is best practice anyway, since a configuration file should not be required if ENV variables are also an alternative. Maybe I'm also reading the code wrong...

This project is a great sandbox for trying out new practices, as well as a great boilerplate for new projects.

As for trying practices, it probably reached a point where the project is "ready", meaning adding new stuff would make it too heavy. Additional service integrations (config) should go into documentation / wiki / website.

Using the project as a boilerplate is not too easy, so this is what I would like to focus on next.

One of the issues is lacking documentation as pointed out in #130.

The other issue is the lack of tooling (code generation, scaffolding).

This is getting better every day in https://github.com/sagikazarmark/mga (especially code generation), but starting a new project is still too hard. So the next step should be a mga new command that creates a new project from the boilerplate. (And we can finally get rid of the crappy init.sh)

Last, but not least we need a better organization of the underlying projects. Right now the boilerplate relies on a few, loosely coupled projects under my account. They need better organization (probably an organization of their own).

Go Buffalo is an excellent example of what I would like to (ideally) achieve with this project.