Development mode

[manucorporat]

IDEAS

• HTML rendering without cache.
• Additional logging
  • Log existing routes
  • Log listening port

API

• Debug mode by default
• Using an environment variable called GIN_MODE that is loaded at init time.

$ export GIN_MODE=release

• Developer-API.
  Any call to this method would replace the default option.

gin.SetMode(gin.DebugMode)

Log example:

~ $ go run test.go
[GIN-debug] POST  /v1/login                 --> main.loginEndpoint (3 handlers)
[GIN-debug] POST  /v1/submit                --> main.submitEndpoint (3 handlers)
[GIN-debug] GET   /v1/read                  --> main.readEndpoint (3 handlers)
[GIN-debug] Listening and serving HTTP on :8080

[manucorporat]

Check out the first commit: 809eee8

[themartorana]

I may be missing something, but how would I interrogate the current mode in my code?

[manucorporat]

ok, right now there is not a API to interrogate the current mode, you just can change it.
I am ok to add an API, but could you explain an use case for that?

[themartorana]

@manucorporat our use-case is of course likely specific to our own needs, but they exist in the level of logging (which I realize can be pushed off to log configuration, but marrying the two makes sense to me) and for us, attaching additional debug information to a returning JSON packet across our API.

Currently we have a single middleware that wraps up all returning responses from handlers into consistent response packets, interrogating errors and return codes for logging and reporting purposes, and attaching any additional information to a packet that is "global" if you will. Being able to make packets lean for production and information-rich at debug/testing time (think staging/development servers) makes sense in our case.

[manucorporat]

fd2e342

[themartorana]

Awesome!

[roosmaa]

I wanted to create a new issue, but it seems more appropriate to comment here. I think the default mode shouldn't be debug mode, but rather release mode.

Currently the mode switching is fairly well hidden and it's very easy to miss. Deploying the app without being aware of this means that the app is deployed in default=debug mode. This is fairly bad.

Instead of defaulting to debug mode, I suggest displaying a hint about it instead when Gin is starting up. That way developers will discover it and update their environment with the appropriate variable and in production it's only taking up 1 line of log space.

[manucorporat]

@roosmaa you are probably right, it's very easy to miss that.
I am going to think about that. thanks!

[phemmer]

I think the default mode shouldn't be debug mode, but rather release mode.

I second this. I find the debug output extremely annoying. And it's more annoying having to go and turn this off in every single package that imports gin, otherwise your test log is spammed with warning messages and other output (the warning alone is 4 lines long).

When you deploy a gin app, the defaults should be that the app runs with minimal configuration.
Also, in every app I've ever used, debug mode is off by default, and you turn it on when you want it.

I feel there are 2 appropriate rules from the unix philosophy here:

• Rule of Least Surprise
  Developers should design programs that build on top of the potential users' expected knowledge; for example, ‘+’ in a calculator program should always mean 'addition'. This rule aims to encourage developers to build intuitive products that are easy to use.
• Rule of Silence
  Developers should design programs so that they do not print unnecessary output. This rule aims to allow other programs and developers to pick out the information they need from a program's output without having to parse verbosity.

[MrGossett]

+1 for @phemmer's comment. Default mode should be release mode.

[ezeql]

I agree with @roosmaa, @phemmer and @MrGossett.