FirstApp
├── appobj
│ ├── appconf.go
│ ├── appobj.go
| └── lead_set_get.go
├── controllers
│ ├── ...
│ ├── ...
.
.
.
├── .dev.config.json
├── .prd.config.json
├── main_test.go
└── main.go
The entry point for go applications is always the main() function, but we seldom write the so-called ‘main’ part of the application in this monolithic function. To that end, an AppObj struct is declared and the main thread of the application runs against it. The content of main.go simply creates an instance of an AppObj struct, parses the flags and then calls the AppObj.Run() method.
When the generated application is started, AppObj.Run() is responsible for:
The creation of the runtime services bears closer inspection before moving on. Generated applications contain an internal ‘service’ for each entity declared in the source model files. The AppObj is responsible for the instantiation of these services when the application is started via the AppObj.createServices() method.
A Services object containing each of the entity runtime services is created on the one-and-only instance of the AppObj. A runtime service is first created to support access to the backend DBMS via the sqac ORM, then a service is started for each entity. Entity services contain a reference to the ORM access handle, as well as an instance of the entity’s validator class which is contained in the model-layer.
The code in appconf.go contains the functions used to load application configuration files, as well as functions containing so-called ‘default’ configuration. It is possible to edit the DefaultConfig() function so that it holds values specific to the local test/development environment. This prevents the need for maintaining a set of configuration files that the development staff need to keep in sync.
The code in lead_set_get.go contains implementation of interface gmcom.GMLeaderSetterGetter. As explained in section Deployment Overview jiffy applications can be deployed as standalone servers, or as a group utilizing a group-leadership model and synchronized access and authorization caching. Default implementations of the Group Leader KVS accessors include support for redis, memcached, stand-alone operation and the dime-store cache server sluggo. The interface is simple to understand and utilizes well-known and well-supported client implementations to access redis and memcached. Although no extension points have been declared in the code to support other KVS servers, it would be a simple matter to do so. See section Interprocess Communication and Multi-Instance Deployment for a detailed overview of interface gmcom.GMLeaderSetterGetter.