gin.Context or context.Context?

[jarrodhroberson (Jarrod Roberson)]

The offical Go blog has this to say about Context

At Google, we require that Go programmers pass a Context parameter as the first argument to every function on the call path between incoming and outgoing requests. This allows Go code developed by many different teams to interoperate well. It provides simple control over timeouts and cancelation and ensures that critical values like security credentials transit Go programs properly.

Server frameworks that want to build on Context should provide implementations of Context to bridge between their packages and those that expect a Context parameter. Their client libraries would then accept a Context from the calling code. By establishing a common interface for request-scoped data and cancelation, Context makes it easier for package developers to share code for creating scalable services.

Does this meant that every call I make after I receive in a controller/handler should accept a context.Context as the first argument?

If so should I use gin.Context since I am using Gin or should I use context.Context to make it more generic and then cast to gin.Context when I need specific gin stuff?

Right now I pull everything I need from thegin.Conext and just pass that as parameters down the function calls to get data do the work and just pass back a result to be serialized.

I did not want to “pollute” the logic/data layers with front end specific code so I can call those functions without having to tie them to Gin?

I guess I know the answer, use context.Context but what is the best practice when it comes to Gin, and context.Context idiomatic Go practices?

[jarrodhroberson (Jarrod Roberson)]

So here is what I am doing, I have all my functions/methods between all the Incoming and Outgoing requests as recommended. They are all of context.Context and I just pass in the gin.Context right now and it gets converted into a generic context.Context reference.

Right now I think this is the best compromise. It gets me “google best practices” and does not time me to Gin. Not that it really matters since using another framework would most likely be a complete re-write because they are all differently opinionated.

But then I have been reading not to put database connections and other “client” type references in Context.Value() for some very good reasons. So I am not really sure why I need it. So I guess I am ticking all the boxes AND not coupling my lower level layers to Gin or the Controller/Request/Response