The offical Go blog has this to say about
At Google, we require that Go programmers pass a
Contextparameter 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
Contextshould provide implementations of
Contextto bridge between their packages and those that expect a
Contextparameter. Their client libraries would then accept a
Contextfrom the calling code. By establishing a common interface for request-scoped data and cancelation,
Contextmakes 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 the
gin.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?