Generation Overview

Jiffy Application File Structure

Running the Jiffy generator creates a set of files that comprise a working backend services application. Jiffy generates the following source code tree when provided with a model-file describing a simple ‘Person’ entity.

FirstApp
├── appobj
│   ├── appconf.go
│   ├── appobj.go
|   └── lead_set_get.go
├── controllers
│   ├── authc.go
│   ├── controllerfuncs.go
│   ├── groupauthc.go
│   ├── person_relationsc.go
│   ├── personc.go
│   ├── usrc.go
│   ├── usr_groupc.go
│   └── ext
│       ├── extc_interfaces.go
│       └── personc_ext.go
├── group
│   ├── gmcl
│   │   ├── gmclient.go
│   ├── gmcom
│   │   ├── gmcache.go
│   │   ├── gmclsrv.go
│   │   ├── gmerrors.go
│   │   └── gmomap.go
│   └── gmsrv
│       ├── gmprocessors.go
│       ├── gmprotocol_senders.go
│       ├── gmserver.go
│       └── gmtxrx.go
├── jwtkeys
│   ├── ecdsa256
│   │   ├── ecdsa.priv.pem
│   │   └── ecdsa.pub.pem
│   ├── ecdsa384
│   │   ├── ecdsa384.priv.pem
│   │   └── ecdsa384.pub.pem
│   ├── ecdsa521
│   │   ├── ecdsa521.priv.pem
│   │   └── ecdsa521.pub.pem
│   ├── rsa256
│   │   ├── rsa.priv.pem
│   │   └── rsa.pub.pem
│   ├── rsa384
│   │   ├── rsa384.priv.pem
│   │   └── rsa384.pub.pem
│   └── rsa512
│       ├── rsa512.priv.pem
│       └── rsa512.pub.pem
├── middleware
│   └── requireuser.go
├── models
│   ├── authm.go
│   ├── errors.go
│   ├── group_authm.go
│   ├── modelfuncs.go
│   ├── personm_ext.go
│   ├── personm.go
│   ├── servicesm.go
│   ├── usr_groupm.go
│   ├── usrm.go
│   └── ext
│       └── model_ext_interfaces.go
├── util
│   └── strings.go
├── .dev.config.json
├── .prd.config.json
├── main_test.go
└── main.go

Basic Application Flow

Incoming service requests are handled by a mux, which validates / authenticates the request, and then matches it to a route. The selected route passes the request to a controller specific to the entity-type, where the incoming information is mapped into a go struct matching the entity declaration. The controller then calls the appropriate model method for the http operation and entity-type combination, passing it the entity structure. The model handler passes the entity struct through a member-field validation layer, and then to the model’s interface to the underlying sqac ORM. The database request is handled by the ORM, and then the response is passed from the model back to the controller where it is marshaled into a JSON payload and sent back to the caller in the response-writer’s body.

Jiffy applications contain an embedded leader-based group-membership sub-system that is used for interprocess communication when the generated jiffy application is deployed as multiple processes.

  1. When a jiffy-application is deployed as more than one process (node), there is a need for changes to users, auths, groups and group/auth associations to be communicated to all running instances. These common application entities are cached locally on each running instance in order to avoid accessing a database unnecessarily. An internal cache subsystem was chosen in order to avoid dependencies on external solutions like redis/memcached/etcd etc. (see footnote). Changes to these objects are performed via standard jiffy-admin services that are present in every jiffy-application. When one of the standard admin objects is updated via an admin service, the object’s data is updated in the database. Following a successful database update, the jiffy-application will disseminate the updated object data to the local cache of the application server that processed the change, as well as every other application server (node) in the group.
  2. Given that there is interprocess / inter-nodal communication for the cache updates, the status of the group members must be tracked. The subsystem uses a SWIM (Scalable Weakly-Consistent Infection-Style Process-Membership) protocol to check and disseminate the statues of the group’s processes. A ping is sent from each process to every other known process in the group in random order once per ping-cycle. The ping message contains a piggybacked process-map containing the pinging process’s (node’s) view of the world in terms of process status. Processes (nodes) may have one of the following five statuses (ALIVE, SUSPECT, FAILED, DEPARTING, DEPARTED), as well as a status count indicating how many times the pinging process has noted that a process is in a particular state.

See the Group Membership section of this document for a detailed overview of the group-membership subsystem.

There are more elegant ways to express certain aspects of the generated application. The coding style has been deliberately kept as simple and straight-forward as possible in order to facilitate easier understanding and adjustment of the generated code.

** Using something like etcd to replace the group-membership and app-server-level caching may make sense in Kubernetes-style deployments. In the future, jiffy may move to the etcd model for all deployments.