Let's examine the variable declarations at the beginning of the igweb.go source file found in the igweb folder:

var WebAppRoot string
var WebAppMode string
var WebServerPort string
var DBConnectionString string
var StaticAssetsPath string

The variables declared here are critical for the proper operation of the web server instance. The WebAppRoot variable is responsible for specifying where the igweb project folder resides. The WebServerPort variable is responsible for specifying on what port the web server instance should run on. The DBConnectionString variable is used to specify the connection string to the database. The StaticAssetsPath variable is used to specify the directory that contains all of the static (nondynamic) assets for the project. These assets may consist of CSS style sheets, JavaScript source files, images, fonts, and anything else that isn't meant to be dynamic.

We initialize the variables in the init function:

func init() {

  WebAppRoot = os.Getenv("IGWEB_APP_ROOT")
  WebAppMode = os.Getenv("IGWEB_MODE")
  WebServerPort = os.Getenv("IGWEB_SERVER_PORT")
  DBConnectionString = os.Getenv("IGWEB_DB_CONNECTION_STRING")

  // Set the default web server port if it hasn't been set already
  if WebServerPort == "" {
    WebServerPort = "8080"
  }

  // Set the default database connection string
  if DBConnectionString == "" {
    DBConnectionString = "localhost:6379"
  }

  StaticAssetsPath = WebAppRoot + "/static"

}

The WebAppRoot and WebServerPort variables are obtained from the IGWEB_APP_ROOT and $IGWEB_SERVER_PORT environment variables, respectively.

We will cover the WebAppMode variable and the $IGWEB_MODE environment variable in Chapter 11, Deploying an Isomorphic Go Web Application.

If the $IGWEB_SERVER_PORT environment variable has not been set, the default port is set to 8080.

The DBConnectionString variable is assigned the value of "localhost:6379", which is the hostname and port on which the Redis database instance is running.

The StaticAssetsPath variable is assigned to the static folder, which resides inside the WebAppRoot folder.

Let's examine the beginning of the main function:

func main() {

  env := common.Env{}

  if WebAppRoot == "" {
    fmt.Println("The IGWEB_APP_ROOT environment variable must be set before the web server instance can be started.")
    os.Exit(1)
  }

  initializeTemplateSet(&env, false)
  initializeDatastore(&env)

Right at the beginning of the main function, we check whether the WebAppRoot variable has been set, and if it hasn't been set, we exit from the application. One of the biggest advantages of setting the $IGWEB_APP_ROOT environment variable, which is used to populate the WebAppRoot variable, is that we can issue the igweb command from any folder on the system.

Inside the main function, we initialize the env object. Right after calling the initializeDatastore function to initialize the datastore, we make a call to the initializeTemplateSet function (shown in bold), passing a reference to the env object to the function. This function, as you may have guessed from its name, is responsible for initializing the template set. We will make use of the second argument, of the bool type, passed to the function in Chapter 11, Deploying an Isomorphic Go Web Application. 

Let's examine the initializeTemplateSet function:

func initializeTemplateSet(env *common.Env, oneTimeStaticAssetsGeneration bool) {
  isokit.WebAppRoot = WebAppRoot
  isokit.TemplateFilesPath = WebAppRoot + "/shared/templates"
  isokit.StaticAssetsPath = StaticAssetsPath
  isokit.StaticTemplateBundleFilePath = StaticAssetsPath + "/templates/igweb.tmplbundle"

  ts := isokit.NewTemplateSet()
  funcMap := template.FuncMap{"rubyformat": templatefuncs.RubyDate, "unixformat": templatefuncs.UnixTime}
  ts.Funcs = funcMap
  ts.GatherTemplates()
  env.TemplateSet = ts
}

We start by initializing the isokit package's exported variables for the WebAppRoot, TemplateFilesPath, and StaticAssetsPath variables. We create a new template set, ts, by calling the NewTemplateSet function found in the isokit package.

Right after we create our template set object, ts, we declare a function map, funcMap. We have populated our map with two custom functions that will be exposed to our templates. The key for the first function is rubyformat, and the value is the RubyDate function found in the templatefuncs package. This function will return the Ruby format for a given time value. The key for the second function is unixformat, and this function will return the Unix timestamp for a given time value. We populate the Funcs field of the template set object with the funcMap object that we just created. Now, all the templates in our template set have access to these two custom functions.

Up to this point, we've prepped the template set, but we haven't populated the template set's bundle field. In order to do this, we must call the GatherTemplate method of the TemplateSet object, which will gather all the templates found in the directory specified by isokit.TemplateFilesPath and all of its subdirectories. The names of the template filenames without the .tmpl file extension will be used as the key in the bundle map. The string contents of the template file will be used as the value in the bundle map. If the template is a layout or partial, their respective directory name will be included in the name to refer to them. For example, the partials/footer.tmpl template will have a name of partials/footer.

Now that our template set is fully prepped, we can populate the TemplateSet field of the env object, so that our server-side application has access to the template set. This comes in handy later on, since it allows us to access the template set from any request handler function defined in our server-side web application, providing us the capability to render any template that exists within the template set.