Comments (11)
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.
from gin.
Check out the first commit: 809eee8
from gin.
I may be missing something, but how would I interrogate the current mode in my code?
from gin.
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?
from gin.
@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.
from gin.
from gin.
Awesome!
from gin.
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.
from gin.
@roosmaa you are probably right, it's very easy to miss that.
I am going to think about that. thanks!
from gin.
+1 for @phemmer's comment. Default mode should be release mode.
from gin.
I agree with @roosmaa, @phemmer and @MrGossett.
from gin.
Related Issues (20)
- Binding a non mandatory file parameter will directly result in an error message HOT 1
- ```ShouldBindBodyWith()``` will more types be supported in the future? HOT 2
- [Community Discussion] What's the status of Gin? HOT 6
- url parameters / path parameters /something(:id) HOT 7
- Is there any way to change the http request method? HOT 2
- Golang-Gin HOT 4
- How to use βAcceptedβ HOT 1
- Trailers sent twice if no body written HOT 2
- Pass variable in rout HOT 1
- Register tauri:// scheme (or allow custom schemes upstream?)
- please support get parms from Transfer-Encoding:compress-deflate
- unexpected EOF during install HOT 1
- sse panic on fasthttphandler HOT 1
- Will it be made into a more comprehensive framework later on? HOT 4
- How does the gin close the log file? HOT 3
- Should we use url.PathUnescape instead of url.QueryUnescape when UnescapePathValues is true
- go get failed: The requested name is valid, but no data of the requested type was found HOT 1
- Attach Response Headers (or middlewares) to redirected requests (CORS issues) HOT 1
- Should context.GetRawData() also copy body to BodyBytesKey? HOT 3
- YAML BindBody should not parse JSON content HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gin.