I want to run some Lambda alias specific code before my main function starts executing. It currently looks like this
func init() {
// Trying to get Lambda function alias here
}
func main() {
adapter = chiproxy.New(r)
lambda.start(lambdaHandler)
}
func lambdaHandler(ctx context.Context, req events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
c, err := adapter.ProxyWithContext(ctx, req)
return c, err
}
req in lambdaHandler has the info I need but I don't know how to get it in init()?
I don't think you can get the alias before the function has been passed a request. lambda automatically provides a number of environment variables but alias is not one of them.
That's probably because the alias is just a pointer to the version; you could have many aliases pointing to the same version, but the same function runtime could be initialized for all of them. So it wouldn't make sense to provide any particular alias at initialization time.
I want to run some Lambda alias specific code before my main function starts executing
But the function's runtime isn't specific to an alias, it's specific to a version. In fact you could create a new alias after the version had been instantiated, and the same cached runtime could be used.
I think I can see why you might want to have invokers call the same function with different aliases, but I'm not sure it's going to be a low friction path to achieve what you want with aliases. Consider whether you might instead want to create bunch of different functions - which could have the same codebase, and have init choose a proper handler or do other init based on the function name instead of its alias.
Related
Using the Go language I am writing a function that uses a custom error variable, e.g.
func readEnv() (map[string]string, error) {
var ErrConfig = errors.New("Configuration Error: Variables starting with the right prefix are not even")
if this {
return nil, ErrConfig
}
I declare this as a local var to avoid declaring it as a package-level var which is not recommended (and marked as issue from the linter if I am not mistaken)
The problem arises when I want to unit test this fxn and want to also test the error path (in which case the fxn should return the above error which however has not access to.). Now, the only way I can think of to address this is to re-declare this variable in my table test.
Which is the right way? Declaring ErrConfig as a package-level variable or just re-declaring it in the unit test fxn?
Does it matter to the caller of readEnv() what error you return?
If it doesn't matter, your test shouldn't care either, just check if the returned error is nil or not.
If it matters, in your current solution callers can't do any better than you in your tests. If it matters and clients should be able to tell, you have to export some kind of mechanism to test / examine the returned error.
One solution is to move ErrConfig to a package level variable. This is accepted, used numerous places in the standard lib too, e.g. io.EOF, io.ErrClosedPipe.
This is not the only solution though. You could make Errconfig unexported (e.g. errConfig), and provide an exported function to test an error, e.g.:
var errConfig = errors.New("Configuration Error: Variables starting...")
func IsErrConfig(err error ) bool {
return err == errConfig
}
This is also used in many places in the standard lib, e.g. os.IsExist(), os.IsNotExist()
You could also make the returned error implement an exported interface, and callers can check using a type assertion if the returned error implements that, providing extra functionality for the returned error.
I have this:
var wd, _ = os.Getwd()
var advanceAgreementTemplateBytes, _ = ioutil.ReadFile(path.Join(wd, "/docs/templates/advance-agreement.template"))
var advanceAgreementTemplate = string(advanceAgreementTemplateBytes)
var t, _ = template.New("advance-agreement").Parse(string(advanceAgreementTemplate))
func sendAdvanceEmail(user *common.User, amount *apd.Decimal, fee *apd.Decimal, created time.Time) {
// use variables `t`, `advanceAgreementTemplate` etc here
}
I want to be able to handle the errors in the cached variables instead of using _ instead of err. Is the only way to do this is to use func init()?
If you want to error-check these, use func init or just initialize them in main.
Not all calls have Must variants, and such variants don't make sense for all calls. Don't forget that the Go way is to do proper error checking. Having Must wrappers for all possible failing calls would encourage a bad programming style, where instead of handling and propagating errors, every error would crash by default.
It's very easy to write your own Must wrappers if all you need is to crash the program on error.
The benefit of writing your own Must wrapper is that you could provide a much better error message - another thing Go encourages. ioutil.ReadFile will just say "open /docs/templates/advance-agreement.template: No such file or directory".
I am doing some web develoment using the go programming language using the package html/template. At some point of the code, I need to call the function template.ParseFiles(...) so I can create a template from those files ad then execute it using temp.Execute(w,data). I would like to know if it is better to create the template on each request or to do it once in the main and declare a global variable.
Right now I do it on each request on my handle functions, like most tutorials do. However, I don't know If I'm wasting resources by doing it on each request instead of having them as global variables.
This is how it looks on each request
func ViewStats(w http.ResponseWriter, r *http.Request) {
//Get stuff from db and put them in data
//...
//return data to user
tmp, err := template.ParseFiles("views/guest-layout.html",
"views/stats.html")
if err != nil {
fmt.Println(err)
} else {
tmp.Execute(w,data)
}
}
I would like to know if this is better:
var temp1 template.Template
func main() {
temp1, err = template.ParseFiles("file1","file2")
//...
}
As usual: It depends.
But first some nuance:
You should never do template parsing (or anything else interesting) in your main() function. Instead, your main() function should call methods (or a single method) that kicks off the chain of interesting things in your program.
Go doesn't have globals, so it's not actually an option to store your parsed templates in a global variable in the first place. The closest Go has to global variables is package variables. You could store your parsed templates in a package variable in the main package, but this is also bad form, as your main package (except for tiny, trivial programs), should just be an entry point, and otherwise nearly empty.
But now, on to the core of your question:
Should you parse templates per request, or per run?
And here it depends.
If you have templates that change frequently (i.e. during development, when you're constantly editing your HTML files), once per request can be best.
But this is far less efficient than just parsing once, so in production, you may wish to parse the templates once on startup only. Then you can store the templates in a package variable, or better, in a struct that is initialized at runtime. But I leave that to you.
But what may be best is actually a bit of a compromise between the two approaches. It may be best to load your templates at start-up, and re-load them occasionally, either automatically (say, every 5 minutes), or watch your filesystem, and reload them whenever the on-disk representation of the templates changes.
How to do this is left as an exercise for the reader.
I am currently trying to work on a small Go project, and I have a problem I am trying to solve.
I'm currently using github.com/jinzhu/gorm to handle database operations for the backend of a GraphQL server, and I wanted to be able to store the DB connection in a global variable accessible throughout the entire project (including sub-packages).
My first attempt was at creating a variable named db by doing the following in my main.go file:
var db *gorm.DB
var err error
then inside the init() function:
func init() {
db, err = gorm.Open("postgres", "credential stuff here")
db.AutoMigrate(&modelStructHere)
defer db.Close()
}
There isn't any crashing, but I would assume due to scoping, the db variable is only usable inside main.go, but I also need to be able to use this inside gql/gql.go, where my GraphQL resolver is currently located.
Perhaps I should move this chunk of code (DB init) to the actual resolver file, since there's really no use for DB operations outside of such a thing anyway, so maybe that's the problem?
Thanks in advance!
Alex's comment is spot on. Create a folder named "database" and inside put a file called "database.go" containing this:
package database
// the imports go here
var DB *gorm.DB
Now you can use it wherever you like with database.DB. You should not make the error variable global, handle it in the same function that initializes the DB. The init function can be in any place, usually you want it at the beginning of your program in the main function.
I'm using gin gonic as an HTTP framework and I need to group some paths with shared variable by like this:
ur := r.Group("/")
ur.Use(package.Prepare)
{
ur.GET("/", package.Home)
}
Inside the Prepare handler, I declare package variable like
package.tplPath because I want all sub routes can access to this variable instead of rewrite the code in each http handler.
var tplPath = ""
func Prepare(c *gin.Context) {
_, filename, _, _ := runtime.Caller(0)
s := helper.RelativeFilePath(filename)
tplPath = s[1:len(s)] + "template/"
}
I don't know how Go works with each process, and variables for each http request. If a variable was declared in package level, will it be set after each http request?
Is this considered good practice? If not, why not?
This is not threadsafe, package variables are shared across all goroutines, and modification in one routine will change the value in all the others, causing a data race.
In general; try and avoid using package level variables where possible.
Edit:
In go, packages are a kind of module. There exists only one instance of a package for any given import path (basically package name). This means that there is only 1 instance of any variable at package level.
Package variables are shared, global state. All accessors of that variable will be accessing the exact same memory.
It does not matter what type the package variable is, struct / string / int etc. If it is defined at package level, all accessors of that variable will share the same instance of it.
If (as with http servers) you have concurrent code, there will be multiple accessors of that variable at the same time. In some situations this is fine, like when that variable is only ever read, but it appears that in your case it will be modified. Making this code racy!
The tplPath is a global variable, all routine will access the same memory address, and set after each http request.
If you want set just once, and the tplPath not depend on the http request. You can set it in the init function.
func init(){
_, filename, _, _ := runtime.Caller(0)
s := helper.RelativeFilePath(filename)
tplPath = s[1:len(s)] + "template/"
}
The init function will run before main, and just do once.